Skip to content

L
linux
Switch branch/tag
  1. 04 Jan, 2012 9 commits
    • Oleg Nesterov's avatar
      ptrace: ensure JOBCTL_STOP_SIGMASK is not zero after detach · 8a88951b
      Oleg Nesterov authored 
      This is the temporary simple fix for 3.2, we need more changes in this
area.

1. do_signal_stop() assumes that the running untraced thread in the
   stopped thread group is not possible. This was our goal but it is
   not yet achieved: a stopped-but-resumed tracee can clone the running
   thread which can initiate another group-stop.

   Remove WARN_ON_ONCE(!current->ptrace).

2. A new thread always starts with ->jobctl = 0. If it is auto-attached
   and this group is stopped, __ptrace_unlink() sets JOBCTL_STOP_PENDING
   but JOBCTL_STOP_SIGMASK part is zero, this triggers WANR_ON(!signr)
   in do_jobctl_trap() if another debugger attaches.

   Change __ptrace_unlink() to set the artificial SIGSTOP for report.

   Alternatively we could change ptrace_init_task() to copy signr from
   current, but this means we can copy it for no reason and hide the
   possible similar problems.
Acked-by: default avatarTejun Heo <tj@kernel.org>
Cc: <stable@kernel.org>		[3.1]
Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8a88951b
    • Oleg Nesterov's avatar
      ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD->EXIT_ZOMBIE race · 50b8d257
      Oleg Nesterov authored 
      Test-case:

	int main(void)
	{
		int pid, status;

		pid = fork();
		if (!pid) {
			for (;;) {
				if (!fork())
					return 0;
				if (waitpid(-1, &status, 0) < 0) {
					printf("ERR!! wait: %m\n");
					return 0;
				}
			}
		}

		assert(ptrace(PTRACE_ATTACH, pid, 0,0) == 0);
		assert(waitpid(-1, NULL, 0) == pid);

		assert(ptrace(PTRACE_SETOPTIONS, pid, 0,
					PTRACE_O_TRACEFORK) == 0);

		do {
			ptrace(PTRACE_CONT, pid, 0, 0);
			pid = waitpid(-1, NULL, 0);
		} while (pid > 0);

		return 1;
	}

It fails because ->real_parent sees its child in EXIT_DEAD state
while the tracer is going to change the state back to EXIT_ZOMBIE
in wait_task_zombie().

The offending commit is 823b018e which moved the EXIT_DEAD check,
but in fact we should not blame it. The original code was not
correct as well because it didn't take ptrace_reparented() into
account and because we can't really trust ->ptrace.

This patch adds the additional check to close this particular
race but it doesn't solve the whole problem. We simply can't
rely on ->ptrace in this case, it can be cleared if the tracer
is multithreaded by the exiting ->parent.

I think we should kill EXIT_DEAD altogether, we should always
remove the soon-to-be-reaped child from ->children or at least
we should never do the DEAD->ZOMBIE transition. But this is too
complex for 3.2.
Reported-and-tested-by: default avatarDenys Vlasenko <vda.linux@googlemail.com>
Tested-by: default avatarLukasz Michalik <lmi@ift.uni.wroc.pl>
Acked-by: default avatarTejun Heo <tj@kernel.org>
Cc: <stable@kernel.org>		[3.0+]
Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      50b8d257
    • Linus Torvalds's avatar
      Merge git://git.samba.org/sfrench/cifs-2.6 · 8d9cbf82
      Linus Torvalds authored 
      * git://git.samba.org/sfrench/cifs-2.6:
  [CIFS] default ntlmv2 for cifs mount delayed to 3.3
  cifs: fix bad buffer length check in coalesce_t2
      8d9cbf82
    • Linus Torvalds's avatar
      Revert "rtc: Expire alarms after the time is set." · f423fc62
      Linus Torvalds authored 
      This reverts commit 93b2ec01.

The call to "schedule_work()" in rtc_initialize_alarm() happens too
early, and can cause oopses at bootup

Neil Brown explains why we do it:

  "If you set an alarm in the future, then shutdown and boot again after
   that time, then you will end up with a timer_queue node which is in
   the past.

   When this happens the queue gets stuck.  That entry-in-the-past won't
   get removed until and interrupt happens and an interrupt won't happen
   because the RTC only triggers an interrupt when the alarm is "now".

   So you'll find that e.g.  "hwclock" will always tell you that
   'select' timed out.

   So we force the interrupt work to happen at the start just in case."

and has a patch that convert it to do things in-process rather than with
the worker thread, but right now it's too late to play around with this,
so we just revert the patch that caused problems for now.
Reported-by: default avatarSander Eikelenboom <linux@eikelenboom.it>
Requested-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Requested-by: default avatarJohn Stultz <john.stultz@linaro.org>
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f423fc62
    • Steve French's avatar
      [CIFS] default ntlmv2 for cifs mount delayed to 3.3 · 225de11e
      Steve French authored 
      Turned out the ntlmv2 (default security authentication)
