Am Mittwoch, 14. März 2007 23:44 schrieb David Howells:
> Pete Zaitcev <[EMAIL PROTECTED]> wrote:
>
> > I think he is concerned about CPU A executing an interrupt handler, its
> > stores getting stuck in its store buffer or its write-back cache, the IRQ
> > finished, IRQ get migrated to CPU B, CPU B taking next interrupt and seeing
> > old RAM state. I don't see this possible, because we take too many
> > spinlocks when IRQ is processed and they definitely drain store buffers and
> > caches. Not to mention the IRQ migration from A to B...
>
> I agree. Unless the IRQ is bound to a particular CPU (in which case it can't
> exhibit the behaviour in question), it will lock and unlock the IRQ descriptor
> spinlock at least once each side of executing a chain of handlers, and whilst
> it's executing the handlers, it may not migrate. This means you get, in
> effect, a full memory barrier either side of a handler:
OK, thanks. I am relieved.
Should I add a section concerning this to Documentation?
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
