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 0B738C369AB for ; Tue, 15 Apr 2025 16:15:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7CAFA28008A; Tue, 15 Apr 2025 12:15:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77BA428001A; Tue, 15 Apr 2025 12:15:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66B2828008A; Tue, 15 Apr 2025 12:15:00 -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 44D6A28001A for ; Tue, 15 Apr 2025 12:15:00 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EE7F3816CA for ; Tue, 15 Apr 2025 16:15:01 +0000 (UTC) X-FDA: 83336777202.17.8636055 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf13.hostedemail.com (Postfix) with ESMTP id 1F40B2000E for ; Tue, 15 Apr 2025 16:14:59 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=yxQMFXnb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744733700; a=rsa-sha256; cv=none; b=K5rokiHxOmixXEuNN2xxRWebbgF9LBuREAjLkm/I0NH21BHq5FWH0fJneHP2qn1mzw35er 8/d/ZT1aUJrb4IIdXqyA2z35bvX0+zh1wmAgWaiD0GF/Y5qRRS7T/W1+F+xPZ6TWZsPJGj ILs/EMtJlELucCqL8nnAW0BAGmyeOPY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=yxQMFXnb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744733700; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=csMZwIekDeMOlvlPV6qqAoZIV9Bpm+l1vvN5nrjAYV8=; b=NDbCW65cuBfQHsvNtZKX2VQdMA/1YCKUT8pXJLtiFAn+OwLhguD8AO1NRAbQX3BaAtnDgT 7gRJsMqVWJs4oqCprRR8BZxN5/UhP02pc+CCTDdkQg25oi3B3K0LDWDrh6FOH8oY2HMyxZ +Tp52aqRNCRVfqnLnp7WNtE4EzGRedw= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-4769e30af66so401621cf.1 for ; Tue, 15 Apr 2025 09:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744733699; x=1745338499; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=csMZwIekDeMOlvlPV6qqAoZIV9Bpm+l1vvN5nrjAYV8=; b=yxQMFXnbjKOumHBWB2AHWOxlkCUddX2/CxZz+abkuKrUcxVKDq9APkmKdlbcSrlPP7 ymf8qfwg+Fpylyecij5npX8iHwPcf+74yMS6pKUdlty6InB8oQMBdIbvOAYp8/vXqZ0X rEmxxfqYrgOG+JZXmwTk2/GqusqBJ5g8IyVMFMNKk3beJg3wnMtF+QRPnQiKEsDY0urf UFDVrqHNIZVP7d+U2m7FeNudLYbOM1rDqzsisDRwDE0mtONfiovP2EFaoV+BEQHrFpBT 0N+hFrNw/l5wS5r5m3ee3zaGHnbtfIRYf+g5sWmqpZwJ+BPpkTg+NV/fOVM4RqF869YN RgWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744733699; x=1745338499; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=csMZwIekDeMOlvlPV6qqAoZIV9Bpm+l1vvN5nrjAYV8=; b=iZW7sRIxE/fNkVrn1fxus9oHO21xG1z8/zshMeac0YJnxu3EUdLBI+6Yb+a1gt8dEk y3DDWTj1Y+MlMH5QFhNc+siuPICtMeeCXZWw9nlKEt17bqvHi356xes27TZhOnHkymZM 8MGRjn3SkcmV+oediuQWTj8LnBViD0UoB3qa1w2yUqjuAy760gryOY5MSZc6fYl4S1Ya Bnzgqai2NBju2BBmIU5KtrnChGMYTHKG6FWm2tfTyeWfjjjdRdvUeleIsN/pACe+nGwF XSCrfXP+l/4GQH/uTg1YVK4rwxFVXOiHbGpoZnzpzNtpDY4A2DW7HTL7Qjy5VswQdV0B U1lw== X-Forwarded-Encrypted: i=1; AJvYcCVqjk8HhcGH34jNhT2kX3fE2ZpuAk0it7g/sD/SxUqt6vYyvc0dFA8R25KnmLSJcir0urhf0fhZvg==@kvack.org X-Gm-Message-State: AOJu0YywZrhNISRhfAtbyhP14E0H2mex11u9EW2vKr+el8e+AQO06YDy XFnbTg2v7qhPZsX5Pu556sxSCkgF7emni67XLi/U0rl5CrJr/oYeNKjH6weVxpQla5kkIYhcPs1 8wyPVfxwKi0TL8LQi1gp2YIMMq6jrFlVEBKUo X-Gm-Gg: ASbGncucnPQSrtnPuhG6k3DInt4+lAj4auwQmF8h/wKPShcjqqOyorzGr8BWYoSSW1M SBrVAC192C9GWHLZEsv34b7ts2Zt2SQ5yZqbkdc/KKrvb36zbyd5r/tlJ9UTMnXeCMTOz6HbME9 TZjfJHy6gz5V0QmdqMBzOQr9qxcXoKdusVd3hM3fgBao2b3PpY5YwHKt3AnEAbyvI= X-Google-Smtp-Source: AGHT+IEJT4pa8qiAKf9nDLAc8QLQO3diLkASwchu6JQEwlG20BFOwTnhbHjQ6zqw5f5vL2dxcfxSIn/aOQ7QqKsa0yY= X-Received: by 2002:a05:622a:1890:b0:477:852d:ead6 with SMTP id d75a77b69052e-47a53030602mr4775251cf.0.1744733698609; Tue, 15 Apr 2025 09:14:58 -0700 (PDT) MIME-Version: 1.0 References: <0722c3fe0cb4c1e54ce01c7689ce4615ecc87e16.1744720574.git.lorenzo.stoakes@oracle.com> <0e796032-4f6d-4b7c-9ce6-6519f8f245af@lucifer.local> In-Reply-To: <0e796032-4f6d-4b7c-9ce6-6519f8f245af@lucifer.local> From: Suren Baghdasaryan Date: Tue, 15 Apr 2025 09:14:47 -0700 X-Gm-Features: ATxdqUGyJhc8pIliv4mVwyKYOFhh4IW_k8OSWcd9OMpOe-l2NcmDUrBamTm_pn8 Message-ID: Subject: Re: [PATCH 2/2] MAINTAINERS: add section for locking of mm's and VMAs To: Lorenzo Stoakes Cc: "Liam R. Howlett" , Shakeel Butt , Jann Horn , Andrew Morton , Vlastimil Babka , Matthew Wilcox , "Paul E . McKenney" , SeongJae Park , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 1F40B2000E X-Rspamd-Server: rspam04 X-Stat-Signature: 7prr5zjx9trzmjwzhzk7rn88hcpoo6c3 X-HE-Tag: 1744733699-496262 X-HE-Meta: U2FsdGVkX1/vVe4swjPTRUuotLygJH78UoNgOmZVJAzz1vi68IbkWh35fa10yLMrs+odefiCQn7V2UrbSPfl4TGatMs6y/OiqaEm5zlv1TP6016Rj776AwWc0VqyixzJoHsqa2gEoIYH7uQF3SSnXOGX1uMz7a0IPA9rrJ4GTLB+vKzBRJiSg7KdrwK62u4BUMvQL7YdUUf/nNKddmwTCMik2Ro6Vb3dYbTVkO3wNwsORi7d2MlddN4Kqwf1oHDsHfHS69GZJanBHA5gaeleF0ftPZi6+CNzXOguZVMWlo1DChgi2U5fs3nfTJEH4ayYoQK7Q/f7z9lAaYL+vaAeNZcWaVx0QgZVKnFKU8didd0k1Mg35OUhab/klhlxs+6pvfTvc9TJG7/FkEgnAxQWfg+9v7Sjaz7a1yxQxAH5qs8U9sHF796elJrv/PzJDPXm6lfYZSm913mLvQ39rrzv/TZGQnm8MLOUlmSV03FMbA+MBEVy7gKe7JyvBhOccqLkgRqIP59ko4dSVyTi3kBViC6GQCeZhuSWDVDlWX5QFw+yra6wiL0bzu8v+pjbdivRC5ueejA6WdBkiulQiH+KMLN7jAV/SmGJL2+KnzmJ7wA0Q9xMp2BdmqjLVh/GN7hZF9M0+Kykkm2xBGraJFXkwRKhq3M2UKKvawL8QKljNFE33J8dE+U4/dxFFr7+oXbuDP7RIOEnM2iPqw5zx35J8CG40H4ADbVeVTv9TaXOFmhkzCylV1Glqb9RaERPXJhDipHPpl2ndTlNGVcvtzS+D1uzcTsngeXg28YmOg4gXN5qkfsbdcucmdnNkqAKm4jv37kuIvv5xNx5fhNg+yZb0ziRupcOhnLmXiWxuSwYE2WSF2cqYzHnkLOUOPEf+f/LMaQ1ZteugcuuKsahVxWXwYPhxzCKBrYIdMfmtaZ6DHG38NwiTdrfjm6AFplz4JpnDtaFDeUqjsASQncM6jl bExePVPj oXnABdfPpcvpQ92vTHtUfvpfQECExGoh6IuuEiljLyLo9+8HqseofgBS/goJ8izhdYRwSyBSk/i2LJUzUogtw6muk+96eZDp8Jzff42Htt2ytDAp67mox2cGIKLQ8HItbaIVvvmYKeNrW1LW5JJf6ycv3sYHejzjFR1cadRIlrsb3e5DqOP6VIlrFBAutIQKdQhM8bHNjjWb7Lk6WA2pAE6ayWGcC25vT7icvKCPrVcU6FQUxQvssklNW162l3/WZh5McWI1KA5zpEoJ+7r0cfxO9m8IFnheglt4AS6ejl5jKULxW5lHhZHrsBRF2rE0KPyOoz9SEo/T4tUSAWGEY7+h5NozibYPJmTrg9gGdah4gswuSuozKnRm9JjEPQYfjlrnDd6bNZdmESULy+Ka8Q1EEaw3+jF585UPYgqT5MiNfONK/VmApYvU2zfAttP5CfiUm 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 8:43=E2=80=AFAM 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 w= e have > > > separated out mmap/vma locking logic into the mmap_lock.c and mmap_lo= ck.h > > > files, so this should encapsulate the majority of the mm locking logi= c 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 Reviewed-by: Suren Baghdasaryan > > > --- > > > 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 th= is > area and being involved in the meetings and documenting, though I'd large= ly > defer to Suren who was the true expertise, and I also feel Liam has bette= r > knowledge than I do. > > So I suggest probably, unless there are other viable and active takers, w= e > should M myself and you Liam? Thanks for trusting me with the maintenance. I'll do my best not to betray = it. I agree that you and Liam have reviewed this code enough times to make informed decisions. Other good candidates include Jann and Vlastimil. David already reviews the entire mm codebase, so adding him is probably unnecessary. > > > > > 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 :), though = I > _don't think_ either Shakeel or Jann really actively work with mmap/VMA > locks (forgive me if I am mistaken) so wouldn't really be suitable for M = as > I feel that requires some active development. > > > > > > + > > > MEMORY MAPPING - MADVISE (MEMORY ADVICE) > > > M: Andrew Morton > > > M: Liam R. Howlett > > > -- > > > 2.49.0 > > >