On Sun, May 28, 2023 at 11:16:16PM -0700, Hugh Dickins wrote: > There is a faint risk that __pte_offset_map(), on a 32-bit architecture > with a 64-bit pmd_t e.g. x86-32 with CONFIG_X86_PAE=y, would succeed on > a pmdval assembled from a pmd_low and a pmd_high which never belonged > together: their combination not pointing to a page table at all, perhaps > not even a valid pfn. pmdp_get_lockless() is not enough to prevent that. > > Guard against that (on such configs) by local_irq_save() blocking TLB > flush between present updates, as linux/pgtable.h suggests. It's only > needed around the pmdp_get_lockless() in __pte_offset_map(): a race when > __pte_offset_map_lock() repeats the pmdp_get_lockless() after getting the > lock, would just send it back to __pte_offset_map() again. What about the other places calling pmdp_get_lockless ? It seems like this is quietly making it part of the API that the caller must hold the IPIs off. And Jann had a note that this approach used by the lockless functions doesn't work anyhow: https://lore.kernel.org/linux-mm/CAG48ez3h-mnp9ZFC10v+-BW_8NQvxbwBsMYJFP8JX31o0B17Pg@xxxxxxxxxxxxxx/ Though we never fixed it, AFAIK.. Jason
