[Devel] Re: [PATCH] usbatm: Update to use the kthread api.
Alan Stern
stern at rowland.harvard.edu
Wed Jan 3 09:52:42 PST 2007
On Wed, 3 Jan 2007, Eric W. Biederman wrote:
> >> The probem with signals is that they can come from various sources, most
> >> notably from random kill commands issues from userland. This defeats
> >> the notion of a fixed thread lifetime under control of the owning module.
> >> Of course this issue doesn't exist for you above useage where you'd
> >> hopefully avoid allowing signals that could terminate the thread.
> >
> > In my case the situation is exactly the reverse: I _want_ to allow signals
> > to terminate the thread (as well as allowing signals to interrupt I/O).
I should have been clearer here. Signals don't terminate the thread; they
merely notify it to clean up and terminate itself.
> > The reason is simple enough. At system shutdown, if the thread isn't
> > terminated then it would continue to own an open file, preventing that
> > file's filesystem from being unmounted cleanly. Since people should be
> > able to unmount their disks during shutdown without having to unload
> > drivers first, the simplest solution is to allow the thread to respond to
> > the TERM signal normally sent by the shutdown scripts.
> >
> > Since the thread is owned by the kernel, random kill commands won't have
> > any bad effect. Only kill commands sent by the superuser can terminate
> > the thread.
> >
>
> Why in the world would a thread hold a file open for an indeterminate duration?
> That seems very wrong.
The thread uses the file to provide backing storage. Kind of like the
loop driver, except that my driver uses a higher-level interface into the
VFS than the loop driver does, for greater simplicity. You wouldn't say
that what the loop driver does is wrong, would you?
> I can just about understand reading a firmware file or something like that
> and close the file afterwards. But unless you are worrying about a very small
> window I think we have a problem here.
I don't follow. Why do you think there's a problem?
Alan Stern
_______________________________________________
Containers mailing list
Containers at lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers
More information about the Devel
mailing list