This should fix the MADV_FREE code for PPC's hashed tlb. Signed-off-by: Rik van Riel --- Nick Piggin wrote: >> Nick Piggin wrote: >> >>>> 3) because of this, we can treat any such accesses as >>>> happening simultaneously with the MADV_FREE and >>>> as illegal, aka undefined behaviour territory and >>>> we do not need to worry about them >>> >>> >>> Yes, but I'm wondering if it is legal in all architectures. >> >> >> It's similar to trying to access memory during an munmap. >> >> You may be able to for a short time, but it'll come back to >> haunt you. > > The question is whether the architecture specific tlb > flushing code will break or not. I guess we'll need to call tlb_remove_tlb_entry() inside the MADV_FREE code to keep powerpc happy. Thanks for pointing this one out. >> Even then we do. Each invocation of zap_pte_range() only touches >> one page table page, and it flushes the TLB before releasing the >> page table lock. > > What kernel are you looking at? -rc7 and rc6-mm1 don't, AFAIKS. Oh dear. I see it now... The tlb end things inside zap_pte_range() are actually noops and the actual tlb flush only happens inside zap_page_range(). I guess the fact that munmap gets the mmap_sem for writing should save us, though... -- 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.