linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: SeongJae Park <sj@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Mike Rapoport <rppt@kernel.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Suren Baghdasaryan <surenb@google.com>,
	linux-doc@vger.kernel.org
Subject: Re: [RFC PATCH] docs/mm: add VMA locks documentation
Date: Fri,  1 Nov 2024 16:48:32 -0700	[thread overview]
Message-ID: <20241101234832.56873-1-sj@kernel.org> (raw)
In-Reply-To: <8e02f3a4-d498-401d-aaba-e53ed2ac6a3a@lucifer.local>

On Fri, 1 Nov 2024 20:58:39 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

[...]
> On Fri, Nov 01, 2024 at 06:50:33PM +0000, Lorenzo Stoakes wrote:
> > Locking around VMAs is complicated and confusing. While we have a number of
> > disparate comments scattered around the place, we seem to be reaching a
> > level of complexity that justifies a serious effort at clearly documenting
> > how locks are expected to be interacted with when it comes to interacting
> > with mm_struct and vm_area_struct objects.
> >
> > This is especially pertinent as regards efforts to find sensible
> > abstractions for these fundamental objects within the kernel rust
> > abstraction whose compiler strictly requires some means of expressing these
> > rules (and through this expression can help self-document these
> > requirements as well as enforce them which is an exciting concept).
> >
> > The document limits scope to mmap and VMA locks and those that are
> > immediately adjacent and relevant to them - so additionally covers page
> > table locking as this is so very closely tied to VMA operations (and relies
> > upon us handling these correctly).
> >
> > The document tries to cover some of the nastier and more confusing edge
> > cases and concerns especially around lock ordering and page table teardown.
> >
> > The document also provides some VMA lock internals, which are up to date
> > and inclusive of recent changes to recent sequence number changes.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

Acked-by: SeongJae Park <sj@kernel.org>

> > ---
> >
> > REVIEWERS NOTES:
> >    You can speed up doc builds by running `make SPHINXDIRS=mm htmldocs`. I
> >    also uploaded a copy of this to my website at
> >    https://ljs.io/output/mm/vma_locks to make it easier to have a quick
> >    read through. Thanks!
> >
> >
> >  Documentation/mm/index.rst     |   1 +
> >  Documentation/mm/vma_locks.rst | 527 +++++++++++++++++++++++++++++++++
> >  2 files changed, 528 insertions(+)
> >  create mode 100644 Documentation/mm/vma_locks.rst
> >
> > diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
> > index 0be1c7503a01..da5f30acaca5 100644
> > --- a/Documentation/mm/index.rst
> > +++ b/Documentation/mm/index.rst
> > @@ -64,3 +64,4 @@ documentation, or deleted if it has served its purpose.
> >     vmemmap_dedup
> >     z3fold
> >     zsmalloc
> > +   vma_locks

This is the "Unsorted Documentation" section.  If the document is really for
the section, I'd suggest putting it in alphabetically sorted order, for the
consistency.  However, if putting the document under the section is not your
real intention, I think it might be better to be put under "Process Addresses"
section above.  What do you think?


Thanks,
SJ

[...]


  parent reply	other threads:[~2024-11-01 23:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-01 18:50 Lorenzo Stoakes
2024-11-01 20:58 ` Lorenzo Stoakes
2024-11-01 22:41   ` Suren Baghdasaryan
2024-11-01 23:48   ` SeongJae Park [this message]
2024-11-04 13:02     ` Lorenzo Stoakes
2024-11-04 13:47       ` Mike Rapoport
2024-11-04 19:55         ` Lorenzo Stoakes
2024-11-02  1:45 ` Jann Horn
2024-11-04 16:42   ` Lorenzo Stoakes
2024-11-04 21:29     ` Jann Horn
2024-11-05 16:10       ` Lorenzo Stoakes
2024-11-05 17:21         ` Jann Horn
2024-11-06  3:09       ` Qi Zheng
2024-11-06 18:09         ` Jann Horn
2024-11-07  7:07           ` Qi Zheng
2024-11-06  2:56     ` Qi Zheng
2024-11-06 11:28       ` Lorenzo Stoakes
2024-11-07  6:47         ` Qi Zheng
2024-11-02  9:00 ` Mike Rapoport
2024-11-04 14:17   ` Lorenzo Stoakes
2024-11-04 15:19     ` Mike Rapoport
2024-11-05 12:23       ` Lorenzo Stoakes
2024-11-04 14:47 ` Alice Ryhl
2024-11-04 16:52   ` Lorenzo Stoakes
2024-11-05 13:56     ` Alice Ryhl
2024-11-05 14:18       ` Lorenzo Stoakes
2024-11-04 17:01 ` Suren Baghdasaryan
2024-11-04 21:04   ` Lorenzo Stoakes
2024-11-04 21:20     ` Suren Baghdasaryan
2024-11-05 16:11       ` Lorenzo Stoakes
2024-11-04 21:25     ` Jann Horn
2024-11-07 11:07 ` Hillf Danton
2024-11-07 11:15   ` 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=20241101234832.56873-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=aliceryhl@google.com \
    --cc=boqun.feng@gmail.com \
    --cc=corbet@lwn.net \
    --cc=jannh@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox