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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
