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 5FD5ECD128A for ; Wed, 10 Apr 2024 20:26:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D78116B0098; Wed, 10 Apr 2024 16:26:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D283E6B0099; Wed, 10 Apr 2024 16:26:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEF8D6B009A; Wed, 10 Apr 2024 16:26:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9DB886B0098 for ; Wed, 10 Apr 2024 16:26:58 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 419FD14094D for ; Wed, 10 Apr 2024 20:26:58 +0000 (UTC) X-FDA: 81994756116.03.7E91932 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id A3E56C0027 for ; Wed, 10 Apr 2024 20:26:49 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dy1zGKif; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712780810; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SPofphAnbknGoSZqWt9l8ENx3Bo5uSTSZafIxk+CniA=; b=E6buxyH+iij00ARTVoMl2EvHJOn8ffYH0nA64V0whCrJBa7DyGoyd3yLUaJvD+I6eWypQx BG8kRxWjUmz3Q2qnaVSR4ugigei8Se/XtQdn0yPnHGObZlvn3WYusNFM7bTD1f9x/139mW kzjOYzqvtnFWpxB9vvMNScGH9bTRttc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dy1zGKif; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712780810; a=rsa-sha256; cv=none; b=mMevpqFmpX5gxqN3AZpg/gDVuZl3j4UWWs0biYzdPj2svbp3a7q1+ViN2mHB6bjLs/E/f2 ykC43x9jEbnk+qXq22Dfql8LiAuJA/MCG8a1mZFet7oerWNOSzFKa+1eLlhkZY1vIKtx7k CKfQTtehwHxSrxN4cdszmsCBvMG7pDU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=SPofphAnbknGoSZqWt9l8ENx3Bo5uSTSZafIxk+CniA=; b=dy1zGKifcnV5nMAYXVfwD7f/58 iIYrRekhUvN5IcfR1mWVSam60xyFwuxMarGdYKLS3LWt573W3IjU7RyS+3ec9ZDVVK9bzx/eqhJ/J 9GSHm4eMIFfSIyeGgHMBm1j25UI+NMh7HwqqiTFG0Fxh1GIVX3rg73XSQLFGpCGV+osoBPekERVL0 nkf1Js1wxC9TFB0E9CAQNgH9gNk/vp6cy/qL0RPi1aHdE3dZr7OsSZ6qkfCKrnlhQ7xRUqxDc9d3y d8j0UbL1VSRTg+JjYEAKJekKPLTE+v/Tt6AqjNoTcpdP5DDzYU6ldn4EQ8a/ajzRVaJE8ZWFlsIiN dWbTeqaQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rueWr-00000005EGj-1bfT; Wed, 10 Apr 2024 20:26:45 +0000 Date: Wed, 10 Apr 2024 21:26:45 +0100 From: Matthew Wilcox To: Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Suren Baghdasaryan , Lokesh Gidra , "Liam R . Howlett" , Alistair Popple Subject: Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks Message-ID: References: <20240410170621.2011171-1-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240410170621.2011171-1-peterx@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A3E56C0027 X-Stat-Signature: nwgmq9zq7th6bcgtp8jsxiqw9ewe54f5 X-HE-Tag: 1712780809-346006 X-HE-Meta: U2FsdGVkX19JxI/Mu0QuRWQ64dVYRhO+2JSw6zntUyKitCZaqz7hAMbN5Kqtu8vBMCQH5WEFxCnyWP5lVOIZhfoiJCCKDbTQaDye5Vplq+ox01c1iJWXXFYDgtkb46ykNaSzug3iziZFyQWYPzVXSori3iyNwE8hvroZBxGkz1mVxGUM16dGafnIXl3llzJfaBVxlCjX8uncxsvYn5sJmdKSCrx4oqbxczFT5e6dM6Tzuh3A27RpIKthNXkpcmCD2XEkp1qJMXNJtaSQRQddaIPN7Vfdq7mJfmB+InDGdz+veJk+adcVjdR4Nx88qkYg30nkK5i5aEAjnq3sRxN+ZzRMusxnTI5J1CObJUIb27njhLXqJlLKGBWhW/EbFFIGpReHxBhZbPb4nkDNnMlRnXJkskjQ9qrsqX+oczteuwLBYaM9XaObt0ZnPd+lg5PYwNgc/Wc+Ps6VFGwtyMHTp8CThAH4RkoGyuK78sv9xSU/waQH5jkBgA8DAfmZyNGy6g5dXrpSmTDsXIIuTPk6HBM+UNABQLojLvOEHQUNYOlQb7u/K41GDT0gRIYczIDH7iz4584GD/C23fEH93ym8TFwZT/VFCPeU6WRgaf0zkeouZtndEwNic9ApGUYKwycE3Xa/8e571mj726lRXc7RjL7erT40Rgz4jdXV1//lhMezHAIntLAMT6IJQXeQryteYKU4Fw7P0tztMrmF9DG/6sG1PIhoAH8zQW0bFouiodRZCvYSZZ5itDcAq5M0kYxcqBta1Q25iJEsNuOM/i0xAUUbqwT9LRkfY8tg5CZJTiLsl0ZdMpibBE58wYJVRTY9BLRpqm13wUk05vf1Ia9FPY2Dn1XKqfnwX0Hs8OfWC0rGZNWIa5EaYGLMm2AuvfUzwE6GOW4+Oshe//w2xQQLvfqn68IjQMaEZPLFyjaWXNRDOaL2IWmBy0dFr7MuWayGIgCBVlguOsQ4/dlCMg BmWOJqPo C4BK0NPKEuGi5roc9Z/cFu3X2Ukj4hkZk5dio3qe5OMdV9yb8aEsBvsWVqGNRAlcLctislDkO1L+EcaVGFHurhtYIfYhRdHIq+Ijm4hV8qE3ED3ITEpMilZgDcr0k5LIWjrywn9Yw9SVznpfb6eXEjROdp3Dqg3XSDoTDqZuociae1vGMMeMdWJZCuQ== 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 10, 2024 at 01:06:21PM -0400, Peter Xu wrote: > anon_vma is a tricky object in the context of per-vma lock, because it's > racy to modify it in that context and mmap lock is needed if it's not > stable yet. I object to this commit message. First, it's not a "sanity check". It's a check to see if we already have an anon VMA. Second, it's not "racy to modify it" at all. The problem is that we need to look at other VMAs, for which we do not hold the lock. > So the trivial side effect of such patch is: > > - We may do slightly better on the first WRITE of a private file mapping, > because we can retry earlier (in lock_vma_under_rcu(), rather than > vmf_anon_prepare() later). > > - We may always use mmap lock for the initial READs on a private file > mappings, while before this patch it _can_ (only when no WRITE ever > happened... but it doesn't make much sense for a MAP_PRIVATE..) do the > read fault with per-vma lock. But that's a super common path! Look at 'cat /proc/self/maps'. All your program text (including libraries) is mapped PRIVATE, and never written to (except by ptrace, I guess). NAK this patch.