aboutsummaryrefslogtreecommitdiffstats
path: root/rust/helpers/slab.c
diff options
context:
space:
mode:
authorRyan Roberts <[email protected]>2025-06-06 09:28:07 +0000
committerAndrew Morton <[email protected]>2025-06-12 05:42:35 +0000
commit383c4613c67c26e90e8eebb72e3083457d02033f (patch)
tree72d7a64a154380b2d51e58772defca4256a233ff /rust/helpers/slab.c
parentmm/vma: reset VMA iterator on commit_merge() OOM failure (diff)
downloadkernel-383c4613c67c26e90e8eebb72e3083457d02033f.tar.gz
kernel-383c4613c67c26e90e8eebb72e3083457d02033f.zip
mm: close theoretical race where stale TLB entries could linger
Commit 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries") described a theoretical race as such: """ Nadav Amit identified a theoretical race between page reclaim and mprotect due to TLB flushes being batched outside of the PTL being held. He described the race as follows: CPU0 CPU1 ---- ---- user accesses memory using RW PTE [PTE now cached in TLB] try_to_unmap_one() ==> ptep_get_and_clear() ==> set_tlb_ubc_flush_pending() mprotect(addr, PROT_READ) ==> change_pte_range() ==> [ PTE non-present - no flush ] user writes using cached RW PTE ... try_to_unmap_flush() The same type of race exists for reads when protecting for PROT_NONE and also exists for operations that can leave an old TLB entry behind such as munmap, mremap and madvise. """ The solution was to introduce flush_tlb_batched_pending() and call it under the PTL from mprotect/madvise/munmap/mremap to complete any pending tlb flushes. However, while madvise_free_pte_range() and madvise_cold_or_pageout_pte_range() were both retro-fitted to call flush_tlb_batched_pending() immediately after initially acquiring the PTL, they both temporarily release the PTL to split a large folio if they stumble upon one. In this case, where re-acquiring the PTL flush_tlb_batched_pending() must be called again, but it previously was not. Let's fix that. There are 2 Fixes: tags here: the first is the commit that fixed madvise_free_pte_range(). The second is the commit that added madvise_cold_or_pageout_pte_range(), which looks like it copy/pasted the faulty pattern from madvise_free_pte_range(). This is a theoretical bug discovered during code review. Link: https://lkml.kernel.org/r/[email protected] Fixes: 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries") Fixes: 9c276cc65a58 ("mm: introduce MADV_COLD") Signed-off-by: Ryan Roberts <[email protected]> Reviewed-by: Jann Horn <[email protected]> Acked-by: David Hildenbrand <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Mel Gorman <mgorman <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
Diffstat (limited to 'rust/helpers/slab.c')
0 files changed, 0 insertions, 0 deletions