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 706D0E732DF for ; Thu, 28 Sep 2023 14:57:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB1638D00B5; Thu, 28 Sep 2023 10:57:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E618A8D0023; Thu, 28 Sep 2023 10:57:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D293A8D00B5; Thu, 28 Sep 2023 10:57:23 -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 C28128D0023 for ; Thu, 28 Sep 2023 10:57:23 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7A982140F1E for ; Thu, 28 Sep 2023 14:57:23 +0000 (UTC) X-FDA: 81286309566.07.3F9DD03 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf26.hostedemail.com (Postfix) with ESMTP id BD328140016 for ; Thu, 28 Sep 2023 14:57:21 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Jc+ch4KM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695913041; 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=1J+NAOOLPtsXAOlMRsbLQmCEgWVpgAT72ATvWjvuNzU=; b=ilGZOLHNjKLb/1+RB7oVSuwJIJJ9pVM2mBzWPGLnFz9MQcXRHl5m6xXZDws8M/PDiyNhPk dVcKg5lLslRNCwDrBAuA5z1LilEoUsLbl9450qja9eKDGI6FKRS3R46+KMU0FDSolV+nma Y3VB86rGl8bguGoRslgDZxYyjJcbIRE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Jc+ch4KM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695913041; a=rsa-sha256; cv=none; b=FUDsnQC0Z81uU6klLffKzlIc5bXa7RfcwptzAp2l0G3AzwuXJyvUhXBdlg4xQhC5in8Vor zFkakKkdil0IJEN1efK1oGQVqhsvBYD13XYrHLHV+rLYWWgghReuYBRHYLZnkEjW28zC/9 5OGJ1MN7cDFbeauhba1JAkpyDWXDyhs= Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-d81d09d883dso14786478276.0 for ; Thu, 28 Sep 2023 07:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695913041; x=1696517841; 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=1J+NAOOLPtsXAOlMRsbLQmCEgWVpgAT72ATvWjvuNzU=; b=Jc+ch4KMAnS9pRHH+V+BBfimXcFkfRa/L72sgeo9Un4N2nKXwkyqYgBeMnHsCSu6gl sw+y6lW0gmW7qCxH0rTQtf3PycCbnyI8G7KL6VJZUwFXyEKaDkjsI+4IpA1ZhLUkZB31 4M/GhN5xd+/LB7LNbjXuESFF1qSfWopJoWHpBlKhMTSqytxHO422TaBQRN2zWAGEXrV9 zPtB8d3Td/BDVBPW0lehznUyKVPrRxt4dEf+ZAuNoGWyjJxXUPzJSZUDAZErrMYS52sc 5OC+mGDPUW7jJ3Wkv/VzjmfUaVFEWrcoeLNCdhARbkuwwOIAYPtZldDPi3nbgiZtRA3K TsZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695913041; x=1696517841; 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=1J+NAOOLPtsXAOlMRsbLQmCEgWVpgAT72ATvWjvuNzU=; b=uVwBkwoTR3XwPlJOsbZHvZSZLoBA3T9tV/fwzvOLHKJnYGFJK7S3YZjBoim849/ZGc 5eepI0JMaTPe+vZ2eYV/8Kl6i0vrhvqqAFsixrs98uLCBanOMYKyBFjIx332Y9aCASKz UkToXL84VspBHsZdATxz6tnfEsxPqVnMT5uZ/zz8OoUrQv11HZo7AhqsFtORZIuHK1Cp rd8VHD16gtqU+uOPMe3Hi9P4rtihkRausCx78U9sTV2hQhZ48k/NMn/aGD7l3QvEDZs1 zFppskyp7sc+gkUc92A5/1UcFxsXB8FY1w8gh+W16CPJcHEWmZ2xZg9EoNKas6pT79OQ fK0Q== X-Gm-Message-State: AOJu0YwdU7rTXoZ6DSgKplU8t0cBFTH63Aysh/opDQg/vPYHXPfnHjVU KuKJomQ1OdmClTQNCtwMSrrhNUkSNQvof4A4K08jHgU8H5PmohtZqAY= X-Google-Smtp-Source: AGHT+IELOUcQG1m4iLxanQdcI+/PeU/WhgW2rkjnCIWBkboSMDE50ZFiyuWRoNLQOGlheNP0OXG8uDjPMmYnH24vGd4= X-Received: by 2002:a25:dc11:0:b0:d78:134:9477 with SMTP id y17-20020a25dc11000000b00d7801349477mr1481990ybe.58.1695913040633; Thu, 28 Sep 2023 07:57:20 -0700 (PDT) MIME-Version: 1.0 References: <20230927052505.2855872-1-willy@infradead.org> <20230927052505.2855872-3-willy@infradead.org> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 28 Sep 2023 07:57:07 -0700 Message-ID: Subject: Re: [PATCH 2/6] mm: Call wp_page_copy() under the VMA lock To: Matthew Wilcox Cc: Andrew Morton , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: BD328140016 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 3itmcbaozbs8b7cuijwo8xbhb9qf54gy X-HE-Tag: 1695913041-567508 X-HE-Meta: U2FsdGVkX1/O6GaqQKxYmjAC/5qBnFIq0cFFTLD0O9j2nEd7wuTkfzUKD+3/EC2um8CXTW9ux6oM/WbtAno3a1FmmsuuP5zEV3ndh3Du04sc/pu8u6U+UX4x2Qf7/jxv2UI9Qo0cA0T8pMkh01ug+to+hEvDtfT78AVCH2RqYtFMgqb/jsN48SNvoCSAMXPel/xHm6FaGys325ooXSa5uUE/YcNOR00JdLpBp4X/efMOA0mzsa4VnGr1wZ8v6FCmyk+1iUMVsb3EFuo2TK7qJD+r2IbY0/g/szZrnW3VafwlMCtELFjfHPpZiqulZr0r+obkz4v7w+Lr/0OV5RwTQXdM7p9CNIhkOougiZihON+NlAEuLxkoIBWd0FcFJF8Hz6Fm4i6lovSHI6k+2CRmImY9V7um2XlTmOYWQQhH7a8OMMhPKdO7TvNdNAnFGh2yt7FQepjtp6x+5irTDPUUXvTjUzn7clVAte+gHRIdO1YJitkdCgrbCeB5JVZs5ybq6VG/6qwEzZndszX6eThZrvP+qaZV7wzX+69Pz/daWnJkkyA4XKmw4cV88astDCHMORLT17moMAE6wv4Ia50B5xCKyjQuGMroDZ+CXHO2v2xMsp/G1zv+42Fi4QTVUsJ/gvyW7sG/TxVQY6t8YMGJHMDJrk3JMltAtHYxUNuIRkRkLj1IdrJmqFGSSmZWj8WDzU538GZCYtPX3UzEtPtB0UkL6W3kbe17OHOtMneoFuk5ah+lh+tV3MqihylPd1StnTCFWW1LNWdglW+3cSg+YPRfzjOhllgQJIZOCCYFzSqWHyJW+aInJWlEudRFXp8vsAOgnEV9ZjNspdyxRx1/Gcf2C0+mRBLDFDYV4qTdSmOaR78mBFZpa5suSgkPtqVzGQWWIjb0c2R84BTC8+DJ1XjPWDvSisCKRQJ8nkBGKJv24aW8NX56rtyjH/nVmah2Y670vFbpF5v31OfpHHF 3n4IzXXd fNMSCR4NsKAgYLSRVZUPGGMoWZocaXxwSaOF4PBmVnTttrCB6WpjNfbbzCIvfIrvAHkWvXXyYsFGK9WMzqH8S83e7j9XcNG4CSEgPyI+tf8Ov6yKMFth+ehluUKX1FiBSRToq6WAOzgfa+Ab+jsjDug00WUenh/bKs4plbvJ6OjNXbgmilNLelXyszrs6bIdkkiIsLeEvNY/Sn/rfMSOtunRFl3LfzeuDMonCDC0L4NJK8iHQZmOLGxTcmk4m7CZOv0H2P+PiQ96dlGG1Dyrwb+1T33EfGWbgnvjy9l5TL1Z88hJxF4CV7RQxA5yGOSD0z3aiwhddl6N/XnxJ9waWsYHc5Tjvu1O7eUapMt9uhN+KJr6kykU6i97wMonfmSuKMriFRDUVwsB4zXc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000230, 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 10:18=E2=80=AFPM Matthew Wilcox wrote: > > On Wed, Sep 27, 2023 at 03:38:38PM -0700, Suren Baghdasaryan wrote: > > On Tue, Sep 26, 2023 at 10:25=E2=80=AFPM Matthew Wilcox (Oracle) > > wrote: > > > It is usually safe to call wp_page_copy() under the VMA lock. The on= ly > > > 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 c= an > > > be shared. Since this happens only for the first COW of a page in th= is > > > 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 alloc= ate > > > 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_fau= lt *vmf) > > > count_vm_event(PGREUSE); > > > } > > > > > > +static vm_fault_t vmf_anon_prepare(struct vm_fault *vmf) > > > +{ > > > + struct vm_area_struct *vma =3D 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. Oh, sorry, I completely missed that this check was only for anon VMAs. Now it makes sense. Thanks!