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 AB6ACC369DC for ; Tue, 29 Apr 2025 17:25:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56D466B000E; Tue, 29 Apr 2025 13:25:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5195A6B0010; Tue, 29 Apr 2025 13:25:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B9676B0011; Tue, 29 Apr 2025 13:25:04 -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 1718B6B000E for ; Tue, 29 Apr 2025 13:25:04 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8FA2D80BDA for ; Tue, 29 Apr 2025 17:25:04 +0000 (UTC) X-FDA: 83387756928.30.1C25968 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf14.hostedemail.com (Postfix) with ESMTP id B98C7100006 for ; Tue, 29 Apr 2025 17:25:02 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=aMSoktV0; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of jannh@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745947502; a=rsa-sha256; cv=none; b=OMOA8W5etP6tIJgeDV3hp144y5unOLgvJxFDy4KK6MEUmYiMg8/CHv0Lq57SCv81FCsCmv fUb/pGqwUPG6JtMA5N2yr/hlHBfzu6YBcqsVE/iqDk0+sgl99ydnHAjUpmCniQrWQOsoEc JWqQNW05NAk7rw7GLr9ehwNtZbc+FFs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745947502; 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=YZNlpWTu45BvxqqIxegtjX5fVfVe1MKL/1zgFUmY1E0=; b=r73RBBxFBX5WA/L8S8/BUZkthynCvLWs8yUVu5i304Gc6dF6uoolQ7PPm0Q6tcd+O5hbVA 15fb5lZSRjNmM+CXTGh79CE2mx0MXCfhecH4Pf6DTluAIOE9+7ExREqHaPrA6xdfrAQmB9 9naRJOuomKzA9lvqbnp7L58eMQZ9otM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=aMSoktV0; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of jannh@google.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=jannh@google.com Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5f632bada3bso3372a12.1 for ; Tue, 29 Apr 2025 10:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745947501; x=1746552301; 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=YZNlpWTu45BvxqqIxegtjX5fVfVe1MKL/1zgFUmY1E0=; b=aMSoktV0YdW0bX28x6aoAUi06G5mw8o7HONTWhFo0sbEECfdt2uI48xBOj6Si/B1tD dJZsJFkoIBeGWOzS1kShyLwlthdV6LtWIhm0cveiFyOgLFnTriPSJPiwh8hoYFXHpa92 fL/rOf+qLVcniappL10s6T/3l7+wQ12Uhr0wV8ej1uj/g8NYD+IYxOw/4kNoE1X4QNu/ KuNED1D/E4ZiKJVeHZliQiwR3K72cbB8OAr8N+u+8IaQWMnNsTkM52hGOyZ4J4T7g20D fvTiDON2n46VdnxA7F5S2bLm8847oGOKSHUbgwtQxfYLpI0+mkIZuH+y3YS736JIezYx dAMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745947501; x=1746552301; 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=YZNlpWTu45BvxqqIxegtjX5fVfVe1MKL/1zgFUmY1E0=; b=KbO1Ky73WDZUP9wIsL4i2rqeXkDlkYQ9oSJujFULm/W5Nr1MG3PP7C+8MnoXF9ZJgp bpfk0ZzWGCwcbvqaCGNkiDnaTezLWp3mhHDPSZcN3MP5TISiQISfZnxtl1LLixcSe0MZ Ap3qX/g8uqpuGXI3V8L4qCUOf3VUz7yAhKci1NAY45iK8npm+CXeq+T5xBDkCbpLKKJ5 3uVIDEhwwAPlCyVTgKJk8wZKFRX8LcWeXcnnPuFr9IF13aiV59zQJrPtBGBvYAS075oN TJ3Fn9WChqOaev+7lcyLL1NYVxjykhAg3CvUyHAsllF1l6i6D/6Ik+rn55Lr/jk6NZK7 Gf4A== X-Forwarded-Encrypted: i=1; AJvYcCWoYM+SDAyVslAy0ddSMLm2MoV+vXPjWKJA75R4BpwkQRbkNKfmRiaqtmgBI0+uju0BC2Fyd7QZCw==@kvack.org X-Gm-Message-State: AOJu0Yyh6WbVw2HtOXcUELzwMs6f1yP6K5ogsRIK4LpSLPWDvfMYZwJl cAvamaQr8ddpkvObONqQ0P52Ek/BViGB/5LJ9v10vBqQRYQZUftUYZEGpWB4TjAB682I+em/g80 54aWsF9/eS3GNa/QlZ+1kzcm+qsVtdObSsKJ4 X-Gm-Gg: ASbGncvAJEZShaJy6OU3wkqFe4I35IlaBuSjOwvg41NhjYO5Wf51xTv+xqhRfP3PyKz wIWK/CeOvycBvH+VyS1kBVfJbYkxkDEDTiCD0lHZS+de/o1NLo/OJxjwmBTEikkeClAUSwtjONi 70IFxhbmevT6pk7WHgw6qgAU8+bHG+SFNCE1F2ScLIga8x2tNfgg== X-Google-Smtp-Source: AGHT+IFQ4OT/08toQML4e1ydyufT1IDTka9yb0vrhYlgRKfv7FERG5Kbei2OqJYLX1P6Hv4sTwQ29rgIx15PTzGkeeg= X-Received: by 2002:a05:6402:516a:b0:5e4:9ee2:afe1 with SMTP id 4fb4d7f45d1cf-5f83933ac06mr118420a12.2.1745947500781; Tue, 29 Apr 2025 10:25:00 -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 19:24:24 +0200 X-Gm-Features: ATxdqUFzhZAitfkhicfO9Ve5tnFVPmDAwtXF6C9iK9LMhQflCPc-OR-WEacaXck Message-ID: Subject: Re: [PATCH v3 8/8] mm/maps: execute PROCMAP_QUERY ioctl under RCU To: Suren Baghdasaryan Cc: Andrii Nakryiko , 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: rspam06 X-Rspamd-Queue-Id: B98C7100006 X-Stat-Signature: ue6c8bzs8xqfx6xqoboshmuzk1a3cks7 X-Rspam-User: X-HE-Tag: 1745947502-641697 X-HE-Meta: U2FsdGVkX1+ZQ9+/T6/Nt6CSWzxXdyQbo73pXq01Azg+xZ3XXeXEvMQRsoB3MODLaTWkHW1OaG0RiSu387yYed5wJKQaoTglmXQLtYOyu+P4qm7Q1nyFJUPGM7/0LorNuTapHmQwVp+M0u3sLQRnhYMnmSKWcCFaEKeoxXkOWsqX0VJa4eyAa2mpba2mod/g+nHjxCxMGrO2JD0WET/o5RhZcrJNxhAgzhq4tkb95IaKjmQyp4tCLXdGgdnvY47JyZUJAbmCnqp1VUYwWwZ91Bk9XLOVY/eZkxAXL4bOqYJ5yqoVQF2lt7tzlkoEh4TARY6tAzd3n/6AXhzLCMfc48PIuMu5Bcm0AkZMjwHrUNKdnVrU0qeKNN+Sq0uVWzebhdexX3ejHPnq+ZOTsj5104Pr4TqFjPKtHG5JDsBN3XRQ+l0u70vXl7snbyZl9Xs4bUd4bGMi0CEnmzvlId6wclYK70mKDtqz4QF1c413O2xwRMaRtIfvBHb6lk/irtZviQM4Te02wT59NMlIbvHkbPvsvHO+XV5CrTQTKfVSQqhwSbaY+Ons+uM3vyh/wWmpBGhwXwLRSHgucMHD1k0NHYofJl1/5uCmpcCOsCdwGZSkkcgy+dsLudcISRYF50g0WAPWJBYnmWSPcSRpyZyCSYZqpaUfKVtUfdwDFkBnElztuZr+37IfT82TMfKxx1RJP6cR4wIQK03ZbKbK5R0hmmM0IS/xP5wpsQI3gEx9CxPWqc0zavSST4IBtsao2IGOS0pPk7B+EZdjZE5IkSJYhWyY7L6mZsKXwDVmLpWMljgPhkXIZ+X3qjgxo4glA7Fl3nPilLtk3ODUlX1gYOTM+6RpLmsjl3djXBAz+eXd5e0kqH8tNatxw8zawudsfVVDXiDlOmwPDpCgO8A6QhHt5Pi+pUfEipG6wEsJv8H9b9w5EJpCiTLfqzKBlyB37Y4tP8zvIIh0TjDROw/nl/T 0m4uaHtC wtwaZ1oP5f4WyNPLX6pqPBOOIWPcOCRbMRzxNlHWdo/utywaHoaK+aaJpyg== 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 29, 2025 at 7:15=E2=80=AFPM Suren Baghdasaryan wrote: > On Tue, Apr 29, 2025 at 8:56=E2=80=AFAM Jann Horn wrot= e: > > 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. > > Yeah, I'll need to re-evaluate such an approach after your review. I > like having get_stable_vma() to obtain a completely stable version of > the vma in a localized place and then stop worrying about possible > races. If implemented correctly, would that be enough to address your > concern, Jann? Yes, I think a stable local snapshot of the VMA (where tricky data races are limited to the VMA snapshotting code) is a good tradeoff.