On Thu, 22 Jun 2006, Hugh Dickins wrote:
> It's intentionally allowed to be racy (ambiguous whether a racing
> thread sees protections before or protections after) up until the
> flush_tlb_range. Should be well-defined from there on.
> Or am I misunderstanding you?
No thats fine but this line of thinking establishes that we need
update_mmu_cache for protection changes. So the documentation on the role
of these calls needs to change. lazy_mmu_prot_update does not do the
notification to arch specific code as documented otherwise we would not
need the flush_tlb_range. In fact it seems that lazy_mmu_prot_update does
only deal with icache/dcache coherency issues and it is separate from
update_mmu_cache because we can avoid checking the icache/dcache issues in
every update_mmu_cache.
> > > But now I wonder, why does do_wp_page reuse case flush_cache_page?
> >
> > Some arches may have virtual caches?
>
> Sorry, I don't get it, you'll have to spell it out to me in detail.
> We have a page mapped for reading, we're about to map that same page
> for writing too. We have no modifications to flush yet,
> why flush_cache_page there?
Hmmm. I found this by Dave Miller in 1999
http://www.ussg.iu.edu/hypermail/linux/kernel/9906.0/1237.html
flush_cache_page(vma, page) is meant to also take care of the case
here for some reason the TLB entry must exist for the cache entry to
be valid as well. This is the case on the HyperSparc's combined I/D
L2 cache (it has no L1 cache), you cannot flush out cache entries
which have no translation, it will make the cpu trap. Sparc/sun4c's
mmu is like this too.
If I read this correctly then it seems the reason that flush_cache_page
was placed there is that on some architecture the TLB entry must exist
correctly on virtual caches to be able to flush the caches (maybe they
are hashed?). update_mmu_cache is called after we changed things so there
may be no way to determine how to flush the cache contents for the page
contents if we later drop the page.
-
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]
