Re: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio

[David Brownell <david-b@pacbell.net>]

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/