On 01.07.2011, at 00:32, Scott Wood wrote: > On Fri, 1 Jul 2011 00:28:19 +0200 > Alexander Graf <ag...@suse.de> wrote: > >> >> On 01.07.2011, at 00:23, Scott Wood wrote: >> >>> On Fri, 1 Jul 2011 00:18:22 +0200 >>> Alexander Graf <ag...@suse.de> wrote: >>> >>>> >>>> On 01.07.2011, at 00:11, Scott Wood wrote: >>>> >>>>> Almost, but what if we have write permission but not read? >>>> >>>> How would you write back data from a cache line when you haven't read it >>>> earlier? >>> >>> The CPU can read it. The program can't. >> >> Hrm. We can always just call the check manually and trigger the respective >> interrupt :). > > Yep. A little trickier, but doable. > >>>>> but what about a race with DMA from the I/O thread? >>>> >>>> That'd simply be broken, but I don't quite see how it wouldn't with real >>>> hardware either :). >>> >>> Real hardware doesn't generate a load/store sequence that the program didn't >>> ask for -- where's the breakage? >> >> Real hardware flushes whatever contents are in that cache line to RAM, no? >> So it would collide with the DMA just as much. Or am I missing something? > > If the DMA happens after the cache line is fetched, it'll be flushed, > whether locked or not. But that's different from losing some of what the > device wrote.
Ah, so DMA flushes even locked cache lines? Then it makes sense. Well, I guess the best choice here really is to merely do a manual storage protection check and be done with it. Alex
