Message-ID: <aEIofgUdu5z5USfD@archie.me>
Date: Fri, 6 Jun 2025 06:30:06 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc: Suren Baghdasaryan <surenb@...gle.com>,
	"Liam R . Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Jonathan Corbet <corbet@....net>, Jann Horn <jannh@...gle.com>,
	Qi Zheng <zhengqi.arch@...edance.com>, linux-mm@...ck.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] docs/mm: expand vma doc to highlight pte freeing,
 non-vma traversal

On Wed, Jun 04, 2025 at 07:03:08PM +0100, Lorenzo Stoakes wrote:
> diff --git a/Documentation/mm/process_addrs.rst b/Documentation/mm/process_addrs.rst
> index e6756e78b476..be49e2a269e4 100644
> --- a/Documentation/mm/process_addrs.rst
> +++ b/Documentation/mm/process_addrs.rst
> @@ -303,7 +303,9 @@ There are four key operations typically performed on page tables:
>  1. **Traversing** page tables - Simply reading page tables in order to traverse
>     them. This only requires that the VMA is kept stable, so a lock which
>     establishes this suffices for traversal (there are also lockless variants
> -   which eliminate even this requirement, such as :c:func:`!gup_fast`).
> +   which eliminate even this requirement, such as :c:func:`!gup_fast`). There is
> +   also a special case of page table traversal for non-VMA regions which we
> +   consider separately below.
>  2. **Installing** page table mappings - Whether creating a new mapping or
>     modifying an existing one in such a way as to change its identity. This
>     requires that the VMA is kept stable via an mmap or VMA lock (explicitly not
> @@ -335,15 +337,13 @@ ahead and perform these operations on page tables (though internally, kernel
>  operations that perform writes also acquire internal page table locks to
>  serialise - see the page table implementation detail section for more details).
> 
> +.. note:: We free empty PTE tables on zap under the RCU lock - this does not
> +          change the aforementioned locking requirements around zapping.
> +
>  When **installing** page table entries, the mmap or VMA lock must be held to
>  keep the VMA stable. We explore why this is in the page table locking details
>  section below.
> 
> -.. warning:: Page tables are normally only traversed in regions covered by VMAs.
> -             If you want to traverse page tables in areas that might not be
> -             covered by VMAs, heavier locking is required.
> -             See :c:func:`!walk_page_range_novma` for details.
> -
>  **Freeing** page tables is an entirely internal memory management operation and
>  has special requirements (see the page freeing section below for more details).
> 
> @@ -355,6 +355,44 @@ has special requirements (see the page freeing section below for more details).
>               from the reverse mappings, but no other VMAs can be permitted to be
>               accessible and span the specified range.
> 
> +Traversing non-VMA page tables
> +------------------------------
> +
> +We've focused above on traversal of page tables belonging to VMAs. It is also
> +possible to traverse page tables which are not represented by VMAs.
> +
> +Kernel page table mappings themselves are generally managed but whatever part of
> +the kernel established them and the aforementioned locking rules do not apply -
> +for instance vmalloc has its own set of locks which are utilised for
> +establishing and tearing down page its page tables.
> +
> +However, for convenience we provide the :c:func:`!walk_kernel_page_table_range`
> +function which is synchronised via the mmap lock on the :c:macro:`!init_mm`
> +kernel instantiation of the :c:struct:`!struct mm_struct` metadata object.
> +
> +If an operation requires exclusive access, a write lock is used, but if not, a
> +read lock suffices - we assert only that at least a read lock has been acquired.
> +
> +Since, aside from vmalloc and memory hot plug, kernel page tables are not torn
> +down all that often - this usually suffices, however any caller of this
> +functionality must ensure that any additionally required locks are acquired in
> +advance.
> +
> +We also permit a truly unusual case is the traversal of non-VMA ranges in
> +**userland** ranges, as provided for by :c:func:`!walk_page_range_debug`.
> +
> +This has only one user - the general page table dumping logic (implemented in
> +:c:macro:`!mm/ptdump.c`) - which seeks to expose all mappings for debug purposes
> +even if they are highly unusual (possibly architecture-specific) and are not
> +backed by a VMA.
> +
> +We must take great care in this case, as the :c:func:`!munmap` implementation
> +detaches VMAs under an mmap write lock before tearing down page tables under a
> +downgraded mmap read lock.
> +
> +This means such an operation could race with this, and thus an mmap **write**
> +lock is required.
> +
>  Lock ordering
>  -------------
> 
> @@ -461,6 +499,10 @@ Locking Implementation Details
>  Page table locking details
>  --------------------------
> 
> +.. note:: This section explores page table locking requirements for page tables
> +          encompassed by a VMA. See the above section on non-VMA page table
> +          traversal for details on how we handle that case.
> +
>  In addition to the locks described in the terminology section above, we have
>  additional locks dedicated to page tables:
> 

The wording looks good, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@...il.com>

-- 
An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists