Message-ID: <Pine.LNX.4.44L0.0704261114080.3552-100000@iolanthe.rowland.org>
Date:	Thu, 26 Apr 2007 11:29:52 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Kthread question

Here's a question about how to use a kthread.

The usb-storage driver creates a new thread to do LUN scanning whenever a
newly-hotplugged device is detected.  This scanning involves waiting for
several seconds and then carrying out a potentially long-lasting series of
I/O operations.  So we don't want to use schedule_work(); instead we
create a new thread to do it.

Once the scanning thread's work is done, there's no reason for it to hang
around.  The driver's probe() method has long since exited, leaving nobody
to reap the thread.  Of course it could always just exit normally, without
checking kthread_should_stop(), but...

If the device is unplugged during that initial several-second-long delay 
period, we need to stop the scanning thread immediately.  The obvious 
answer is to use kthread_stop(), but that's not consistent with the 
thread's normal behavior of exiting without waiting for 
kthread_should_stop().

Another problem arises as well.  If the driver's remove() method doesn't
call kthread_stop() then it doesn't have any straightforward way to wait
for the thread to exit.  This leads to the possibility that the driver's
module could be unloaded while the scanning thread is still running.

Would the best approach be to set up a special-purpose struct completion?  
Then the thread could call complete_and_exit() and the remove() method
could wait for it safely.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists