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
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
