>
> it seems we have a smp race in zap_page_range():
>
> When we remove a page from the page tables, we must call:
>
> flush_cache_page();
> pte_clear();
> flush_tlb_page();
> free_page();
>
> We must not free the page before we have called flush_tlb_xy(),
> otherwise the second cpu could access memory that already freed.
>
> but zap_page_range() calls free_page() before the flush_tlb() call.
>
> Is that really a bug, has anyone a good idea how to fix that?
Why do you think this is a bug? After the pte_clear, we need to flush
tlb, so that if anyone wants to drag in the mapping (by accessing the
virtual address), he will fault (since translation is not in tlb) and
wait on mmap_sem. After that, when zap_page_range has freed the page,
and released the mmap_sem, the faulter will find he was trying to access
what is now invalid memory and get a signal/killed.
But a race does exist in establish_pte(), when the flush_tlb happens
_before_ the set_pte(), another thread might drag in the old translation
on a different cpu.
>
> filemap_sync() calls flush_tlb_page() for each page, but IMHO this is a
> really bad idea, the performance will suck with multi-threaded apps on
> SMP.
The best you can do probably is a flush_tlb_range?
Kanoj
>
> Perhaps build a linked list, and free later?
> We could abuse the next pointer from "struct page".
> --
> Manfred
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux.eu.org/Linux-MM/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:12 EST