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 2B068EB64DD for ; Fri, 14 Jul 2023 03:04:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 923C6900008; Thu, 13 Jul 2023 23:04:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D3BD900002; Thu, 13 Jul 2023 23:04:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 775BC900008; Thu, 13 Jul 2023 23:04:47 -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 64209900002 for ; Thu, 13 Jul 2023 23:04:47 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 31920B0688 for ; Fri, 14 Jul 2023 03:04:47 +0000 (UTC) X-FDA: 81008725014.30.F651225 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf26.hostedemail.com (Postfix) with ESMTP id 5771C140005 for ; Fri, 14 Jul 2023 03:04:45 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=er6f9xnG; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689303885; 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=v4BF5nL1hHerQt4XXkZr14C1Ft2qyucggxOLcgG/mUE=; b=6h9SNpU54BbYRgS94K3+S23Q3MpS0airMBODeKjlbP3rzIVsasCvg+IBhra1zf0wdpa9J+ w7d3vqm0EaLGb7eX2wrmo/9tFxbZ0PGkfSdgea47vNUuoldulfih6D3KKdMJNAID+MF1M8 JCDuheU38aJZekCqMHgcJoAC49wkh0Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689303885; a=rsa-sha256; cv=none; b=U+50Bezx6YijY/3uaYz2P9UPQF/vfYsoMzFRZ3W8f4F79fwORSCwZoguKGVeMiC9sPVQaT mAJ0crNO8Z/KQPjGBHpicqCDmUa92yRrT+tE0L+1DYUmKoZO1eqIsFkTS/Zb2bnqm4G+xv b//KRoss3PKdH2d3GZbHFiisq4Szy+Y= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=er6f9xnG; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-cada5e4e3f6so1327483276.3 for ; Thu, 13 Jul 2023 20:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689303884; x=1691895884; 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=v4BF5nL1hHerQt4XXkZr14C1Ft2qyucggxOLcgG/mUE=; b=er6f9xnGJ2N0qzlavJE7C8fXy0dDvCJIhFU9ZDb6LeyXGIiBwWFjrgUF9waRAMHLUD Vst9Hmnuhmj+GCUAbysAnoawRb/3DKTXo38GfLYjm70NzKHKxnUaNZ6o3FW7eBCZLZfO S8PUAUbU1aBPRxWOhSxPigUFYDuqPh2xUVnHSS7AtXGGDA9KZw+G1k30WpArGVn4LkqC IlIi5MyLf/lvWZnmSDrtKLxYs5OYoU+R+vC9NuKxZSrvipU8/qHupPGmY9OK0vBJyLQv e9LTMSOJTGT8l3/L7efxA/y8rIFBGs2Po1DDtBlJxmzNyjAuh3UTa3ZE3O00moOUX53N eTfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689303884; x=1691895884; 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=v4BF5nL1hHerQt4XXkZr14C1Ft2qyucggxOLcgG/mUE=; b=ekLEdE6ZLsmlb7VdLmISYgRx1bNfu2r/Yccus3cwXs1lxpRRBa7W///Ds0hxMes3vv fMz4bHnZqRyWB84a1SnpNmP8MOKg0eLlK4a8t1q/FlqC9+ff9QTDHFbJj1Bs85xogiXY ih9F3ZE4J7Ac1ojC6dowDk9yx00UHAfGhr87BBeFm4HKA4BkaEfS0Yq/k7qYYUPqVDld bz5EcjKXnN0QxlqzVSXwH00Iyf+0ZUTfJlD3Z/TsoWlcECvq9/sDwyDmRFo9Fee9nURN 6o4R5NWpaKim8mRLT8tJ257l37VuYkEkN2pDM+e103pumZYjppeAeLFKrru9DiEU1+EC ilwQ== X-Gm-Message-State: ABy/qLZXwnakNRMgP/l/Cccme77P8Hcc4da+NZHORhlCs+cVbaRYsbjL jpUzDJwWyoo9rROJ1hGvsKo0N3zDEZrawt9s1+B1xA== X-Google-Smtp-Source: APBJJlHEUo2Sn8En4kIzeIj2RFma+K5JyjK7OTmVvujsN42wdttyWHvEBiqedgRa4i59pb4h0DT40FytdkqdZ61/pek= X-Received: by 2002:a25:3491:0:b0:c85:d8b6:c21d with SMTP id b139-20020a253491000000b00c85d8b6c21dmr2775730yba.31.1689303884251; Thu, 13 Jul 2023 20:04:44 -0700 (PDT) MIME-Version: 1.0 References: <20230711202047.3818697-1-willy@infradead.org> <20230711202047.3818697-4-willy@infradead.org> In-Reply-To: <20230711202047.3818697-4-willy@infradead.org> From: Suren Baghdasaryan Date: Thu, 13 Jul 2023 20:04:33 -0700 Message-ID: Subject: Re: [PATCH v2 3/9] mm: Move FAULT_FLAG_VMA_LOCK check from handle_mm_fault() To: "Matthew Wilcox (Oracle)" Cc: linux-mm@kvack.org, Arjun Roy , Eric Dumazet , linux-fsdevel@vger.kernel.org, Punit Agrawal Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5771C140005 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 76ms4roib8ehnnc6hkmwxybsn4837u4e X-HE-Tag: 1689303885-356626 X-HE-Meta: U2FsdGVkX18fvYXYAMARyvH8KmuFzgBAwHUnRWY1JLUmZrrcpt7kld0p/78xsdd3mFPkmQ1zvKtwc0KDdA1uwtyEcWVzk4umW+jMX/pMWtFxmjWsZS8coxwdg03BCdK9eOWbcTQisTaydP7SAPON9BBgaXghywYVybV/aXf80eohrwdjlRQpLsvMNJZ47fTtp31xScDQWa7x/13JuJkPC3o/y4Q5UHAhxazlb11LlAU01I2KOsIb1vD61XtBXPChHOmXzMtRrzND8qoW3lHENHGIPw5MgOz1r1nyaP5Jpv8yuvCmxwcL/D+ZsouWrAku0vvmZ0oQw51MSU0+F5pxiWAlpbuqAdMFPJsA+Ykv+/AWUJCMbnn+CEqkmF9z3Ay1NU5fySZYvqsnA9VL+A2vMOOkk7LnUlRiBMLz4zZXuJw1R6zRXEcki4yLXMtOUPcV8ookmgRIyPJT5yFsg96QC3Fj0OeDE9YXBnKC89ZuSB2U2EsMuBkReyCieO3GoQEeT84UprTg0mcmBZtD5Wx9zU2B3VxW0fv6WmZSDl2f0nTTlul2fS1TB80rJF6Yr5P8oLMN3hipIGeTflPPHW+ZXr+rYfhNkctxBfqskl42gdjKFAcmTmSkNRcqz+7BGFw/7KN+KNgwoSUsavVCQykqStGFXqcuW4DpHsseJ6IdtrSHaerHql+jy79g+SurOngfbjX8GGA/wAe25MkGwjmlkG+4imGLb5CftEgtWengv2U4bkhJlvCS1uNGPTRnytfhzNQeUw0WEuB9oXh/J5Qa/+4Qs2zMQ7kdTWdUBMWRt7XD0tOB4YPy8KZ/uRo8xRSiFOwfnOP0UkkDAzT1QugQEyf+ZYNbHPTHyxQxNAErv5to5Mh3Cg3tvZVHWTyQYL2dgiVS24Te1Zs1M8z1y/hL0xEhXyvOYGt1lML65hHLS0y9P7/2WfJp9D2Bx1mvK7JzrXP3/WxytPGrsw/VIEr qZGUjPmH Iwtc93/F2UQGF9alKrXlYJlbFbRJi9dYWgnQB8l90Vdy8Q+Pg1YACAdA29o+x5k+ucDtGVcg2wXh2ikYoOIkajA+SOWLupJZNyjaoGqpd4D5tfdaArbobbMcDcpO3mc/keSgoVLK2CVXWrowzU/5SxRLiyusDbonbE4EmIG4fXgSJIM6wTaKp4c8zg1RM1c2cq/aorMhqGu5Cp3Fr5wBSvaalXv+FT1XfJPwxWbP4cub8F2qaDflmdZyFV/NHmocUDYWTksaJk8DNrYm3PTw4Z/WSZSunLVGquVscoa7MUSGiT/+Lo1LcrY1sQyS2pDWz8KbNfGFViW3MEWsxaCrgk+vt2ZSLLY0juf36 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 Tue, Jul 11, 2023 at 1:20=E2=80=AFPM Matthew Wilcox (Oracle) wrote: > > Handle a little more of the page fault path outside the mmap sem. > The hugetlb path doesn't need to check whether the VMA is anonymous; > the VM_HUGETLB flag is only set on hugetlbfs VMAs. There should be no > performance change from the previous commit; this is simply a step to > ease bisection of any problems. > > Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Suren Baghdasaryan > --- > mm/hugetlb.c | 6 ++++++ > mm/memory.c | 18 +++++++++--------- > 2 files changed, 15 insertions(+), 9 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index e4a28ce0667f..109e1ff92bc8 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -6063,6 +6063,12 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, str= uct vm_area_struct *vma, > int need_wait_lock =3D 0; > unsigned long haddr =3D address & huge_page_mask(h); > > + /* TODO: Handle faults under the VMA lock */ > + if (flags & FAULT_FLAG_VMA_LOCK) { > + vma_end_read(vma); > + return VM_FAULT_RETRY; > + } > + > /* > * Serialize hugepage allocation and instantiation, so that we do= n't > * get spurious allocation failures if two CPUs race to instantia= te > diff --git a/mm/memory.c b/mm/memory.c > index f2dcc695f54e..6eda5c5f2069 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -4998,10 +4998,10 @@ static vm_fault_t handle_pte_fault(struct vm_faul= t *vmf) > } > > /* > - * By the time we get here, we already hold the mm semaphore > - * > - * The mmap_lock may have been released depending on flags and our > - * return value. See filemap_fault() and __folio_lock_or_retry(). > + * On entry, we hold either the VMA lock or the mmap_lock > + * (FAULT_FLAG_VMA_LOCK tells you which). If VM_FAULT_RETRY is set in > + * the result, the mmap_lock is not held on exit. See filemap_fault() > + * and __folio_lock_or_retry(). > */ > static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma, > unsigned long address, unsigned int flags) > @@ -5020,6 +5020,11 @@ static vm_fault_t __handle_mm_fault(struct vm_area= _struct *vma, > p4d_t *p4d; > vm_fault_t ret; > > + if ((flags & FAULT_FLAG_VMA_LOCK) && !vma_is_anonymous(vma)) { > + vma_end_read(vma); > + return VM_FAULT_RETRY; > + } > + > pgd =3D pgd_offset(mm, address); > p4d =3D p4d_alloc(mm, pgd, address); > if (!p4d) > @@ -5247,11 +5252,6 @@ vm_fault_t handle_mm_fault(struct vm_area_struct *= vma, unsigned long address, > goto out; > } > > - if ((flags & FAULT_FLAG_VMA_LOCK) && !vma_is_anonymous(vma)) { > - vma_end_read(vma); > - return VM_FAULT_RETRY; > - } > - > /* > * Enable the memcg OOM handling for faults triggered in user > * space. Kernel faults are handled more gracefully. > -- > 2.39.2 >