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.
Previously, !signal_group_exit(signal) 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, >From http://marc.info/?t=123222433100001 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". Oleg. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel