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 4A45FCE7AF9 for ; Thu, 28 Sep 2023 05:18:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDDAF8D00A5; Thu, 28 Sep 2023 01:18:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8F2C8D0002; Thu, 28 Sep 2023 01:18:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7C4F8D00A5; Thu, 28 Sep 2023 01:18:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A89CC8D0002 for ; Thu, 28 Sep 2023 01:18:54 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 737E81201B7 for ; Thu, 28 Sep 2023 05:18:54 +0000 (UTC) X-FDA: 81284851788.08.F0F420E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 30768140012 for ; Thu, 28 Sep 2023 05:18:51 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=t3P6ZhNP; dmarc=none; spf=none (imf26.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=1695878332; a=rsa-sha256; cv=none; b=yQf3wfqhHNS7sDZv+x8tOiR8VGhzRSuxwSpLH2Pfr3/VM6TikY8tzdC3qny0zkCUzTHUUx JEvTE4OQyZhcQgkb9L//qwjVlDzEIWRLGlPEuEULHxQiPwVf3y2v/ryWx1IaO2wP2zVuY2 /sX9tyFRSFQ/LqFutyNIPZezaEKHI9Q= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=t3P6ZhNP; dmarc=none; spf=none (imf26.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=1695878332; 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=Gatp5PjPYiNl9eGT2crCSLkW5HFBPpYwr+IR52u5E5E=; b=nafmb5fNWiF0xHtdRu3hlHaZznN97wGgJte0GTnnHqPXng/tdlka8QXYpcotWM+rTxk2tZ X4ryUh2hYF6G0xM4PvMa5mXjNeAY6NY2Fq5aXkb7B1JsMTUnuCI6UjR3YS1gWGacHFD9E/ DgenV5xbcWc5WvZ/6IBmWrLCuW1W32M= 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=Gatp5PjPYiNl9eGT2crCSLkW5HFBPpYwr+IR52u5E5E=; b=t3P6ZhNPZYS1GiHnS80nzybx7/ xbHp5bJicQvLZOC1QkBSSZyEcELYVt9ehoaf9AevOEreUEKdMsuIadMBiGg3+uigL9Mcu9Sh6/AbW vpWovoT7B+90yaUwkGH02IkQwATaOQ4AY02vBdbPSFYTb5oma8spQ0xSRfunth7DwPpu6dCd8KfTc kIKGYnKaYSe9BiKOSA/37zKyPl2GSqXFyCr9xG1nMhb1csz6hHUqO+Pv+LR9PvM3c2JLZqginUlN7 YtKBHU6wiNzcDObEJiaFoY1O/gFPrt2lD8LYHwqTeybBX628YYbFVgVXJXGDH6jLe8K45v4agpoDl 3KwN615A==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qljQG-000ayL-GL; Thu, 28 Sep 2023 05:18:48 +0000 Date: Thu, 28 Sep 2023 06:18:48 +0100 From: Matthew Wilcox To: Suren Baghdasaryan Cc: Andrew Morton , linux-mm@kvack.org Subject: Re: [PATCH 2/6] mm: Call wp_page_copy() under the VMA lock Message-ID: References: <20230927052505.2855872-1-willy@infradead.org> <20230927052505.2855872-3-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 30768140012 X-Stat-Signature: gkefmri54gd3sfq5fh61tfxkjwarn777 X-HE-Tag: 1695878331-719392 X-HE-Meta: U2FsdGVkX1+xqIWmNdJ041mjqoP8YyIg3r6J96rLBLCsPMclXOd26zOrrQDVaPdGvvUUIj8yZIVi6qZ2CSKOb/Z1UNDYXSDWwPlM1/cv9N8SSVUBZLIzUG72NAOACYs8WykEAzE3sPKbYprFmOr4xy8+VEd9NH/mz9nvGXyj1rcwNJ1+scya4GQOGeUWxG4NqpWu2C2xVPzHYjWhwX04GqJar5nXHQMId+m+xNZoBXHmvrVAPdieDY0v9RUsVflwd2JKYYeJTeSazcLdkArEZ7Mb3WYVKhde/8YoxHVJMn4E4HXHB7aa8mKFzeayTLpzC5GMBDrHLHW5Sy5goojzGtrQu8K2ZgdDPPZ5O93g/2KOlJ2C2xQE4NWU/dkVPYfYqwI7lntbCD368WF7DN9Gj13+zP/UEwvEdOcvMhc/2tY5t99ukM+Bojf7+gDtpAvKi1nBYfRr1TCiBcnznp5rzToueLaULWiN5vkEh3UG1O53x/FQjof6ojagFZ5+OJjFwzfghcOHWwnrye2viuYX6KbtwfsGgjU/cnDUkelJnJEcVpb+q/h727RVLONh/TI1Q8kaZJj/fBEMuD7SsmTfRnzc5+NG35s0ldv5OFJfwQJvJZkJ1IqWpGlYVl43r69cefK/dBeRrGeBBztDEHfuXBoza14iIDdsIc2eeX5Jarf6Ug7FZfFBqeURXNRhs/FspG70UdkEV7FhfT7vI+qJKtJus6As03kGgJx6TwO3af1okyt8eu5JZ5Q8vBu7Kk56HonKvOTdIjV+mY8Uw0h0j+EgIYsbIUT+F0QMZpDwtlnHdWdr22WHoByqr9l+p1OAYY1+1y1+7b/gLZl9PIBm3c6JaIqMynn+7jUHLKTQvDzBJBzoQ/oTMpES7cWwcgWDThs08y1wyX0dsYLKlLn34tsJjLQ98yoXDmX8Sa07ofUvjB1Knoo2vRDDsaiGHyHfJGq4W2d2AItcHqBafQj WnlHh4OK cfY+mY0mRvdoiKSThu83N3woGIUBxvQoKY9aprPlB6jZi2eNf70rsOPt3lZhUV5osR8J27siGEV89EWFeC9+BoJ3O9tWtjcNvNdxRr6lebZYUffxiAXO5npJ57Dq5HV0Rd33DAhtySdNU9+tZzNPxcBy5B/fk0nymWkoRDRP238hcmmjZVg4m9QUp1WYIYbz52SnvcV4G5p0MQPP1i+hjpjqMn6lRTerr1QxmmDjQ1jmSiF9/kTOAgBPtm2jQYdu2a7kc5KbEoLXm+Mi9dA4TeZOw500vxSP0unQUzL2AHDmgmpc= 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: On Wed, Sep 27, 2023 at 03:38:38PM -0700, Suren Baghdasaryan wrote: > On Tue, Sep 26, 2023 at 10:25 PM Matthew Wilcox (Oracle) > wrote: > > It is usually safe to call wp_page_copy() under the VMA lock. The only > > unsafe situation is when no anon_vma has been allocated for this VMA, > > and we have to look at adjacent VMAs to determine if their anon_vma can > > be shared. Since this happens only for the first COW of a page in this > > VMA, the majority of calls to wp_page_copy() do not need to fall back > > to the mmap_sem. > > > > Add vmf_anon_prepare() as an alternative to anon_vma_prepare() which > > will return RETRY if we currently hold the VMA lock and need to allocate > > an anon_vma. This lets us drop the check in do_wp_page(). > > > > Signed-off-by: Matthew Wilcox (Oracle) > > --- > > mm/memory.c | 39 ++++++++++++++++++++++++++------------- > > 1 file changed, 26 insertions(+), 13 deletions(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index 97f860d6cd2a..cff78c496728 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -3042,6 +3042,21 @@ static inline void wp_page_reuse(struct vm_fault *vmf) > > count_vm_event(PGREUSE); > > } > > > > +static vm_fault_t vmf_anon_prepare(struct vm_fault *vmf) > > +{ > > + struct vm_area_struct *vma = vmf->vma; > > + > > + if (likely(vma->anon_vma)) > > + return 0; > > + if (vmf->flags & FAULT_FLAG_VMA_LOCK) { > > I don't think the above condition will happen today because > lock_vma_under_rcu() returns NULL and do_page_fault() falls back to > taking mmap_lock when !vma->anon_vma > (https://elixir.bootlin.com/linux/v6.6-rc3/source/mm/memory.c#L5428). > We would need to narrow down that check in lock_vma_under_rcu() to > make this work here. That's only for anon VMAs. For file-backed VMAs, we can get here ... handle_pte_fault() if (vmf->flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) { if (!pte_write(entry)) return do_wp_page(vmf); ie we we have a MAP_PRIVATE of a file, first take a read-fault on it, then write to it. That causes us to allocate an anon page in this file-backed VMA, so we need an anon_vma to exist.