Re: Daemonize() should re-parent its caller

[Andrew Morton <akpm@zip.com.au>]

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?)

-