On Mon, Aug 11, 2003 at 10:49:05PM +0200, Oliver Neukum wrote:
> Am Montag, 11. August 2003 22:20 schrieb Greg KH:
> > On Mon, Aug 11, 2003 at 09:44:42PM +0200, Oliver Neukum wrote:
> > > Hi,
> > > 
> > > this function races with itself, doesn't return errors and races with
> > > releasing interfaces. This patch fixes it by changing the function
> > > prototype, introducing locking and having a correct order in
> > > releasing interfaces.
> > 
> > So you're using the fact that lock_kernel() can recurse here, right?
> > That's not pretty :(
> 
> Actually no. It's just not worth introducing another dedicated lock
> and we are in -test where I strive for minimal changes in core
> code.

I strive for correctness :)
Is there a better way you can think of solving this without using the
BKL?

> > Hm, I _really_ hate this function in the first place, but I can see how
> > it could be necessary for some devices.  Since currently probe() is
> > called sequentially for a device (no other interfaces on the same device
> > can be called at the same time), this lock isn't really necessary,
> > right?
> 
> Not so, interfaces are claimed by usbfs as well.

Bleah, I keep forgetting about usbfs...

> > I really don't want to add lock_kernel() here if we can avoid it.
> 
> Usbfs assumes BKL here.

But the probe() sequence doesn't, right?  So we are just protecting
ourself from usbfs, correct?  If so, how about a nice comment about that
here, as that's all we are trying to prevent the race for.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to