lkml.org 
[lkml]   [2005]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio
Date
On Tuesday 31 May 2005 1:48 am, Harald Welte wrote:
> On Mon, May 30, 2005 at 03:55:39PM -0700, David Brownell wrote:
>
> > The logic closing an open usbfs file -- which is done before any task
> > exits with such an open file -- is supposed to block till all its URBs
> > complete. So the pointer to the task "should" be valid for as long as
> > any URB it's submitted is active.
>
> unfortunately it doesn't seem to cover the fork() case, see below.

OK, so it seems this is a moderately deep broken assumption in usbfs.


> > Not that it helps at all, but I've never really trusted the usbfs async
> > I/O code. "Real AIO" could be a lot more obviously correct. And smaller.
>
> mh, but nobody has written AIO-enabled usbfs2 yet ;)

I'm still hoping that one of the folk who want make an interesting and
useful contribution to Linux will take the hint. It goes slowly. :)


Right now I think a "usbfs 1.5" would be the simplest way to deliver
it ... an ioctl that returns a new per-endpoint file descriptor. It'd
need to support the AIO calls and a bit more ... and that could be the
guts of a "usbfs2". The "gadgetfs" code shows how small that part
could be ... and later, some libfs based code could do all the fun
stuff, creating a real "usbfs2" that exports normal per-endpoint files
and so on. Then we could deprecate the current AIO stuff...


> meanwhile, the current usbfs aio handling is the only way how to deal
> with delivery of interrupt pipe URB's to userspace drivers.

Other than tying up the file descriptor with a blocking read, that is.


> However, __exit_files() only calls close_files() if files->count goes
> down to zero. What if the process fork()ed before, and the other half of
> the fork still has a refcount? -> boom.
>
> It seems to me that the whole usbdevio async handling doesn't really
> cope with a lot of the unix semantics, such as fork() or file descriptor
> passing.

*cough* usbfs2 aio *cough*


> Wouldn't it help to associate the URB with the file (instaed of the
> task), and then send the signal to any task that still has opened the
> file? I'm willing to hack up a patch, if this is considered a sane fix.

Sounds reasonable, except that not all such tasks will want the signal.
Though I guess the infrastructure to filter the signal out already exists,
so the main missing piece is that urb-to-file binding.

- Dave

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

\
 
 \ /
  Last update: 2005-05-31 21:14    [W:0.824 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site