Alan Stern wrote:
>
> Consider the question: what happens when a kernel thread dies? For
> the most part this doesn't come up, since most kernel threads stay
> alive as long as the system is up. But when a kernel thread dies, the
> same thing happens as with any other thread: it becomes a zombie, and
> its exit_signal (if any) is posted to its parent.
>
> ...
>
> But a more elegant and economical solution is to have the daemonize()
> routine automatically re-parent its caller to be a child of init
> (assuming the caller's parent isn't init already). At the same time,
> the caller's exit_signal should be set to SIGCHLD. This would
> definitely solve the problem, and it is unlikely to introduce any
> incompatibilities with existing code.
>
Yes. There's a function in the 2.4 series called reparent_to_init()
whch does this. Typically a kernel thread will call that immediately
after calling daemonize(). It _should_ solve any problem which you're
observing. Could you please test that, and if it fixes the problem
which you're seeing, send a patch to the USB maintainers?
Perhaps we should unconditionally call reparent_to_init() from within
daemonize(). I wimped out on doing that because of the possibility
of strangely breaking something.
Really, an audit of all callers of kernel_thread() is needed, and
most of them should would end up using reparent_to_init(). Difficult
to do in the 2.4 context, so we should only do this when and where
problems are demonstrated.
(But you Cc'ed Alan. Are you using 2.2.x?)
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:01:06 EST