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

[Harald Welte]

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.

> > > I'm not familiar with the scheduler code to decide what fix
> > > is the way to go.  Is it sufficient to do {get,put}_task_struct() from
> > > the usb code?
> 
> It's worth making that change in any case, to avoid such questions in
> the future.  And if it does any good, more power to the patch!

Ok.

> 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 ;)

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

> > mh. it appears like it's sighand which disappears, not the task itself.
> > ...
> 
> Odd.  Isn't that nulled only in __exit_sighand(), which gets called only
> when the task itself is finally being freed?

yes, I couldn't find any other location but __exit_sighand() that nulls
task->sighand.  And looking at exit.c, do_exit() definitely calls
__exit_files(tsk) before it calls __exit_sighand() via exit_notify().


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.

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.

Cheers,
	Harald
-- 
- Harald Welte <laforge@xxxxxxxxxxxx>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Attachment: pgp00000.pgp
Description: PGP signature