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 E5647C83F27 for ; Wed, 16 Jul 2025 01:50:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 623156B00B7; Tue, 15 Jul 2025 21:50:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D3C26B00B8; Tue, 15 Jul 2025 21:50:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C2B16B00B9; Tue, 15 Jul 2025 21:50:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3827C6B00B7 for ; Tue, 15 Jul 2025 21:50:36 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D252E5760C for ; Wed, 16 Jul 2025 01:50:35 +0000 (UTC) X-FDA: 83668448430.12.B2FA367 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf09.hostedemail.com (Postfix) with ESMTP id EEC7A140007 for ; Wed, 16 Jul 2025 01:50:33 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Hjo6jHgw; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752630634; a=rsa-sha256; cv=none; b=uJaRa6lOeNYE8Ou2F8doDfU5XC0CooSTDaXllpuEJBUBZbi6sqM5FLxUrZGebifpj7Ce6e HOt4o2Q5SKdGJQLGWCyFAqefE2RuPPXqknJo2ZutpgVPozkePlKc8m/JEsMTR4T3bAMKUS Yqzo4QFDrLPj71v7sSX5ToWkPIoqKDg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Hjo6jHgw; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 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=1752630634; 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=PI+BpmLhrBZFyCshwZnktNusgYyVbEvS1xUVnNwBsk0=; b=XhUD2lil8qUkZ213hqka5mpaZSGApw8Oxo531ZlsG7S5AR54bd0tdeSEPuBguw3W2AFc83 7Sbuh300XYho6xUj2zSBiEyhSAvc31qJJMuHrDmRLpRbRy9QkvNK6rJgaRuM9Nxv4YQHm7 NLIfMFyrb8OHIJO7PNxlizMYjfqbfXk= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-4ab3855fca3so68451cf.1 for ; Tue, 15 Jul 2025 18:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752630633; x=1753235433; 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=PI+BpmLhrBZFyCshwZnktNusgYyVbEvS1xUVnNwBsk0=; b=Hjo6jHgwT8SL/cDQd0wmo9Pe2TkSVBaaBkgT6yvGheLqmOlp++uSP7WVwBI72SneMR IfUUkSumih99AUmOkzOrej1YF7joMPxHvtOnEyvgK2euuknpxQ/XAdgZEft4q3KFbz8X oVOjJB9vMaaV2Yy5IZ08M0Cbfq+nydQ394QC7CzUUgv3kYBisiCeGi4NMYK6DEHl+y2t yKKqWTR8Zwl3/UFoJPBMprrkxMnzC6GJUzdcvvhwCCO/nc+NfyjEzk5INe7yp99JTNcn 4N9+JGs6StAA7bNkHXNGSoNJ6lxM06c2A4tmIaEQelGuk3xIvhbJUcnQ5tMaOJyRuOJU i9yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752630633; x=1753235433; 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=PI+BpmLhrBZFyCshwZnktNusgYyVbEvS1xUVnNwBsk0=; b=qgja1J43Rtc4XlG58Y8DAjhGyDSzxkhNGT71sDjWmKthLUKSe9/+qI5/1jC3rdDbwD GJBRxo9eUqYkFPKTkM33gcsfWNXaNlGNcSt+X7seun4P3dx9BVtfZvYf35+b7S55fMAh qgYXCJ5gEwUN0svbc5LHxYi83Z+WmNK2KM1x9X+rxqX5Kx/+vvvkWB85RJFvhacxT7Bx j2n6fM+gKnWm/PNpvtg6WtYf3qPpxKSjoXYDG0Vdz1ovjcBLseZEi9BOjgtfcJDZN2Ci 1RgjcJFIYKBa/4NKHZnmexGheR3YEh1dcoIg9hgjonSXX9+Vyz0t2qfBRUKsrifduATs efVQ== X-Forwarded-Encrypted: i=1; AJvYcCVfUHvkJ0UX/PuI2KGnu2EJMVQNzmG0XwOZzQEgW6BX3ff0yqxlgPWXCOPcGTzd+eYkXcJJ88HNHQ==@kvack.org X-Gm-Message-State: AOJu0YwLIzyFHtv2w7dtFfxDKDCUIIh7u0Ogh8nYs/ls7ifZ0nEdPDFH hkaOP6gNIwyhJtcAp3jyNcE4Hc91kOilfcM2rVFG4i4/rXB1V6O/XriIFhrteYJJgX04DnHwpW6 E5/wEr16Vi9r+gKRhE7gGD5OKnQVQub2GFVbPv2xJ X-Gm-Gg: ASbGncvaLAuWwstYMWG4KZVsyaqcRruXPpLcmgJFz3hkMRn5oL2bseyD3NIfXE0JSeC A3wPVc5B6RFtPZGsZJs4rr/X9h9T8fAM6O/bFKHWIGXJ/KK4KUgcnx10Qq0lcYxP5WyqdRHPdQ1 8z/xOvl4Fs96kHzyKgDwQJhkKEuJ9GSQdXDUg6AEXCZthTykN6r1O7X5Ncsyal3InFKE0Y6olTv bhktYFszIVMxIGzO9Wv1esTLdqxNH91QfOm X-Google-Smtp-Source: AGHT+IE6S/geSCvAIOHME6wPTf87Pj245hn8wrq94Y+u/3lJJQqVVGTcUSg58tpAQ1CgaWAS+29p2Kj+iGhdGbbkHEY= X-Received: by 2002:a05:622a:8d01:b0:4a9:95a6:3a69 with SMTP id d75a77b69052e-4ab953ab2b0mr763871cf.8.1752630632631; Tue, 15 Jul 2025 18:50:32 -0700 (PDT) MIME-Version: 1.0 References: <5ec10376-6a5f-4a94-9880-e59f1b6d425f@suse.cz> <19d46c33-bd5e-41d1-88ad-3db071fa1bed@lucifer.local> <0b8617c1-a150-426f-8fa6-9ab3b5bcfa1e@redhat.com> <8026c455-6237-47e3-98af-e3acb90dba25@suse.cz> <5f8d3100-a0dd-4da3-8797-f097e063ca97@lucifer.local> <7568edfa-6992-452d-9eb2-2497221cb22a@lucifer.local> <7d878566-f445-4fc2-9d04-eb8b38024c9b@lucifer.local> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 15 Jul 2025 18:50:21 -0700 X-Gm-Features: Ac12FXyGHcEwj0dROFdwa9pljKXvmZP0XFWCivJTUTBRwHJhx-DGskIWSfL3dJQ Message-ID: Subject: Re: [PATCH v6 7/8] fs/proc/task_mmu: read proc/pid/maps under per-vma lock To: Andrii Nakryiko Cc: Lorenzo Stoakes , Vlastimil Babka , David Hildenbrand , "Liam R. Howlett" , akpm@linux-foundation.org, peterx@redhat.com, jannh@google.com, hannes@cmpxchg.org, mhocko@kernel.org, paulmck@kernel.org, shuah@kernel.org, adobriyan@gmail.com, brauner@kernel.org, josef@toxicpanda.com, yebin10@huawei.com, linux@weissschuh.net, willy@infradead.org, osalvador@suse.de, andrii@kernel.org, ryan.roberts@arm.com, christophe.leroy@csgroup.eu, tjmercier@google.com, kaleshsingh@google.com, aha310510@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EEC7A140007 X-Stat-Signature: scrpz9zr6i8f7rri1ajr6x1sjmqanz7y X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752630633-105712 X-HE-Meta: U2FsdGVkX19TxTVtuXiUi8Cuz9uSDdys6DmEGKKRXQMSLzjIm60PtsQqTIrXafG8g+G46i3j7Wo2NiiiDLz6ZfTUlqW8jRWbTkUEym1Ac03XbUw0ly2OltQEPzBdMo4HRlHu3i8qFUt5WF2RUAhQCLz77xt4bNw0F8d7DBBFFgv39zc4OFhSzB5WIC1p4QTllFu96rJK9Sy3xuwB8le8THJDFN20MvgSUzGOuiA19A7Y16hEkBGFeo2zYh4toKAUYqxlqbX/WUT99v06w4IySgfWXGtb3CqcqH0A5CIjJksSEnwtc2fySwpww2ck9ed2QmdsmRPM11Dvur3b9qDA28yywK6aAVeFSBsggAGaond9/jJ6ZjJC2sqTBo7caqqZ7V3uXZFrSJZH/AJzKdQxvvbgDzgz0aC2+92HypoMXICnVHzqnXzY6XokRXfjEhlE9wHqmHLe4JkJlqoKI1zmMyHhjO+s7ES3vuXnKjedLly83jTx66ImTcuxJFFmtPyNiI+paGliyIH1WoXMb0yVQ5Fjo4Y350o7C75o2wexOLbaWsWtw4FgoHYgJwccLkhk9a6Ht4uKKkgU9SWHIgQjZ86hK9NUTq3mlKz0Khno4Pqcgcmx0OXE4z0F7RGtSNPVMnIuU5OIwWscLxT98Nsqvz+vb0aPkD0RFXdJGpJBv+Ope+RettqNZvmtBOOx+u5wPI4crPimp3592G6dhXyCBM99E2NJ/gTPh40GeQIGOC2n88xy4VyZM6mb4lHdVNHDeYORML01gvfDpQAqAuDZSgdEefQUYWoL5Oab/MzdO/qOaBcfbaD9OhsZYViLIUALvchTIpZ/RFpS/Hgl7zpU+vmTGTyCaVidnwufHMV1ETU+B0XdRyq29YTV1xA/4A57XV2Xn8DS1xCo4TBTFqHWfHzFvk6ZgBqHCZhiKLbhq2T9hgSGeA9D1rKxrW6E+DELcwbyMQNQzBgtQxjOtL0 ODVjs5Tm P7Y4oxtzIuEjlJLB54NGnLf6FlQIAXMYBA2HBe0+TWQB2tw6Od6aJNPCk33LGRYh9eBgIUs8/2CS9a8AyT+cshv3lIUSTmabxypVvB0vdcCRNdGob1VaCQOGRvkkzKkKoNjN9tlfXbfdFGFSAi8ANoSjfJ5b9lyw+XrzYzFoUnXc/N9x3VDLdkqahpcAWQaMHOKOZ23XpHWFR+W4wow/2lmhCRrsVMmHEZNSJkpfup+FltGthSdCpsRb8HwYgDYEdUz/dSUiJwwCFRvHrnUR6IuLyZqk1vYuApBZc3iJ0j2Chw1l8K/tIB08y7hFLypOEQFZqD4VmUhj4ZQh6r/dedklGA/ERJDrkpY80w9nBuXDbWplwxFGvGlcLKsXrGdHhqqHZ 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, Jul 15, 2025 at 1:18=E2=80=AFPM Suren Baghdasaryan wrote: > > On Tue, Jul 15, 2025 at 10:29=E2=80=AFAM Andrii Nakryiko > wrote: > > > > On Tue, Jul 15, 2025 at 10:21=E2=80=AFAM Lorenzo Stoakes > > wrote: > > > > > > On Tue, Jul 15, 2025 at 06:10:16PM +0100, Lorenzo Stoakes wrote: > > > > > For PROCMAP_QUERY, we need priv->mm, but the newly added locked_v= ma > > > > > and locked_vma don't need to be persisted between ioctl calls. So= we > > > > > can just add those two fields into a small struct, and for seq_fi= le > > > > > case have it in priv, but for PROCMAP_QUERY just have it on the s= tack. > > > > > The code can be written to accept this struct to maintain the sta= te, > > > > > which for PROCMAP_QUERY ioctl will be very short-lived on the sta= ck > > > > > one. > > > > > > > > > > Would that work? > > > > > > > > Yeah that's a great idea actually, the stack would obviously give u= s the > > > > per-query invocation thing. Nice! > > > > > > > > I am kicking myself because I jokingly suggested (off-list) that a = helper > > > > struct would be the answer to everything (I do love them) and of > > > > course... here we are :P > > > > > > Hm but actually we'd have to invert things I think, what I mean is - = since > > > these fields can be updated at any time by racing threads, we can't h= ave > > > _anything_ in the priv struct that is mutable. > > > > > > > Exactly, and I guess I was just being incomplete with just listing two > > of the fields that Suren make use of in PROCMAP_QUERY. See below. > > > > > So instead we should do something like: > > > > > > struct proc_maps_state { > > > const struct proc_maps_private *priv; > > > bool mmap_locked; > > > struct vm_area_struct *locked_vma; > > > struct vma_iterator iter; > > > loff_t last_pos; > > > }; > > > > > > static long procfs_procmap_ioctl(struct file *file, unsigned int cmd,= unsigned long arg) > > > { > > > struct seq_file *seq =3D file->private_data; > > > struct proc_maps_private *priv =3D seq->private; > > > struct proc_maps_state state =3D { > > > .priv =3D priv, > > > }; > > > > > > switch (cmd) { > > > case PROCMAP_QUERY: > > > return do_procmap_query(state, (void __user *)arg); > > > > I guess it's a matter of preference, but I'd actually just pass > > seq->priv->mm and arg into do_procmap_query(), which will make it > > super obvious that priv is not used or mutated, and all the new stuff > > that Suren needs for lockless VMA iteration, including iter (not sure > > PROCMAP_QUERY needs last_pos, tbh), I'd just put into this new struct, > > which do_procmap_query() can keep private to itself. > > > > Ultimately, I think we are on the same page, it's just a matter of > > structuring code and types. > > That sounds cleaner to me too. > I'll post a new version of my patchset today without the last patch to > keep PROCMAP_QUERY changes separate, and then a follow-up patch that > does this refactoring and changes PROCMAP_QUERY to use per-vma locks. > > Thanks folks! It's good to be back from vacation with the problem > already figured out for you :) Yes, Vlastimil was correct. Once I refactored the last patch so that do_procmap_query() does not use seq->private at all, the reproducer stopped failing. I'll post the patchset without the last patch shortly and once Andrew takes it into mm-unstable, will post the last patch as a follow-up. Thanks, Suren. > > > > > > default: > > > return -ENOIOCTLCMD; > > > } > > > } > > > > > > And then we have a stack-based thing with the bits that change and a > > > read-only pointer to the bits that must remain static. And we can enf= orce > > > that with const... > > > > > > We'd have to move the VMI and last_pos out too to make it const. > > > > > > Anyway the general idea should work!