Re: Unusually long delay in the kernel

[Andrew Morton]

Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> > Presumably it's spinning on the bkl.  Is this actually an SMP machine?  If
> > so, perhaps some other process is holding the bkl for a long time.  Perhaps
> > a netdevice spending a long time diddling hardware in an ioctl, something
> > like that.
> 
> I need to do more precise tests.  Some quick informal tests indicated that 
> the lock_kernel call and the daemonize call each took a noticeable time.  

Something odd is happening.

> > That code could be converted to the kthread API btw.
> 
> Hmph.  Near as I can tell, the only changes that would involve are:
> 
> 	Converting the thread creation call from kernel_thread to
> 	kthread_run.
> 
> 	Adding another call to wake the thread up once it has been
> 	created.
> 
> 	Removing the call to daemonize.
> 
> There wouldn't be any need to call kthread_stop -- and in fact it wouldn't 
> work, as the thread waits on a semaphore while it is idle (kthread_stop 
> can't cope with things like that).

Well I was assuming that the semaphore would go away as well.  Kernel
threads normally use waitqueues to await more work.

> 
> That reminds me, I've got another question.  Once a thread has called
> daemonize, or if it was started using kthread_run, all its signals are
> blocked.  Is it still possible that through some extraordinary
> circumstance the thread could receive a signal, or are we absolutely
> guaranteed that no signals will arrive until the thread enables them?  

Kernel threads should sleep in state TASK_INTERRUPTIBLE, with all signals
blocked.  Because they don't want to contribute to the load average, and
because they shouldn't use signals.

So if it was possible to deliver a signal to an all-signals-blocked kernel
thread, that kernel thread would go into a busy loop, because all of its
sleep attempts will fall straight through (signal_pending() is true).  So I
think it's safe to assume that nobody ever does force_sig() on a kenrel
thread.

> It's important to know the answer, because normally a thread spends its
> idle time waiting on down_interruptible or something similar.  If a signal
> managed to get through somehow, the thread would never be able to go back
> to sleep unless it explicitly flushed its signals.

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