Hello arch and mm people.
Is it intentional that threads of a process that invoked munmap syscall
can see TLB entries pointing to already freed pages, or it is a bug?
I'm talking about zap_pmd_range and zap_pte_range:
zap_pmd_range
zap_pte_range
arch_enter_lazy_mmu_mode
ptep_get_and_clear_full
tlb_remove_tlb_entry
__tlb_remove_page
arch_leave_lazy_mmu_mode
cond_resched
With the default arch_{enter,leave}_lazy_mmu_mode, tlb_remove_tlb_entry
and __tlb_remove_page there is a loop in the zap_pte_range that clears
PTEs and frees corresponding pages, but doesn't flush TLB, and
surrounding loop in the zap_pmd_range that calls cond_resched. If a thread
of the same process gets scheduled then it is able to see TLB entries
pointing to already freed physical pages.
I've noticed that with xtensa arch when I added a test before returning to
userspace checking that TLB contents agrees with page tables of the
current mm. This check reliably fires with the LTP test mtest05 that
maps, unmaps and accesses memory from multiple threads.
Is there anything wrong in my description, maybe something specific to
my arch, or this issue really exists?
I've also noticed that there are a lot of arches with default implementations
of the involved functions, does that mean that any/all of them have this
issue too?
--
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
