lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 18 May 2009 17:45:50 +0200
From:	Oleg Nesterov <>
To:	Linus Torvalds <>
Cc:	Ingo Molnar <>, "Rafael J. Wysocki" <>,
	Jonathan Corbet <>, Martin Bammer <>,
	Jeff Garzik <>,
	Kumar Gala <>,
	Andrew Morton <>,
	Linux Kernel Mailing List <>,
	Adrian Bunk <>,
	Natalie Protasevich <>,
	Kernel Testers List <>,
	Network Development <>,
	Linux ACPI <>,
	Linux PM List <>,
	Linux SCSI List <>,
	Linux Wireless List <>,
	DRI <>
Subject: Re: 2.6.30-rc6: Reported regressions from 2.6.29

On 05/18, Linus Torvalds wrote:
> On Mon, 18 May 2009, Ingo Molnar wrote:
> >
> > Btw., why did the patch (and the revert) make any difference to the
> > test? Timing differences look improbable.
> It's the change from
> 	!signal_group_exit(signal)
> to
> 	!sig_kernel_only(signr)
> and quite frankly, I still don't see the point.



meant: we do not know what should we do, let's ignore this signal.
Unless the multithreaded init does exec, in this case we should
respect SIGKILL.

With the recent changes, sig_kernel_only() means: we already checked
we should handle SIGKILL/SIGSTOP when this signal was queued.

> The comment seems to be wrong too:
>     If SIGSTOP/SIGKILL originate from a descendant of container-init they are
>     never queued (i.e dropped in sig_ignored() in an earler patch).
>     If SIGSTOP/SIGKILL originate from parent namespace, the signal is queued
>     and container-init processes the signal.
> since the bug was that the SIGSTOP (from within the same container) was
> _not_ ignored like the comment says.

Yes, the changelog could be better because it ignores ptrace issues. But
this was discussed,


	Yes we should handle SIGSTOP fine if it sent from the parent namespace.

	Also. Currently it is possible to ptrace the global init, but even
	ptracer can't stop it (but ptrace_stop() works). With these patches
	ptracer can stop init.

	I forgot to mention this behaviour change, imho this side-effect
	is good.

So, at least this change is not "by accident".


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists