On Fri, Nov 01, 2024 at 04:48:32PM -0700, SeongJae Park wrote: > On Fri, 1 Nov 2024 20:58:39 +0000 Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> 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@xxxxxxxxxx> > > Acked-by: SeongJae Park <sj@xxxxxxxxxx> Thanks :) > > > > --- > > > > > > 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? Well, at the moment it's sort of a WIP thing that we may want to put under another section, was just putting there somewhat arbitrarily for now. I also wanted to avoid too much debate about what to put where :P But absolutely, ack, will either sort it there or put it somewhere more sensible, thanks! > > > Thanks, > SJ > > [...]
