Messages in this thread | | | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: [BUG] oops while completing async USB via usbdevio | Date | Tue, 31 May 2005 11:53:24 -0700 |
| |
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/
| |