lkml.org 
[lkml]   [2001]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 8139too termination
Robert Kuebel wrote:
>
> hi,
>
> i have been getting this message at shutdown ...
>
> "eth1: unable to signal thread"
>
> it turns out that 8139too's kernel thread gets killed at shutdown (or
> reboot) when SIGTERM is sent to all processes. then the network
> shutdown script comes along and takes down the interface. the driver
> complains ...
>
> "eth1: unable to signal thread"
>
> because the thread has already terminated. the driver currently does
> not block any signals.
>
> my question is, should 8139too really not block any signals (and allow
> itself to be killed by them)? isn't it a bad thing to allow a kernel
> thread to be killed accidentally like this?
>

Yes, I'd agree that the driver should ignore random signals.
The kernel thread should only allow itself to be terminated
via the driver's close() method.

An obvious approach is to change rtl8139_close() to do:

tp->diediedie = 1;
wmb();
ret = kill_proc(...);

and test the flag in rtl8139_thread().

The tricky part is teaching the thread to ignore the
spurious signals - the signal_pending() state needs to be
cleared. I think flush_signals() is the way to do this.
See context_thread() for an example.

spin_lock_irq(&curtask->sigmask_lock);
flush_signals(curtask);
recalc_sigpending(curtask);
spin_unlock_irq(&curtask->sigmask_lock);

The recalc_sigpending() here appears to be unnecessary...

The kernel thread in 8139too has certainly been an interesting
learning exercise :) Using signals and task management in-kernel
is full of pitfalls. In retrospect, probably it should have used
waitqueues directly.

-
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:12    [W:0.066 / U:6.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site