On Wed, Dec 11, 2002 at 01:26:53AM +0100, Oliver Neukum wrote:
> 
> > > Doesn't sound easy to me.
> >
> > Ick, that's even messier :(
> > In looking at your match, I think we only need the last bit, right?  The
> > other stuff was formatting cleanup, and code reorg from a first glance.
> 
> The first hunk is editor junk, true, sorry.
> The rest is essential. That code is shifted around for a reason.
> The copy_to_user() must come after the tree has been walked,
> because BKL may be dropped that way.
> The downside of this is that memory consumption increases
> drastically. Worst case is ~900K with GFP_ATOMIC.

That's not acceptable :(

> If you really want this cleanly you need a lock for the usb device
> tree. That however means rewriting a lot of locking in usbcore.
> We need to lock the whole tree because not only are the devices
> needed and must not be freed, but the tree's topology must
> be absolutely preserved while the read is being executed.
> Even my patch is theoretically speaking incomplete.
> There should be mutual exclusion with usb_device_reset()
> and usb_set_configuration().

Well I would argue that the tree topology doesn't have to be preserved
between calls to read(), much like it is today, only during a single
read(), which can be done with the bus locks, right?

thanks,

greg k-h


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to