lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f2c8e125-8436-40dd-81d5-5bda786d54a2@lucifer.local>
Date: Thu, 7 Nov 2024 11:15:02 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Hillf Danton <hdanton@...a.com>
Cc: Boqun Feng <boqun.feng@...il.com>, Jann Horn <jannh@...gle.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] docs/mm: add VMA locks documentation

On Thu, Nov 07, 2024 at 07:07:17PM +0800, Hillf Danton wrote:
> On Fri,  1 Nov 2024 18:50:33 +0000 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> >
> > 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.
> >
> What is missed is the clear guide to the correct locking order.
> Is the order below correct for instance?
>
> 	lock  vma
> 	lock  vma->vm_mm

There's a whole section on lock ordering (albeit, a copy/paste of mm/rmap.c
comment).

However I do agree that I didn't put enough emphasis on lock ordering for VMA
locks.

I'm working on v2 now (aside: my god you won't believe how surprisingly
challenging it is to write docs, I mean you'd think I'd know after book but I
forgot I guess :) where I put a very strong emphasis on this locking order,
including reflecting Suren and Jann's input on read mmap lock vs. vma read lock
(you'd probably not want to bother with vma read lock if you have an mmap read
lock, but the latter has to be taken before the former if you do - the other way
round is a deadlock).

The v2 respin puts a much stronger emphasis on separating a top-level practical
guide to what locks to acquire and where in what order vs. implementation
details as per the valuable feedback on this from Alice + others.

So TL;DR - yes agree absolutely and this is made clearer in v2!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