On Thu, 11 May 2023, Matthew Wilcox wrote: > > I was thinking that removing CONFIG_HIGHPTE might simplify the page > fault handling path a little, but now I've looked at it some more, and > I'm not sure there's any simplification to be had. It should probably > use kmap_local instead of kmap_atomic(), though. Re kmap_local, yes, one of the patches in the next series does make that change. > > I infer that what you need is a pte_access_start() and a > pte_access_end() which look like they can be plausibly rcu_read_lock() > and rcu_read_unlock(), but might need to be local_irq_save() and > local_irq_restore() in some configurations? Yes, except that the local_irq_restore() in PAE-like configurations (if we need it at all) is not delayed until the pte_access_end() or pte_unmap() - it's internal to the pte_access_start() or pte_offset_map(): interrupts only disabled across the getting of a consistent pmd entry. Over-generalizing a little, any user of pte_offset_map() (as opposed to pte_offset_map_lock()) has to be prepared for the ptes to change under them: but we do need to give them something that is or was recently the relevant page table, rather than a random page mishmashed from mismatched pmd_low and pmd_high. > > We also talked about moving x86 to always RCU-free page tables in > order to make accessing /proc/$pid/smaps lockless. I believe Michel > is going to take a swing at this project. (And /proc/$pid/numa_maps, I hope: that's even worse in some way, IIRC.) That might be orthogonal to what I'm doing: many non-x86 architectures already do RCU-freeing of page tables via the TLB route, but that doesn't cover a pte_free() from retract_page_tables() or collapse_and_free_pmd(). Hugh
