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 21269C83F17 for ; Tue, 15 Jul 2025 20:18:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7CE66B008C; Tue, 15 Jul 2025 16:18:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2DB26B009F; Tue, 15 Jul 2025 16:18:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A43B56B00A0; Tue, 15 Jul 2025 16:18:18 -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 940156B008C for ; Tue, 15 Jul 2025 16:18:18 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6440410C7E3 for ; Tue, 15 Jul 2025 20:18:18 +0000 (UTC) X-FDA: 83667611076.13.43E997A Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf11.hostedemail.com (Postfix) with ESMTP id 7969440009 for ; Tue, 15 Jul 2025 20:18:16 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GaL+3ykF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752610696; a=rsa-sha256; cv=none; b=rfGCf6AMa16A+CTg7vvFaHHd3rv+/CEneAU8E/LLkfLJJ2BadRNMuNuVtJplNIXjKJq6yw H8k8rs4pbcwMsVUKJ7usIgMdAcWAHAnyf+EBLUEVvo+O3H3e055GIMjH56qLLOfJSTdgRt z2vUYWLPv0x4+gu3POuDLmYROPPSQzM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GaL+3ykF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.160.173 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=1752610696; 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=4h3Ep2VWmJ725V4zeell0WprNHA0l7LEqrQxhnNjHu8=; b=C+EgTRG9VDbygKl+EcUnKaepwjxX2hLY+Hhs0kAEuFgYfsimMbs2lYsAGAzkrVFYm7FYWV jrQrywUQYLU1jxh20tZz98pjVNcfFDmKUqywb6MHpA1ld6T5qZYVE4UHVkbAVzdqk/kYOM dWf9qTGubx/nNyYSWamWNkuVpOz3Iac= Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-4ab3ad4c61fso120281cf.0 for ; Tue, 15 Jul 2025 13:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752610695; x=1753215495; 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=4h3Ep2VWmJ725V4zeell0WprNHA0l7LEqrQxhnNjHu8=; b=GaL+3ykFUnSSEkUERzKrnoVDDytQ2pQdpQ2IfY4KQLewiV+xaJkAomCi5DqrNUTspr CHoAwrxUn/ZlqtLrNtyNWjVoWbMKwJ4yMPMQx8vOVha1ioT4xhKGSmQcmwjSoMRFcxuN RK9re89PG0RTmuf8Wz/42YmXzu1L//1iEqOtnb5WT5ydEbYGhEui/+5WGcFO64XEPzx4 a4knJoONhUdfQrpIMRbz9O/bYwjQyavb0PpDmXTCkxfWYK51FnSvBuA3QCdxZkQdzyhu EqjhkK6ZdK5R3kWBnKnUUb9rJTXa2DPMAl7xAoSYthf3ho+xaPoPTaCvVM/+GYXqBCdU Y4SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752610695; x=1753215495; 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=4h3Ep2VWmJ725V4zeell0WprNHA0l7LEqrQxhnNjHu8=; b=kx1U6cG3PAkwQNMi8l4I6houT13QuRVw5EpH0TcUDWkCCRNrxz74vjGFjaeEQ0oGyR rwUCx6CcK0Rhn3s9msfCjExajR44ZI7kZx3AKBunaP6RAY/DosO4evQDuw0bQ/c1P04P GY3eUxCk91C7VmbqXfw+wa181xox/Lm9wDO9rnSnNgOMMULa/CDlr1h6njz8+kMvvdcd q6TuMPBRr4B6+oyPwRWvza2slmTUTrBijZp3kIoX1L1f0nNPZUhj6Yi5KtKoJJp3yt3F Bzdoa7aqgBzcqMOCpo/+rQCW08H6u6UX215TvaF5CkFkGOE8LHcQbbOYW8irgGghxRvj XsIA== X-Forwarded-Encrypted: i=1; AJvYcCXH0ObfGow6FaDiDGjWVmx2z2kCqBDqeMCf4HN5da2izxAFeGfRdLSpizD92+tPSmT3AmrUud9cEA==@kvack.org X-Gm-Message-State: AOJu0YyjQQ/EzPLdfz6nPO/RK63wHwJ71tb4AvKyNAlNYrIScv9DLhW7 wpa8Qn+ip4PeK18ap0Y/3wAbYUHZ9/8SqUmipaubFDyjoTNrU6UQaKQc7engseXmxniY6sN4gdL jxh74SeeOEPNDaYovEcdAoUkZLDGPjV9w5y5t8x9x X-Gm-Gg: ASbGncvH+ZLHOxYZfnXcd6AGWCWDyIkQ5OE43nl1gpnObSwSLi09IghIi02D6Ja29V3 kuBCKq3djoTkmyZP7/nZ2LdjWE98Bsfdqwp1XSsa37vSgOMiBB0fcpj9eVSLVgKSzs2sreqCbJB ZLXKHTE/vjjlBZdHra/d5xtRbGddm+jFU9eFpD4KmK3uw/OHzlebNm2hgYJtlXW9YpAfvZqwxRt wsRT/hhf+rWwMfI0GDAqNpuY+6Kjxe8KkLXnC4PptOUXtc= X-Google-Smtp-Source: AGHT+IGH4M4H5yhWaOUW04EMOoMVNaNdnS8aTx/in7/xD6LRAKlI7amTM7yUE22F+ar6ZwOBueaAeL5WAceT+XowSog= X-Received: by 2002:a05:622a:a492:b0:4a7:26d2:5a38 with SMTP id d75a77b69052e-4ab92bdf67fmr419201cf.19.1752610695062; Tue, 15 Jul 2025 13:18:15 -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 13:18:03 -0700 X-Gm-Features: Ac12FXxyNmeLY-h4XS0JaeMQU9el1n8wMSHADzsB6KmgQZuTOsVzCS4Lh8cGUys 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: 7969440009 X-Stat-Signature: ahdo5ycbmcxa831i51tuo6hjydf5tza6 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752610696-597456 X-HE-Meta: U2FsdGVkX18gDCWT7L18TgMJA/N2toLaj3ImOEqpuHHRXUH01z2hnAum1pBboKxKSn/S5dHCkvwHhO8DXMYLHpWB04Nv7OlcYLCmP8b4b7uSycSp8oFHr/+WN2ahUmSick1JWtWwVBMMhSfNwt09PGUtIGUBJ2sm9JHv2yROcHifKUT/UltUKOPs3JLqKvgelkCEiC6x3v0Px9ZGqJIayWWS0MkhP45EtII+Xp25Pv+3isE5fbUBt4YXCrOnyiI4BYPsfGhAiznHM/D+mE3IGBR29OLproci57lUBkzD2VnpPwVXV5ZtLB9GutRiNeYFaxNlLjUUCITx11SCvrb0MJX/AEnf4VZycn6+TDJW/D/Wgs8d2n+NDneRnsRKM+PCK53MVl7Q57uzNf6FAdRgo3zhZyoUh7urJB/qx+CU+1GEnPP9K4Mj8u9FoAQeTa6ugqZxVpjpBL6TOsR7vfJEcRWI5sf9q7L7rcMULLCSnh8IgQR5lq7oUAcu7M6vpRMdcpPll00nle0ZzmpJ4N/wVY6eBsOINryQn13ori71AFeWSRJcFtRLFOiiNrQw4Vo3tg2J7n5dgjq/VLXKeMUL1vQ0aY1uB4p8WYk2rbupCE7Aasv1ge2qgLTTphJwaGDuERiKggN3pJOutSqC20rfWTqOCP7gLmft9ft71JL2bnW5EXUNMBxoGzUeeFdleSmIOoVIbIThGZesxjE2kf3towSruK31SN//nyhEWM3y02Aj4C7X3CSZkdUv/92rquOZ1Woq2Md/oKI9qsvgvRn2tup/DIw2PmZtDMCLufMXF1NkPBKY7y11/xBGh8EzjGWh9Hq6aGZWPAh2jRGxQHlOPWLtoMkqq8dmt5Qyi7MF0OgnPmWnUp0PelQe2cNHFEyo/YduXuAvQl860wwoLbd4zQ3IKqZt3teqzodQqfVUc5eeZVJi3P43iRBj7tdFreWeK5S+hZfXDRxp9ZqliSs LT0n6iyD +Xm45YpS1vh5bAuBOviwPU7qWCgzzXainQ6b4fbQefDbNvR9/dFFlR/j0ywTK6FiVrDpmtfzgKE0vDQ7qvXUnaHhI5KFB39tsrkN9tpAIamzd71JQnfD/2NQV6bFYQNXvE0n5K4/lzdvm4HSUxrcOOnyCzlv2zdVX9erR+6clB+RHR7NRgM3ty2IQYfJ82ojaqYGAxhSmxQRfN+L0VAHlRUroDY89UFVF+QYiqLGmL3cQyH+UyaJdcH6OF5jYTm+kPUND2XIEuPkisCpZpxUTJfXBS9gwZuCSeLF7Uo0JrLEK+7EJKhu3ke3H4Zl2aaZe49ugW0tjNq1aV3a3TAMcwfdfkDUTdUTv9nevv2w8oTAcC3w= 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 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_vma > > > > and locked_vma don't need to be persisted between ioctl calls. So w= e > > > > can just add those two fields into a small struct, and for seq_file > > > > case have it in priv, but for PROCMAP_QUERY just have it on the sta= ck. > > > > The code can be written to accept this struct to maintain the state= , > > > > which for PROCMAP_QUERY ioctl will be very short-lived on the stack > > > > one. > > > > > > > > Would that work? > > > > > > Yeah that's a great idea actually, the stack would obviously give us = the > > > per-query invocation thing. Nice! > > > > > > I am kicking myself because I jokingly suggested (off-list) that a he= lper > > > 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 - si= nce > > these fields can be updated at any time by racing threads, we can't hav= e > > _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, u= nsigned 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 :) > > > 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 enfor= ce > > 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!