[lkml]   [2001]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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;
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.


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
More majordomo info at
Please read the FAQ at

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