Nick Piggin wrote:
What the tlb flush used to be able to assume is that the page
has been removed from the pagetables when they are put in the
tlb flush batch.
I think this is still the case, to a degree. There should be
no harm in removing the TLB entries after the page table has
been unlocked, right?
Or is something like the attached really needed?
From what I can see, the page table lock should be enough
synchronization between unmap_mapping_range, MADV_FREE and
MADV_DONTNEED.
I don't see why we need the attached, but in case you find
a good reason, here's my signed-off-by line for Andrew :)
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
--- linux-2.6.20.x86_64/mm/memory.c.flushme 2007-04-23 22:26:06.000000000 -0400
+++ linux-2.6.20.x86_64/mm/memory.c 2007-04-23 22:42:06.000000000 -0400
@@ -628,6 +628,7 @@ static unsigned long zap_pte_range(struc
long *zap_work, struct zap_details *details)
{
struct mm_struct *mm = tlb->mm;
+ unsigned long start_addr = addr;
pte_t *pte;
spinlock_t *ptl;
int file_rss = 0;
@@ -726,6 +727,11 @@ static unsigned long zap_pte_range(struc
add_mm_rss(mm, file_rss, anon_rss);
arch_leave_lazy_mmu_mode();
+ if (details && details->madv_free) {
+ /* Protect against MADV_DONTNEED or unmap_mapping_range */
+ tlb_finish_mmu(tlb, start_addr, addr);
+ tlb = tlb_gather_mmu(mm, 0);
+ }
pte_unmap_unlock(pte - 1, ptl);
return addr;
