Query about __unmap_hugepage_range
bill_carson at 126.com
Fri Apr 8 04:04:52 EDT 2011
Hey, MM developers:)
I don't know if this posting is proper at here, so sorry for disturbing if it does.
for normal 4K page: in unmap_page_range
1: tlb_start_vma(tlb, vma); <------ call flush_cache_range to invalidate icache if vma is VM_EXEC
2: clear pagetable mapping
3: tlb_end_vma(tlb, vma); <-------- call flush_tlb_range to invalidate unmapped vma tlb entry
for hugepage: in __unmap_hugepage_range
1: clear pagetable mapping
2: call flush_tlb_range(vma, start, end); to invalidate unmapped vma tlb entry
I really don't understand about two things:
A: why there is no flush_cache_range for hugepage when we do the unmapping?
B: How does kernel take care of such case for both normal 4K page and hugepage:
a: mmap a page with PROT_EXEC at location p;
b: copy bunch instruction into p ,call cacheflush to make ICACHE see the new instruction;
c: run instruction at location p, then unmap it;
d: mmap a new page with MAP_FIXED/PROT_EXEC at location p, and run unexpected instruction at p;
there is a great chance we got the same page at step_a;
user space should see a clean icache, not a stale one;
I am really puzzled for a long time.
I am porting hugepage for ARM ,and one testcase in libhugetlbfs called icache-hygiene failed, test rationale is described in above B.
Any tips/advice would be truly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linux-arm-kernel