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 2A202C00A94 for ; Fri, 12 Apr 2024 13:32:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6AEB6B0096; Fri, 12 Apr 2024 09:32:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F3756B0098; Fri, 12 Apr 2024 09:32:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 893E56B0099; Fri, 12 Apr 2024 09:32:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 66AFC6B0096 for ; Fri, 12 Apr 2024 09:32:57 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A207D1C141F for ; Fri, 12 Apr 2024 13:32:56 +0000 (UTC) X-FDA: 82000970352.22.53BAF16 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 8F495100002 for ; Fri, 12 Apr 2024 13:32:54 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iGxKlxLu; dmarc=none; spf=none (imf14.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=1712928775; 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=tlo/jKZBmTDJIdo4PDZvhBV4+iTY9T2bWEJHZD3RkwU=; b=18yqGhQKrxTNTd8h/Sg7dc8z0312TZDN2bCCTzLdk/Ae2uErrwwamTmsTsegisgbtk+wjh cIIwdFnv0WdA69NRXos65nLTDXinbUA5IreP4tYWYQwf4T6fdjAbzp1s8qDuVb2OEZN45U zXPRkOXYUJE1BvpMvJgc0DEvI7qTqRY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iGxKlxLu; dmarc=none; spf=none (imf14.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=1712928775; a=rsa-sha256; cv=none; b=Xl37cBxO1+dvozpvZlrx/TvcCyNk6o4w/75z2OZSGwgpqPG//e13jZzGQBTi8el9DgLplA NDetgJmQV6oOk2SCnCyjz3e3Lh7AMZkUEcOEHZttdIgB6gN688VRE2sXLOpEGm4IrXTiJr RhEeSWHgcytTbJ+/olI05La6ghklrq0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=tlo/jKZBmTDJIdo4PDZvhBV4+iTY9T2bWEJHZD3RkwU=; b=iGxKlxLuVrmepm/fByNdFT5cbz YelU4Pv2IIxF/mgrDh0J0I5OQPwyawd/FCdqZG3fD/jtr8+oe2tMeFw5WhjmLxtDLefeZgwBFZmJd wsNMyZnGlFqvL0Us7gDU9wlAP60bw2QpeZeMJoZWdynua3Pp3hpekog+GEeL7/OSdJ5jyP6M4ON4I YbG/EUpVUSCxTFQqo3ixdxfd8Ho51C0/yy3a6+21xD3Btk/O0RbJhcL7AAARl2GOz7qcYgqY9OBRs fuN+KWcr0CyAphESaAHtMu1kVPx8r9lMrGJSFSQuTduXPvyAhmIrdxtEsZGfp/MYrhQOgwroeGFVj +7wGHdgA==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rvH1M-00000009ET5-0XgE; Fri, 12 Apr 2024 13:32:48 +0000 Date: Fri, 12 Apr 2024 14:32:48 +0100 From: Matthew Wilcox To: Suren Baghdasaryan Cc: Peter Xu , "Liam R. Howlett" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Lokesh Gidra , 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> <20240411171319.almhz23xulg4f7op@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8F495100002 X-Stat-Signature: jda5zxks8c7oin1j6gd47wk5b4gzeouh X-Rspam-User: X-HE-Tag: 1712928774-596255 X-HE-Meta: U2FsdGVkX192K+bmfJNbnykB9OKxd/p3J73/6yV+mZk+ymVto851wiApQk6LABObJ5J9CgYmR9uaelDM+5x8g9e+rqhy5B/YRuH5z4/2vKZXJAUXllLu/xn6uqc0WANtZ6yc8zVDRlvwaWwn8O3r8bOMsm/GwRwCUN8DxRZtuVisJr3ZDfvJh7Ql0b1Qom5U4c1ZYB4p33gNgbgbRgnJgtid8sLvedpwZ1A4HaB0YiyQ6I3ddxPlfO0ln2GhnyfscitKUh6ectIQX3ZJpfGBY7yeliIepV//nd0hxg7O0Lzo7VA7GJH4HjzJkODitL0Mlr6ZC1SDQXg4bNrhnD+N4LOX1od/izE6l5SKl86iWxZzIApbyykfqZgK1/jnRtoG2gmpCcs4WabCauFoRdCYJYsUgTue3fqvJdWOgX/nvmD99Glcpui4tfabIKgmcpE9gdHBM6C00O+roXXCD2mQkbKpnaBsMottYsEZ8W8Epgyy0xm9Ev2oJxNe1GlSU/m0WRXQIWsDNp90BWecjQIz5ltH8J7kReittYJKsGRSw7oYIwk7ztZyodJRNQXVuvXWaPi2V7RUYwMIisOicOpxYPUmWMg2peMuhmg03+RQBUfMJp1x7Uu9CTKbtVcg3TxGYhLWQsqbwi01NwuVNaaCHArwhDwe2bfUaTXJYWC1wISefcUHmqt1KwEJs4Se0hhBNi6+a8e/xseyn732/j4fpYb4wq6TK5AYKp10QBoGqIJZB+L2037R2VFKLbVKJda0S1t84n8W/s+L8+sPQ3zTVOlDT5h7UcKnbO8dUUqnc8KD3OgSFSGOjdKw0OKCDUj680OnOl+SaOicRQV3q1EG9B7gHkJsG1z+yFR4GdGMrigjk9OINrGub37zHoILBlu0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000029, 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 Fri, Apr 12, 2024 at 05:46:52AM -0700, Suren Baghdasaryan wrote: > On Thu, Apr 11, 2024 at 8:14 PM Matthew Wilcox wrote: > About the code, I'll take a closer look once I'm back from vacation > this weekend but I think you will also have to modify > do_anonymous_page() to use vmf_anon_prepare() instead of > anon_vma_prepare(). Ah yes. Also do_huge_pmd_anonymous_page(). And we should do this: +++ b/mm/rmap.c @@ -182,8 +182,6 @@ static void anon_vma_chain_link(struct vm_area_struct *vma, * for the new allocation. At the same time, we do not want * to do any locking for the common case of already having * an anon_vma. - * - * This must be called with the mmap_lock held for reading. */ int __anon_vma_prepare(struct vm_area_struct *vma) { @@ -191,6 +189,7 @@ int __anon_vma_prepare(struct vm_area_struct *vma) struct anon_vma *anon_vma, *allocated; struct anon_vma_chain *avc; + mmap_assert_locked(mm); might_sleep(); avc = anon_vma_chain_alloc(GFP_KERNEL); > > We could even eagerly initialise vma->anon_vma for anon vmas. I don't > > know why we don't do that. > > You found the answer to that question a long time ago and IIRC it was > because in many cases we end up not needing to set vma->anon_vma at > all. So, this is an optimization to try avoiding extra operations > whenever we can. I'll try to find your comment on this. I thought that was file VMAs that I found the answer to that question?