All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lstoakes@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	upstream+pagemap@sigma-star.at, adobriyan@gmail.com,
	wangkefeng.wang@huawei.com, ryan.roberts@arm.com,
	hughd@google.com, peterx@redhat.com, david@redhat.com,
	avagin@google.com, vbabka@suse.cz, akpm@linux-foundation.org,
	usama.anjum@collabora.com, corbet@lwn.net
Subject: Re: [PATCH 2/2] [RFC] pagemap.rst: Document write bit
Date: Sun, 10 Mar 2024 22:14:04 +0000	[thread overview]
Message-ID: <Ze4wrHL6DEQJl_Oo@devil> (raw)
In-Reply-To: <20240306232339.29659-2-richard@nod.at>

On Thu, Mar 07, 2024 at 12:23:39AM +0100, Richard Weinberger wrote:
> Bit 58 denotes that a PTE is writable.
> The main use case is detecting CoW mappings.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>  Documentation/admin-guide/mm/pagemap.rst | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst
> index f5f065c67615..81ffe3601b96 100644
> --- a/Documentation/admin-guide/mm/pagemap.rst
> +++ b/Documentation/admin-guide/mm/pagemap.rst
> @@ -21,7 +21,8 @@ There are four components to pagemap:
>      * Bit  56    page exclusively mapped (since 4.2)
>      * Bit  57    pte is uffd-wp write-protected (since 5.13) (see
>        Documentation/admin-guide/mm/userfaultfd.rst)
> -    * Bits 58-60 zero
> +    * Bit  58    pte is writable (since 6.10)

I really think we need to be careful about talking about 'writable' again
because people are easily confused about the difference between a writable
_mapping_ and a writable _page table entry_.

Of course you mention PTE here, but I think it might be better to say
something like:

    * Bit  58    raw pte r/w flag (since 6.10)

> +    * Bits 59-60 zero
>      * Bit  61    page is file-page or shared-anon (since 3.5)
>      * Bit  62    page swapped
>      * Bit  63    page present
> @@ -37,6 +38,11 @@ There are four components to pagemap:
>     precisely which pages are mapped (or in swap) and comparing mapped
>     pages between processes.
>
> +   Bit 58 is useful to detect CoW mappings; however, it does not indicate
> +   whether the page mapping is writable or not. If an anonymous mapping is
> +   writable but the write bit is not set, it means that the next write access
> +   will cause a page fault, and copy-on-write will happen.
> +

David has addressed the copy vs. anon exclusive remap issue, but I also
feel this needs some balking out.

I would simply rephrase this in terms of whether a write fault occurs or
not e.g.:

   Bit 58 indicates whether the PTE has the write flag set. If this flag is
   unset, then write accesses for this mapping will cause a fault for this
   page. If the mapping is private (whether anonymous or file-backed), this
   can result in a Copy-on-Write (though if anonymous-excusive the flag
   will simply be set). If file-backed, this being cleared may simply
   indicate that this file page is clean.

>     Efficient users of this interface will use ``/proc/pid/maps`` to
>     determine which areas of memory are actually mapped and llseek to
>     skip over unmapped regions.
> --
> 2.35.3
>

  parent reply	other threads:[~2024-03-10 22:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 23:23 [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable Richard Weinberger
2024-03-06 23:23 ` [PATCH 2/2] [RFC] pagemap.rst: Document write bit Richard Weinberger
2024-03-07 10:52   ` David Hildenbrand
2024-03-07 11:10     ` Richard Weinberger
2024-03-07 11:15       ` David Hildenbrand
2024-03-10 22:14   ` Lorenzo Stoakes [this message]
2024-03-07 10:44 ` [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable Muhammad Usama Anjum
2024-03-07 10:52 ` David Hildenbrand
2024-03-07 11:10   ` Richard Weinberger
2024-03-07 11:20     ` David Hildenbrand
2024-03-07 11:51       ` Richard Weinberger
2024-03-07 11:59         ` David Hildenbrand
2024-03-07 12:09           ` David Hildenbrand
2024-03-07 14:42             ` Richard Weinberger
2024-03-10 21:55 ` Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ze4wrHL6DEQJl_Oo@devil \
    --to=lstoakes@gmail.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@google.com \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=richard@nod.at \
    --cc=ryan.roberts@arm.com \
    --cc=upstream+pagemap@sigma-star.at \
    --cc=usama.anjum@collabora.com \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.