Re: [RFC][PATCH] Kernel thread signal handling.

[Andrew Morton]

David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>
>  1. We need disallow_signal() to complement allow_signal().
> 
>  2. We need a function which does dequeue_signal() _with_ locking.
> 
>  3. We might need a better name for #2. Change if you care.
> 
>  4. We need allow_signal() to actually allow signals other than
>     SIGKILL. Currently they get either converted to SIGKILL or
>     silently dropped, according to whether your kernel thread
>     happens to have sa_handler set for the signal in question.
> 
>     It would be nicer to fix this in the signal delivery code
>     itself if (!tsk->mm) rather than by faking a handler in
>     allow_signal(). I'm not touching the signal delivery code
>     with a bargepole though. Hopefully the proposed change to
>     allow_signal() will provoke someone else into doing so.

Sigh.  Using signals to communicate with kernel threads is evil.  It keeps
on breaking and each site does it differently and we've had plenty of bugs
due to this practice.

Signals are for userspace and the signal developers shouldn't have to worry
about weird in-kernel abuse and we have other simpler, more reliable
mechanisms available in-kernel and even more such ranting you get the
point.

Is there no way in which jffs2 can be weaned off this obnoxious habit?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/