From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA743E6F095 for ; Fri, 1 Nov 2024 23:48:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F1506B009E; Fri, 1 Nov 2024 19:48:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A1716B00A0; Fri, 1 Nov 2024 19:48:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56B4B6B00A2; Fri, 1 Nov 2024 19:48:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 376FE6B009E for ; Fri, 1 Nov 2024 19:48:41 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DB69D160214 for ; Fri, 1 Nov 2024 23:48:40 +0000 (UTC) X-FDA: 82739166468.20.406C001 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 1C799140006 for ; Fri, 1 Nov 2024 23:48:18 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XnXnosvs; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730504799; a=rsa-sha256; cv=none; b=3EhsmzaLLUAQmR77I80Nefj1ueOLOXy9ubi8C5HowKblNnaFNRVxr0TUnjLLxG0HklKYYq 9jcla6UbXtiVimwQl6uGiv1oMxwWMFSaVQUvOk5wSiimEES+TXHMAJsOLb7DVwhTtanP+G F7PpuEza16O6EjfLxcG/sCB0BuNiwp0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XnXnosvs; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730504799; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=a7tR8G/laHHbmnqgxjvqsyOD3S+7y+2YEz31mSivQDI=; b=ZTgxh2YvYe3B+ZV8GF2F9HQIlWpzAvIVEtlMhg38ZUm4So2ycaGxF8ztBlhjGktZ5TMFXp XDLY458JBTkoWHWcg794rRRO6Ab2vAVlGhAlejmhpmn4SU8IP9o93uTSASf8BrNbIyKqk0 2y1YfokPytnka+vveJWl/5aLxGBWrFM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 34D4E5C0FCF; Fri, 1 Nov 2024 23:47:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88D8EC4CECD; Fri, 1 Nov 2024 23:48:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730504917; bh=21sE4yu3fLR3GE+R+fbN8Kwt1qsk+dJsWr1o3Qpjm84=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XnXnosvsFADcp34ib5vlgimxIxx2hd7Pjef5THJI9VVq5Ojoyv5PIg77XyeSWqkpu 66nPXvTGBe2GebhBXvtmRRmwEtCk6RHvBJXW6UE5brLsMjvfjRq52vt7zjy57ah1L4 TW9+pfOdpOxnHJeZwW7BbBB+PwAmxii+sHR0im5Ij8jEg3EReC9JifYlEDoVOlRsSC WH/IjMU5p8vyRKtPIlhikn2jrYpahswiqsXIGxGWZ8Yc/oSThSDzBdSkhZZ6lcSrvo SOb6qjGufmi09tVcOozs2eIJlHpLpdh0ReTQ9UOP47rKb7ityr7c6maIluBPiYmE6L X2IiZu85paz9w== From: SeongJae Park To: Lorenzo Stoakes Cc: SeongJae Park , Jonathan Corbet , Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Alice Ryhl , Boqun Feng , Matthew Wilcox , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Suren Baghdasaryan , linux-doc@vger.kernel.org Subject: Re: [RFC PATCH] docs/mm: add VMA locks documentation Date: Fri, 1 Nov 2024 16:48:32 -0700 Message-Id: <20241101234832.56873-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <8e02f3a4-d498-401d-aaba-e53ed2ac6a3a@lucifer.local> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 1C799140006 X-Stat-Signature: 6k93n8679uy3i36wde49je5bg1ujuwea X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1730504898-161399 X-HE-Meta: U2FsdGVkX1+9cLfQMPF/Pqiln975IQ+/nkwEHVjcPjMn0EZYFKccPrTeHvXGBNWquNbo8Uf8IOm1kctgFIS28OBEhILkYW3VDtCK3hq76qLVuvtgBQx1U4f98ySL+gayqb5KsVUQ/OdqMnZ4sJFdkb/05X4xG8lKVI7sVFx673K+8dgJcXq4KmyP8xMB0tG1Vm8pLZ+ETmRwE/kxl2Y4cNoI5XOJMf6ZL1xnOFDo/dP3G4MQ/k9mt/LNKriULTwO8bPMfHqvh+b7oHyjxSlMyYZy73JgONDm9AZpQBtEIoT1FCVfT7sS3MjhqkHh6Lh7AXh8h+tpHyMCA8oS1Vs5vPZ2XBMCUjZBDym5/yHx7L+FSLjN0Fu60NmfbnJV8qMbMgXa8R9DrfhU+x95Gz0zGN4BT6nLI4sFWs8YhbB/vFZepcOceid9p3Jg17N339bchQRgq3YiIiCdvOmY08+5QZDv6xOinp2zCRIOpLwQ2I9fXY2jYfbigC+uvHnNnShFsZJvSjxyGI4CsgH1Tt2rNPffoRxxGEiKDA566a9zZrnluZQXcLo2ypfYVooR/h30Z3AzMHsp3UYBDDma+6QD/FUaf+JXt955LkLGsb+92kIjxttC8tVS5lMvdCLX4pNCOQvP2d7PR8xmfXMrFb+cxWIQz4LVCyS4ASw86e4gTnZlNNTis06wLknMpj5+YN3RFIfw/P+upezjYnQmmwgPWGB74T4FjjmDqG2yPcwa7DqlkmUZAT65slgkr2lHSnxKtev8lsOvNcI94Gu9IhatN0mIYOUILLd2FwE/n2hxcwTi9IBAVJe5k4PKzzkaB70oT37DP5+l1Q7UkhDR9PswsTrep1fSg9xzwhdLb1F1zdJUsN7TYj4fbIsDkVHLJnupC3L1Pb3lQWLTneoAB4c718jTRZlKky7nIBCSWavnl62kkXnpWQxNzSyQy1mBqDqfTZE34+9w8bIje2inUrS A9N9lzRV 5leXt1w124ugCLNg6gu1/okaqbJXf4n+07M9CEakSyWuPV7Tm+hAaeCE5g7siRqTUznQR24jrtBOHvjXb0RfIx3hY9C4SpRgh1pwGjurNWxOU93UCzMJ3ZboR2p3Jbq6kbNeonW6TFbl/7h5Yn0jzFemT7CHEp68VIDmMUd5b+bksr53vi/Ih4KhFjvN/qd4Sid58Dk1BP5v4SPqVYy2lzQLby6QYScM7DcwfsmIOTgN5hkukMFcJ+gwUImDnjCwtuUIHX5MVlWx3GspRn/kfLOvKo0lxLndbvFueF10j3HH/efUNnMeYgNiQJvuqNd1Xh9a7aihJVhCCTkRHSirb6Af5QEPiHXpkLuhEVsU4Rp80Y3ZkjTteLGYV1TP5j385WTGL017AFj0pvREJgEoIOJzMvWYOZ89p0wf5 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 1 Nov 2024 20:58:39 +0000 Lorenzo Stoakes 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 Acked-by: SeongJae Park > > --- > > > > 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 [...]