Re: [PATCH]generic usb serial driver

Am Samstag, 31. März 2007 01:31 schrieb David Brownell:
> On Friday 30 March 2007 2:49 pm, Oliver Neukum wrote:
> 
> > > Nope.  If an smp_mb() is needed, the reason is because of other
> > > driver-internal bugs.
> 
> > > Remember that the driver isn't allowed to so much as *LOOK* at any
> > > field of an URB until the completion callback.  That generalizes:
> > > it mustn't do so until that callback (cleanly) hands the URB back
> > 
> > Yes and the callback is guaranteed that all the urb's fields are
> > valid. Which is the whole point. Is that guarantee only valid to the
> > callback or to the whole driver?
> > 
> > CPU A (callback)			CPU B
> > 
> > flag = 1;					if (!flag) barrier();
> > a = urb->status;			b = urb->status;
> > 
> > Do we guarantee a==b or don't we?
> 
> I don't see a handoff there that's even vaguely correct, which
> means this code displays one of those "driver-internal bugs".
> 
> So of course there's no such guarantee.
> 
> It's perfectly legit for CPU A to reorder writes; common, even,
> when they're in different cache lines.

Very well, that is a clear statement :-)

That raises the question how the issue is to be solved. To me the obvious
solution to a lack of memory ordering is to specify memory ordering
explicitely. However, I seem to be in the minority.

The other way around it would be to use wait_for_completion().
Oppinions?

	Regards
		Oliver

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel