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 32600C369BA for ; Tue, 15 Apr 2025 18:01:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B673280010; Tue, 15 Apr 2025 14:01:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4657C28000F; Tue, 15 Apr 2025 14:01:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32C3F280010; Tue, 15 Apr 2025 14:01:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0B30028000F for ; Tue, 15 Apr 2025 14:01:02 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 040291C8EB6 for ; Tue, 15 Apr 2025 18:01:02 +0000 (UTC) X-FDA: 83337044406.12.ABF9A69 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) by imf30.hostedemail.com (Postfix) with ESMTP id 2E33380005 for ; Tue, 15 Apr 2025 18:01:00 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="ax5/05cm"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf30.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744740061; a=rsa-sha256; cv=none; b=kpNDdEgriRTYi4eDtNE2POpZd58maW1DHVbWBrvYnOEqsLyYTsn2Wv7Ts1yQQm56zz1fjl 8BLPg9AkewYIS/J50UDlRii0Z7R5GPv7PVzF47LWihaqnnN/x7HiZoGUYC7l4XdzHb8krD PlfaQyI8OitkN9g0k6ZHIgCJV3PmeLI= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="ax5/05cm"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf30.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744740061; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1Mo25pBuBWiN307HIbqRzDBZRU7fU/K2LqdF6ML5T2o=; b=nhO2lDpqKHMeFOXg1lTTrxdNNiAZ1jl+xfT0PgOMbW8dTEhboaZv3Ko7JqLfuV/hgyNn00 Xm4wIQfyvxrhUhITjmEea3RpjvdzigwX8VwpcNCLVt0goX9kOL00T6946B1X2x0yVW/6hZ zTEyQf047eGg658O93hO4Obm/ylHEfA= Date: Tue, 15 Apr 2025 11:00:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1744740059; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1Mo25pBuBWiN307HIbqRzDBZRU7fU/K2LqdF6ML5T2o=; b=ax5/05cmrpg2/AeaSBKsb2/ealQFqKIK4UHWFFhwkppTdUcbnPQIiCF1SQn3VD+10qsAyU IBm0Wto5C8Z7bRZgIFvzEd+gYNyPqV1FbBnsE3lZS4cSui65FvUtTf6hzWc0Dnd9WVJJ4r WwPyk3jbp1rgUBWSdpPfAIs7Ty3kvOw= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Lorenzo Stoakes Cc: "Liam R. Howlett" , Jann Horn , Andrew Morton , Suren Baghdasaryan , Vlastimil Babka , Matthew Wilcox , "Paul E . McKenney" , SeongJae Park , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/2] MAINTAINERS: add section for locking of mm's and VMAs Message-ID: References: <0722c3fe0cb4c1e54ce01c7689ce4615ecc87e16.1744720574.git.lorenzo.stoakes@oracle.com> <0e796032-4f6d-4b7c-9ce6-6519f8f245af@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e796032-4f6d-4b7c-9ce6-6519f8f245af@lucifer.local> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 2E33380005 X-Rspamd-Server: rspam04 X-Stat-Signature: jmkx8kx8guew6dhkskuwnwseqsmqqcw9 X-HE-Tag: 1744740060-224562 X-HE-Meta: U2FsdGVkX18AHuTayuNpRs0CQL+jtzkIFSyqx0ZlWQm7st9jAvkO415keiTfPx57s7Wek2+g91bdD7+FM6doaJH/efgUBpbyl/B8Y6YzCdaHKLw84r4CD0WXfxwkzCtQE0uVPhGVDD8EqdhCjSsc867ExQPK40vkgAMtVd/pRWTkux5Cz0b5sp+AXgEC6/ygaIVpHh958c/BUZcPVRfjGt2KffalmOfMoV17EKNfcHhPq35TqRLAQbmk6O0JOuDcKA+iUfWx/2NLDbodFJWXBtUV2zMIn/fy1oIfvaCcAby31fxDe0mrYrs3oj2EW82TJ7bZ7WnoyWI0JkDwfS/mpaFcZQqRqxQ78/NIO8So2u8afE0okaWkwO4mZ6jKXwV1s4UbzT83vDtQwpBXwMjKJfjFtV35aQ+uwmIXmgd1p3g6MMkHNq40/cpbUT/xD8ZF8MZQV7kG7zd7Ysd/0QaaVxnMDz4dfTo3CzivVH9jDCfqt/Vzd6v9RpKidLj6KlMdXGOk6N3nmGfjRvMJPSAu29IDVrQsBaK0zY4KoSV9Bi7yhdqi6IM2vEM6Nj+TXlLeTg1sjVdSy5+tVC/n1vsoWo7cnHAE/ijx0Ca/zApKe1l0n5TGAezfBcLdssc1+hGrC4TBTPyzvPWpjK6uxkXDKOd2AHJI2wQ2RZZiFTuKfXAJ/g6vPIa7psilkJTQR7WVHh52S3ivFx/3JgezuIY5NgKXLo1+ZYLXBHPJIjVWBzW+moIT1vQHLNiRRU5vzEcz3/he2MjYAuV+PgZOimbYm5+OYBEyXmSW3yO+/aFOealqZ0NHEnI3e/e0zvmZ5Tv2dMSbfwUiiryXZwRciTuXQFBbJLGeCUpTh61pj9rJorhAwLV/LvT3mOtSkS9qI3CMwfMRl3Ww6FWqUW4UwdBA4ApEJvm2mKa8e+FLnp2NWDtNtZxxVAFSMcjXdelQr8N112AXUwgyDqU/XjjPwch YcpYQsn0 DKyPv6ia2pMROkNn2qON89VZoBVIfmNolKwxtV/Zy4rmJ557yPq0mzZlPQ/uOgfLve6V0AUbH31XB5wcDGuACO3nNwSu4bKtkDF/ePv2D8274AKM9veZRxgVtyT7f3ChOt7FltR/GnO9a9FlBv4sNlsMrA+jsA1pugwfUnX+qLa7wtMVV3oRDUtzvNQhd3tHDuCqZRTVh2FZ033qWXg+d8pojljUt4dBrid/HNau2U0q4YtxCZcS0Wd5jFPm3ohQC9XpWLQF/OVwL76ycVlN5WYjHxYHYbGUpUvLYtnFknQXzAMPM9MzbDSaEDk54mtap6VYeK6timDuN0GaA7dwGRlXD/eMsbPQEimOcPeaMZ9A2ht9otzdOH5fOzTtPcy8cnwJAaNmokHeSIvuyDBzRuR14mIffFUfmV5/vAEUtsT+yyDM= 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 Tue, Apr 15, 2025 at 04:43:41PM +0100, Lorenzo Stoakes wrote: > On Tue, Apr 15, 2025 at 11:37:04AM -0400, Liam R. Howlett wrote: > > * Lorenzo Stoakes [250415 09:11]: > > > We place this under memory mapping as related to memory mapping > > > abstractions in the form of mm_struct and vm_area_struct (VMA). Now we have > > > separated out mmap/vma locking logic into the mmap_lock.c and mmap_lock.h > > > files, so this should encapsulate the majority of the mm locking logic in > > > the kernel. > > > > > > Suren is best placed to maintain this logic as the core architect of VMA > > > locking as a whole. > > > > > > Signed-off-by: Lorenzo Stoakes > > > --- > > > MAINTAINERS | 15 +++++++++++++++ > > > 1 file changed, 15 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 8d834514a047..ce55676a16a4 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -15595,6 +15595,21 @@ F: mm/vma_internal.h > > > F: tools/testing/selftests/mm/merge.c > > > F: tools/testing/vma/ > > > > > > +MEMORY MAPPING - LOCKING > > > +M: Andrew Morton > > > +M: Suren Baghdasaryan > > > +R: Liam R. Howlett > > > +R: Lorenzo Stoakes > > > +R: Vlastimil Babka > > > +L: linux-mm@kvack.org > > > +S: Maintained > > > +W: http://www.linux-mm.org > > > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > > +F: Documentation/mm/process_addrs.rst > > > +F: include/linux/mmap_lock.h > > > +F: include/trace/events/mmap_lock.h > > > +F: mm/mmap_lock.c > > > > It would be good to have more M's here in the case Suren is away or > > whatever. > > > > I have worked on the mmap locking due to the maple tree addition, and I > > have helped with vma locking in some areas. > > > > Lorenzo wrote the locking document, which Suren pointed out last mmap > > lock meeting and does make locking changes. > > > > Are there others that could be M here? > > I mean I'm fine to take an M here, based on having done _some_ work in this > area and being involved in the meetings and documenting, though I'd largely > defer to Suren who was the true expertise, and I also feel Liam has better > knowledge than I do. > > So I suggest probably, unless there are other viable and active takers, we > should M myself and you Liam? > > > > > Shakeel and/or Jann might be good additions to this list somewhere > > (looking at the edits to the file). > > Don't mind R in these cases if Shakeel or Jann want of course :), Thanks Liam. I don't mind an R here if you decide to send a new version. Reviewed-by: Shakeel Butt