On 9/22/26 17:35, Lorenzo Stoakes (ARM) wrote: > Now that page tables are freed after an RCU grace period, it is safe for > read-only page table walkers to walk page table ranges that are being > concurrently torn down, provided the mm is kept alive via mmgrab(). > > It is however unsafe for writers to do so, as they must obtain an > appropriate lock to do so safely. > > Update the pte_offset_map_lock()'s comment block to reflect this. > > Similarly update the process addresses documentation. > > Acked-by: Kiryl Shutsemau (Meta) <[email protected]> > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > --- > Documentation/mm/process_addrs.rst | 6 ++++++ > mm/pgtable-generic.c | 15 +++++++++++---- > 2 files changed, 17 insertions(+), 4 deletions(-) > > diff --git a/Documentation/mm/process_addrs.rst > b/Documentation/mm/process_addrs.rst > index a7296f251799..b1f4f44d75eb 100644 > --- a/Documentation/mm/process_addrs.rst > +++ b/Documentation/mm/process_addrs.rst > @@ -537,6 +537,12 @@ We establish basic locking rules when interacting with > page tables: > * When changing a page table entry the page table lock for that page table > **must** be held, except if you can safely assume nobody can access the > page > tables concurrently (such as on invocation of :c:func:`!free_pgtables`). > +* Page tables may be *walked* under RCU alone, as page tables are freed only > + after an RCU grace period has elapsed. However, any entry found must be > + revalidated after the page table lock is taken (such as the > + :c:func:`!pmd_same` recheck performed by :c:func:`!pte_offset_map_lock`) > + before it is acted upon. Changing an entry requires the page table > + lock and one of the locks that excludes teardown (mmap or VMA lock).
While we can walk the page tables, I assume there are some limits to what we can actually do with leaf entries. E.g., Doing a careless pte->folio lookup might be dangerous. I wonder if we want to hint at that here: that walking under RCU (traversing page tables) is something different than actually operating on the leaf entries. Apart from that LGTM. -- Cheers, David
