On Fri, 13 Apr 2007 11:31:16 +0400 Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> 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 bl
Andrew Morton <[EMAIL PROTECTED]> writes:
> jffs2 actually wants its head examined. W. T. F. does it think it's
> doing in there?
Good question, especially with respect to SIGHUP.
It is on my short list of very annoying kernel threads...
NFS and a few kernel threads others currently need a way
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
> > signal
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 "kill
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
5 matches
Mail list logo