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 08009C83F09 for ; Wed, 9 Jul 2025 14:43:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89EB18D000B; Wed, 9 Jul 2025 10:43:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84F0C8D000A; Wed, 9 Jul 2025 10:43:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78C358D000B; Wed, 9 Jul 2025 10:43:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 68C7E8D000A for ; Wed, 9 Jul 2025 10:43:21 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 83B1557981 for ; Wed, 9 Jul 2025 14:43:20 +0000 (UTC) X-FDA: 83644994160.30.57FCBEC Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf10.hostedemail.com (Postfix) with ESMTP id BDF75C0006 for ; Wed, 9 Jul 2025 14:43:18 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qltg8UF2; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752072198; 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=gftQ+qxJSS70rkMsu4DZpRzsUtd6k9644oflq0fw20w=; b=7c3Plqn8QQxRYjILTJjljAsUo5n0cJp90eWtg+LXu3BexX9woeaAz8JMybZW75+5TEFQet wnLZ8rbHzOWku2ffJ+4EmF2qGAoG+SYYEGIL+2Vl3t+l91Or7nRRFooQBeTuDHJ66B0ZJU 6/l57OeCyS3Y1js+Vu0zS0py9r/4yOI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qltg8UF2; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752072198; a=rsa-sha256; cv=none; b=NFv6+XSnSUoEPP3J46nKHWB8JHSF7/UUevpu4T+IgifxVUYEyObwIxJLNJqTZSNeL0wNNL e4RDyIbLtmVcwyOWpzGC5smaABp+zbnRxuu6qiRBpTWYyZ6Duwg0i2b1G+pdK1BOqjDU7W uK2v4OrzeVJVJYgDa+onyg0bbPNxDOg= Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-4a9e8459f28so41931cf.0 for ; Wed, 09 Jul 2025 07:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752072198; x=1752676998; 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=gftQ+qxJSS70rkMsu4DZpRzsUtd6k9644oflq0fw20w=; b=qltg8UF2PUZF3uGt3AqqKjzNiz+mjkCBqlGeHtTWs9y6pqyQ0t8cvQr+AxnhV1Zgto +duUffg9gG88ryQBRFe7A6ZljoRsxlvIsjiAcJdNraFNCzn2iYvudvC/H8iPnBsfQ1Xo hot0ws4fZps96I2Ow57NPjaLxi8nAif6SnrkzEzdbBWZj3h2ld1lnvQNvb17Sap5m6HM U56+LLt0GMNKeeZKbjJWAUhslX9HZZ5uC3QCBxEi8JXbzUCyMBi8w5GhfRZ9LsI0r28x y1ahTyR1yz5Ei5dzwqOIBkh+DaJDDw1qyIMFuRjaeKabNIeDavPhSNywljGLT81qkk6l 6Ncg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752072198; x=1752676998; 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=gftQ+qxJSS70rkMsu4DZpRzsUtd6k9644oflq0fw20w=; b=CLllpKFN5Cy9NaisUcTic1//d28+JXEbebPd8m72T+O6Xkh1o4m39wH9U5mbQ1RxfL xBIBu8yiBxFKeFLwV7TYsFSLMa41bTVuu/ZWzlM5k22hyN8MiHJEJ2r5tHkP0IzgPNp4 s1WaEO/dXL9pPLBk/yCxtfYgBHeVRwJcOgX7d8YUgGptRvUcmur9qI6H8eCFeUzosAla NN9nowK4esnVvhLqhitOqmMDT0po42WeKgSC03/6AC1rmtFA5W7cDzsK4B4kV7XVtk8O 1O9unairsCOU8dHddgdYMHPHNeCZTQmvgvKpyGb49TiUUQsibBDNJyAj00hJWD3CQbJW Il4Q== X-Forwarded-Encrypted: i=1; AJvYcCWEZsjl5JOdpFgD43g0snIjuIN4Dbw1twoHEcfK0FjITxlHc/lUR5/7N3+QfWunrAtDwrNPkU/7yA==@kvack.org X-Gm-Message-State: AOJu0Yyy7fO+UCOovHKGuPlZDDsza+A7UILvAOFKZSAmYwHztXsBM8UB Z7uIpu2i/erru2w1hEhyrcZh61rX3SAAJ8qLDl8dMVbOmpgM9fdwS8hVXXhK02g1zcoM4um9zmf Flx+dqlN2fhDdUB2BLwSUGR3j9h2EIVoriwmsUf1x X-Gm-Gg: ASbGnctgC1kIwjAgmMJYvKyl+Am4HeMBp0BCjDL5rLS9yG87SE67KvynOR75k7RYenG q6oQO+kQVu6LL1iZ1X96grQ0tXKIfiT3h/ISY/WjJ1OqNfwBs0Mf+W/8vu5gsec+UOxg2auD9Ah JWG/TawvQCUQpVH/Tu2YYt61Tc9jV4F2rrqLTEIdYIR6roXasUhchX0u3exvnU28ZBRPHBZN4RB Q== X-Google-Smtp-Source: AGHT+IG7zkg+Pkwxf0jmyxqG/AtRZpt/NoxzbpzI97QUnstYs7Yx7/T+z19dLrUpiVtN2qwc05XeZbLDBRjwgVj3A6I= X-Received: by 2002:a05:622a:8d0c:b0:4a6:f525:e35a with SMTP id d75a77b69052e-4a9de110269mr3693611cf.9.1752072197446; Wed, 09 Jul 2025 07:43:17 -0700 (PDT) MIME-Version: 1.0 References: <20250704060727.724817-1-surenb@google.com> <20250704060727.724817-8-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 9 Jul 2025 07:43:06 -0700 X-Gm-Features: Ac12FXxdfxMaIiBpg3e7XumgPrV_lZW5D9LQCLmL4Lhi4PbvyNa3fhCKX1bjdeI Message-ID: Subject: Re: [PATCH v6 7/8] fs/proc/task_mmu: read proc/pid/maps under per-vma lock To: Vlastimil Babka Cc: Lorenzo Stoakes , akpm@linux-foundation.org, Liam.Howlett@oracle.com, david@redhat.com, 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-Rspam-User: X-Rspamd-Queue-Id: BDF75C0006 X-Rspamd-Server: rspam09 X-Stat-Signature: q9956z8rqzohay6doh3so7iginpqzfi8 X-HE-Tag: 1752072198-972847 X-HE-Meta: U2FsdGVkX18MYNTcvUpkUHvR/YKvIgoEI5DHcWa8LF3XyJhLhshIhW4+EtPe4Em/JzTY9Nc1zR3wtAJa6takN5XZNwgg2luVwgWYPX7SXroatDG3ltEiNK2tOr0gR0eEIV0UZe6LqkJWJ8/OGBS6UEOP25AgjvEUofIbTF3yJ8e/nizACm3F7+lb0MLAp2HqNXIh1TtwPbdj7qVO8EDESnk1nizfp2ib0P0Rg1eN63X4twzfL6qXfif+C37TkXd8ou/Ge7RyWP+yUfGCUXVwz+zP3zD2nLvbfMaZFxJPbDvRf/Ejtp311FymNe5VVqdqraHZvCLmHtBJOqrFifrpMZRVBKrsECEc139m3t30E966NVUqjcQA8UiV81H9BysjyibyAVho3c1Kk/A2ASoDvf3bWgkC9RBsWdeX7eD+wTKhu0rxVDlfTTWkz4qLZvyh0lIRCz5YXScApD9L7B5oPPz5OG8wUbidW9U5hQRPM0n14ug7rgag4/FlYsBrR1HV3jtXUWUgdC4P2+N0oy6yEKLHTg6o3AizD9CTIEmbUU/xhomYA9fQ+Cmd4IjNYJIbsCe+GCKAYtpJWz6CTq6Cig/NA57CDznUuqtuccX3ZglJNszMiwFVqAB8aJMc4vloW5Wn1UH3Lpvvb8uK04nMYB5mDkOgmrWKpLUcB6Xxegg1cok2VNUSwKDBgTC3HzvW9aoYpGu11bBEiFGL6qLs41vbKS/MSRR2rozYpp01rs/s4SrKEaoCRmncDUBdoKOYgmpuWDq53VNpENF652Ax2qE0yhsqsEumYayjbvQ3op9GPaa7m+EAbdhVajabrb0CbcS0fRQtg3/v5vwTd+GgB3166gQgJUQul8Y0i9AUSB8Mq25Ri7tXU7jfTPKIyxSSwKwNLP5W2LQ/10Tt6pbR+hkUkZAPG8/fkZP6GLI9NmuJBU24S3uS5UcEe3hrqrApedVRn5zIWPw= 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 Wed, Jul 9, 2025 at 1:57=E2=80=AFAM Vlastimil Babka wro= te: > > On 7/8/25 01:10, Suren Baghdasaryan wrote: > >>> + rcu_read_unlock(); > >>> + vma =3D lock_vma_under_mmap_lock(mm, iter, address); > >>> + rcu_read_lock(); > >> OK I guess we hold the RCU lock the whole time as we traverse except w= hen > >> we lock under mmap lock. > > Correct. > > I wonder if it's really necessary? Can't it be done just inside > lock_next_vma()? It would also avoid the unlock/lock dance quoted above. > > Even if we later manage to extend this approach to smaps and employ rcu > locking to traverse the page tables, I'd think it's best to separate and > fine-grain the rcu lock usage for vma iterator and page tables, if only t= o > avoid too long time under the lock. I thought we would need to be in the same rcu read section while traversing the maple tree using vma_next() but now looking at it, maybe we can indeed enter only while finding and locking the next vma... Liam, would that work? I see struct ma_state containing a node field. Can it be freed from under us if we find a vma, exit rcu read section then re-enter rcu and use the same iterator to find the next vma?