upgrade was harder to test than expected, and we ran
out of time to test against Apple and a few other servers
that we wanted to.  Delay upgrade of default security
from ntlm to ntlmv2 (on mount) to 3.3.  Still works
fine to specify it explicitly via "sec=ntlmv2" so this
should be fine.
Acked-by: default avatarJeff Layton <jlayton@samba.org>
Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      225de11e
    • Jeff Layton's avatar
      cifs: fix bad buffer length check in coalesce_t2 · 497728e1
      Jeff Layton authored 
      The current check looks to see if the RFC1002 length is larger than
CIFSMaxBufSize, and fails if it is. The buffer is actually larger than
that by MAX_CIFS_HDR_SIZE.

This bug has been around for a long time, but the fact that we used to
cap the clients MaxBufferSize at the same level as the server tended
to paper over it. Commit c974befa changed that however and caused this
bug to bite in more cases.
Reported-and-Tested-by: default avatarKonstantinos Skarlatos <k.skarlatos@gmail.com>
Tested-by: default avatarShirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      497728e1
    • Linus Torvalds's avatar
      Revert "rtc: Disable the alarm in the hardware" · 157e8bf8
      Linus Torvalds authored 
      This reverts commit c0afabd3.

It causes failures on Toshiba laptops - instead of disabling the alarm,
it actually seems to enable it on the affected laptops, resulting in
(for example) the laptop powering on automatically five minutes after
shutdown.

There's a patch for it that appears to work for at least some people,
but it's too late to play around with this, so revert for now and try
again in the next merge window.

See for example

	http://bugs.debian.org/652869

Reported-and-bisected-by: Andreas Friedrich <afrie@gmx.net> (Toshiba Tecra)
Reported-by: Antonio-M. Corbi Bellot <antonio.corbi@ua.es> (Toshiba Portege R500)
Reported-by: Marco Santos <marco.santos@waynext.com> (Toshiba Portege Z830)
Reported-by: Christophe Vu-Brugier <cvubrugier@yahoo.fr>  (Toshiba Portege R830)
Cc: Jonathan Nieder <jrnieder@gmail.com>
Requested-by: default avatarJohn Stultz <john.stultz@linaro.org>
Cc: stable@kernel.org  # for the versions that applied this
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      157e8bf8
    • Mandeep Singh Baines's avatar
      hung_task: fix false positive during vfork · f9fab10b
      Mandeep Singh Baines authored 
      vfork parent uninterruptibly and unkillably waits for its child to
exec/exit. This wait is of unbounded length. Ignore such waits
in the hung_task detector.
Signed-off-by: default avatarMandeep Singh Baines <msb@chromium.org>
Reported-by: default avatarSasha Levin <levinsasha928@gmail.com>
LKML-Reference: <1325344394.28904.43.camel@lappy>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: John Kacur <jkacur@redhat.com>
Cc: stable@kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f9fab10b
    • Jan Kara's avatar
      security: Fix security_old_inode_init_security() when CONFIG_SECURITY is not set · 30e05324
      Jan Kara authored 
      Commit 1e39f384 ("evm: fix build problems") makes the stub version
of security_old_inode_init_security() return 0 when CONFIG_SECURITY is
not set.

But that makes callers such as reiserfs_security_init() assume that
security_old_inode_init_security() has set name, value, and len
arguments properly - but security_old_inode_init_security() left them
uninitialized which then results in interesting failures.

Revert security_old_inode_init_security() to the old behavior of
returning EOPNOTSUPP since both callers (reiserfs and ocfs2) handle this
just fine.

[ Also fixed the S_PRIVATE(inode) case of the actual non-stub
  security_old_inode_init_security() function to return EOPNOTSUPP
  for the same reason, as pointed out by Mimi Zohar.

  It got incorrectly changed to match the new function in commit
  fb88c2b6: "evm: fix security/security_old_init_security return
  code".   - Linus ]
Reported-by: default avatarJorge Bastos <mysql.jorge@decimal.pt>
Acked-by: default avatarJames Morris <jmorris@namei.org>
Acked-by: default avatarMimi Zohar <zohar@us.ibm.com>
Signed-off-by: default avatarJan Kara <jack@suse.cz>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      30e05324
  3. 03 Jan, 2012 1 commit
  5. 02 Jan, 2012 2 commits
  7. 31 Dec, 2011 6 commits
  9. 30 Dec, 2011 17 commits
  11. 29 Dec, 2011 3 commits
  13. 28 Dec, 2011 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7