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 89FF7C369DC for ; Tue, 29 Apr 2025 15:56:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA1DF6B000E; Tue, 29 Apr 2025 11:56:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E2AA86B0010; Tue, 29 Apr 2025 11:56:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCA866B0011; Tue, 29 Apr 2025 11:56:38 -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 AAE606B000E for ; Tue, 29 Apr 2025 11:56:38 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 751478081C for ; Tue, 29 Apr 2025 15:56:39 +0000 (UTC) X-FDA: 83387534118.10.7E9CB48 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf18.hostedemail.com (Postfix) with ESMTP id 696261C0012 for ; Tue, 29 Apr 2025 15:56:37 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=F4xQdrBC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of jannh@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745942197; a=rsa-sha256; cv=none; b=ZzRLf3RWa+HXXCYsjPAdo1g+M1j7R+KqbtAO3Z6GeC6MfnZ7MW4dLGJgHFdZM1e8f4ctoa VRyeZTByka3AkPV1nv8/DHu3wxm3t4ySMl+BJn025MLY6rySbDO+fJSwaRbPDwZAnlGw4D lfDPpiji+oHCIstpqXDQgZ1kyeuG8ns= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=F4xQdrBC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of jannh@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745942197; 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=PksiWfpMfxllb9cMtMeDE5xqZSJKQGuK3D2npFWtovY=; b=Yy9DkCiZrJND3qAJ9Y0WA094L3f3Tt+KZBd64UV2lOSOz83xz4eMq1NqoJ9DV+qpLefyGg 4v73mv/tPSml+jjNVhO6O8j+ekHg9I0hAU29PoUQOwNt82WYxSChNHP+928V/UjLYdO7Br p00jbNBurFjPLqvsIWWvk5ipSWgXzR4= Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5f8684d4188so4249a12.0 for ; Tue, 29 Apr 2025 08:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745942196; x=1746546996; 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=PksiWfpMfxllb9cMtMeDE5xqZSJKQGuK3D2npFWtovY=; b=F4xQdrBCp3hj5/C6r+jZ0q8MTDWrtrXf2B0WwvvNFYM63X8nPqH24gdJ0P+pNZ7atZ cpvB8xAmeIPN/qtruIXIeZCwUHCXfBPa9LU231raMXLipeMxRBdixy60sDg9kyvHNTFQ Y81zeZnkkMqpu6w8Hfgd2mcTMjj29wXV5N4zJetwtuk7exXCWcyJ22maMTv4a1aKALxi iaoBC6a5klioptSV6mjKQZM4tcO10H9zx6u0+NZXrBALDjSpq4RUx8oblYcogr8HL2nd zLXbF3+0Qoj0m4hlW2Ftea4jaS6ni3JIM6jABw+QBoo4R3BwN59fEZKMj2Lt5BqhJlpZ 8PMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745942196; x=1746546996; 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=PksiWfpMfxllb9cMtMeDE5xqZSJKQGuK3D2npFWtovY=; b=PQe5oEhug0tDhHv3nPa8reGBcA3Nx5/bPJaW29qrC4LZS8evkaQJXp3A0nSs51EdJV r2Ugyb2rIHLsuyqfGGEo9BHHo+EMRiGR9QPHP838s6+dMXJMXYl+XCFzY6MM1ob5ILGf TTxUbtmVyP+N5YV5auvhVqfzKaSyhLc1o6QoR5Acb0Y5fpHWoPg44Erqgll49AO82Vi5 /3ms+1DEkQypBe6lCVPJui3LBGhIt29eLFbyN+iycflrJHXVg9oKZvC5TW3x7rKo2LJs tn1xPpi5Ttra+7c+ua9fvORxtifh0YjRDs4/x0Mf35ATTKB+rkPsEJOiYVmjGLlJsLbk kAfQ== X-Forwarded-Encrypted: i=1; AJvYcCVbj8AfT5KjXChqVCWNqNuLJMyApzGUxQJFH9voIBoUhoMIts46q7rxQi9YYWJMdF0hqPRU+c+HwA==@kvack.org X-Gm-Message-State: AOJu0YweV3ZieIu2unaSeqeUyD24I4gAgBjYpMwmu1IMzFW1iSu/+UDp VIKs4q2V0Or+g2axcDrmRzsKtLRxjsOz71OBfG3aDi8DJOwHqcfC1yoWyy7czV53VY4H+hnvWKE 6cAAuDbJxllp7qM/RUhE9oBbdLPc3zyFVBC3Q X-Gm-Gg: ASbGnct3SnQTa/bkwV5Y+blvbqf0CgJ2XDB2gMgmRFeWLgYrdS6xIRRzC0NzwesSVWA Y1IqcSqtv9pVwIqBzEPHKz8R2TMPd5ZkNE34DlZYqLDIeMBaLgB1xh/ZTFmaxX8RqqLnsoYzgIf zASKvpsEYaqXm3krqWM1ay1vYLXFYLRsFFbRULEWI1lrlZ18blXw== X-Google-Smtp-Source: AGHT+IGtxlZGWu2Je/bOBDJTv80S1Q80Y7hLVWaw/Dsh1sFOZ7mVM95j4NTnHLX0IbqUIKK8zCAe/YhlOZPXyx67i/w= X-Received: by 2002:a50:cd0f:0:b0:5e5:7c1:43bd with SMTP id 4fb4d7f45d1cf-5f83c1b5a74mr91868a12.1.1745942195429; Tue, 29 Apr 2025 08:56:35 -0700 (PDT) MIME-Version: 1.0 References: <20250418174959.1431962-1-surenb@google.com> <20250418174959.1431962-9-surenb@google.com> In-Reply-To: From: Jann Horn Date: Tue, 29 Apr 2025 17:55:59 +0200 X-Gm-Features: ATxdqUFo7EtQYKmtjBK-XwiZ1ZSWDYl5j8WIiYqQOeXkDF7OdcxVClYh41AITzo Message-ID: Subject: Re: [PATCH v3 8/8] mm/maps: execute PROCMAP_QUERY ioctl under RCU To: Andrii Nakryiko Cc: Suren Baghdasaryan , akpm@linux-foundation.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, david@redhat.com, vbabka@suse.cz, peterx@redhat.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, 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-Server: rspam10 X-Rspamd-Queue-Id: 696261C0012 X-Stat-Signature: ppfym7ron15o3gftubstptkwm491uyww X-Rspam-User: X-HE-Tag: 1745942197-470945 X-HE-Meta: U2FsdGVkX18cqfjtJvqJNViU2CpXarX+tV7REHcxl1wAMTv/SHvUbBcETZjrKPq/3yG4FJlCJBqbTEF6v9YYZal8M7eundEF15DD4no4D80MQ3KypXvd7jAiXsFmjmmpx2zFKqQuNjoOdSYoq6kJG2fnQzCiAo0JrR8FEcAKdTA7bB/RRYKk/5/cSerJMEn+mLkwnY2AvvkMwdbsBPYednKkLZa+7zk045AzaHKvWm28CDTkoNkWuemY9qWlxlDqQpVnTWpSGOQYCfUrq7rJEFAtYh6EX7yVHmDYHHxh33/ziaHD4X+kCNf9J90UXliFhRs8cli3udwZt4T6/t8HkP7OONUMLxj9xuXiA7SGE3nR2+/MQjAYL3jXeSviceC6rmpicd6khQzcglkHJkrlzW9hj6hcVJ3Is0TYcLwGLrtLwMZwDqKIKb18CtYlcZuNsJ95fDliWH63IAYUM7bzV8TU5Ndm92rP8+ST9mcEQztNewQ4KQl+Dq3O3YCHbZbsjCWt056x5FQqb0Y0BI6waz2tD7KW+00+BKi0ynEcAM19+CA0KTcrtfoX7BSodOzgGQJ8NDKPNruCO7vNMI/gVrx6qeexfcKrI2cbrT4xeYG1RddNpBGIM+bmyTJz9B3BiVRbrASgsB+/n2wuVtPzTtHjb5wsJ0ermFV3Zpv8RmW4StleD2QUKBwLgkGrr7srgAwWO/f+ss5Iaq+MmYp7bXSNA5sGoPmh00v0Iqw01xER5x/tGoPZ4da4daB8qjRJvRKQuYvwLHMi7Kj3GZXZ1zR9+T2u0pvT5E8yrxYnn7XyIKN9GgszhyqALPboUFG+DdtlJhowLRMUtjTaw4NPvL4cL/yQ/RdlsOQv1mYzB0iUG8HwxgsYik/SCAbkYHQgT8LYiLPVX/79R9ds6E+aY/1GZqRfVaLe+YgVQc+FlJ3ZNjHnQ3M/xlhUZAHFj+WHXpozORFqMUrSinqBzKz 1Oeg1d1C k4Tt2Mrv2zWwfSC1Nz2HGmn9OTZcVqDYqoyUSPRookcmMcarEqG+BHAz/8hGrbIchPe4pMe4MmSO+f4f4Hmo0xtf1raDSGdu8c4JT2Q/6NbWjomUbZkqimiWJHe7jPyGJJ6zVhotWLmpw9Nr5OyboKSQ0v+l3wMpiEztOcAhZm5hBN8oX1si3DPQQTSsIm07k6TwS6dB2Pj59alfqElstsDrI60baiilyan3QQtw13Dt8ptGo6tY2/b+Oqhcu/u/QtTrGE965mA0jqdWa0vajcfRXAX5+8ss9xtC4JjwC0bxHObGhgvsk0PgRd1DCnkOIQ3v87kSUlfo9uQV0AIl3IUWKGq6aF9g6d5YsA+SOri+t3/w= 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, Apr 23, 2025 at 12:54=E2=80=AFAM Andrii Nakryiko wrote: > On Fri, Apr 18, 2025 at 10:50=E2=80=AFAM Suren Baghdasaryan wrote: > > Utilize speculative vma lookup to find and snapshot a vma without > > taking mmap_lock during PROCMAP_QUERY ioctl execution. Concurrent > > address space modifications are detected and the lookup is retried. > > While we take the mmap_lock for reading during such contention, we > > do that momentarily only to record new mm_wr_seq counter. > > PROCMAP_QUERY is an even more obvious candidate for fully lockless > speculation, IMO (because it's more obvious that vma's use is > localized to do_procmap_query(), instead of being spread across > m_start/m_next and m_show as with seq_file approach). We do > rcu_read_lock(), mmap_lock_speculate_try_begin(), query for VMA (no > mmap_read_lock), use that VMA to produce (speculative) output, and > then validate that VMA or mm_struct didn't change with > mmap_lock_speculate_retry(). If it did - retry, if not - we are done. > No need for vma_copy and any gets/puts, no? I really strongly dislike this "fully lockless" approach because it means we get data races all over the place, and it gets hard to reason about what happens especially if we do anything other than reading plain data from the VMA. When reading the implementation of do_procmap_query(), at basically every memory read you'd have to think twice as hard to figure out which fields can be concurrently updated elsewhere and whether the subsequent sequence count recheck can recover from the resulting badness. Just as one example, I think get_vma_name() could (depending on compiler optimizations) crash with a NULL deref if the VMA's ->vm_ops pointer is concurrently changed to &vma_dummy_vm_ops by vma_close() between "if (vma->vm_ops && vma->vm_ops->name)" and "vma->vm_ops->name(vma)". And I think this illustrates how the "fully lockless" approach creates more implicit assumptions about the behavior of core MM code, which could be broken by future changes to MM code.