On Fri, 13 Apr 2007 08:13:32 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Oleg Nesterov <[EMAIL PROTECTED]> writes: > > > On top of Eric's > > > > kthread-dont-depend-on-work-queues-take-2.patch > > > > Currently kernel threads use sigprocmask(SIG_BLOCK) to protect against > > signals. > > This doesn't prevent the signal delivery, this only blocks signal_wake_up(). > > Every "killall -33 kthreadd" means a "struct siginfo" leak. > > > > Change kthreadd_setup() to set all handlers to SIG_IGN instead of blocking > > them > > (make a new helper ignore_signals() for that). If the kernel thread needs > > some > > signal, it should use allow_signal() anyway, and in that case it should not > > use > > CLONE_SIGHAND. > > > > Note that we can't change daemonize() (should die!) in the same way, because > > it can be used along with CLONE_SIGHAND. This means that allow_signal() > > still > > should unblock the signal to work correctly with daemonize()ed threads. > > > > However, disallow_signal() doesn't block the signal any longer but ignores > > it. > > > > NOTE: with or without this patch the kernel threads are not protected from > > handle_stop_signal(), this seems harmless, but not good. > > Hmm. I like it all except for disallow_signal. > > disallow_signal currently only has one user, jffs2. While jffs2 > currently doesn't care, given the way jffs2 is using disallow_signal I > would expect it would prefer to have the signal blocked. > > Thinking about this some more if jffs2 or anyone else wants blocked > signal behavior they can go ahead and block the signal. Keeping > disallow_signal in sync with allow_signal seems to make sense. jffs2 actually wants its head examined. W. T. F. does it think it's doing in there? Sigh. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
