linux-kernel - Re: Kthread question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <m1r6q7j6i4.fsf@ebiederm.dsl.xmission.com>
Date:	Thu, 26 Apr 2007 13:11:15 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Kthread question

Alan Stern <stern@...land.harvard.edu> writes:

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

Ok.    Because of the module unloading issue, and because we don't have
a lot of these threads running around, the current plan is to fix
thread_create and kthread_stop so that they must always be paired,
and so that kthread_stop will work correctly if the task has already
exited.

Basically that just involves calling get_task_struct in kthread_create
and put_task_struct in kthread_stop.

I have some patches, hopefully I will start getting them out in the next day or
two.  Sorry I should have acted on this sooner, but I got a little distracted.

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