Re: [PATCH 1/3] Fix COW D-cache aliasing on fork

[Nick Piggin <nickpiggin@yahoo.com.au>]

Linus Torvalds wrote:
> On Sat, 21 Oct 2006, Nick Piggin wrote:
>
> > So moving the flush_cache_mm below the copy_page_range, to just
> > before the flush_tlb_mm, would work then? This would make the
> > race much smaller than with this patchset.
> >
> > But doesn't that still leave a race?
> >
> > What if another thread writes to cache after we have flushed it
> > but before flushing the TLBs? Although we've marked the the ptes
> > readonly, the CPU won't trap if the TLB is valid? There must be
> > some special way for the arch to handle this, but I can't see it.
>
>
> Why not do the cache flush _after_ the TLB flush? There's still a mapping, 
> and never mind that it's read-only: the _mapping_ still exists, and I 
> doubt any CPU will not do the writeback (the readonly bit had better 
> affect the _frontend_ of the memory pipeline, but affectign the back end 
> would be insane and very hard, since you can't raise a fault any more).

I didn't think that would work if there is no TLB. But if the writeback
can cause a TLB reload, and then bypass the readonly protection, then
yes would close all races.

Of course, you may also want to do the racy cache flush before the
TLB flush as well, so you don't immediately take a load of TLB misses
to write it out.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/