Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2714407rwd; Fri, 9 Jun 2023 16:02:36 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6xxXmPKkcWobKGYmaSvd6FKabi20oT0RuiNIu/8L76B1Q65AYj7kymG5sVo1ZnSFbVmzgl X-Received: by 2002:a05:6a20:8f07:b0:10d:1213:432a with SMTP id b7-20020a056a208f0700b0010d1213432amr2628878pzk.33.1686351756284; Fri, 09 Jun 2023 16:02:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686351756; cv=none; d=google.com; s=arc-20160816; b=h2gwfj/73tEcY5/coipw86JXh/HZtls7KPBzPgC6703bhw3ENIWfz5Pfphx8HcQKnF vX+mxalL9/9rCkSjj76H6ipcnhMY2F/MDxfo6Yv+HXo15Vyq2pO9E1eNOK1cEkI5kYn8 vk2acWOQDIBogM32sTHlZVhVqiT4wMoyYeUFmBeCFD/bDObNG8N9S8Bd3cNOs6gbHznT 3LdOEdn1eBWNsP1l0nh/2lZkboEQRSgTEWdWbMKqZVcZt0CUYKFNvWyZ5qowfE83b2Hn XS423QjD4Xg2WlqxvYJ+ZaR61puZkghlIW18U9pFBtVVeSqLnTn74ez0dEMnFUIU07Ed LDww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=F91PTYUlrDQnVkE7RKrpSVNT7i04Oh1Dw138WVZlpbs=; b=ZjU4MKv4tPP4iTaWjc++6+xZec0S2cxhQwvbhwv3o+8+lSDbpC0MsitpLh+rNzi0vT eW67L1hMMLeH6bD3zKi6Cyeyg3KAWYrJBdt8KqvumVuyV6BvegOCAkn7R9ZcZTrV7qdx vSj/DfCnM2kK3lV+S2oTs3N8MyhqF0kDgPPCsQqFpbz3O9UfsOfe52mLAWUyOe4mU/kF +ZD1CVOftyF+GR7UcVW45d3SGfeJo+9diMcructFxdcXqugdgm0+tTSHcewiA/EEO5ZA ad8A5rxKEeH+kdvMjI3iBj6742vlMlt9wxs5ew+02QxTJERGqtr+GJvESYG5oovGJb0A FI6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=JZTcd7Fe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q29-20020aa7961d000000b006546d0d5832si87921pfg.183.2023.06.09.16.02.22; Fri, 09 Jun 2023 16:02:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=JZTcd7Fe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232101AbjFIWsT (ORCPT + 99 others); Fri, 9 Jun 2023 18:48:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231909AbjFIWsR (ORCPT ); Fri, 9 Jun 2023 18:48:17 -0400 Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E2FD1BD for ; Fri, 9 Jun 2023 15:48:16 -0700 (PDT) Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-565ba6aee5fso21201787b3.1 for ; Fri, 09 Jun 2023 15:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686350895; x=1688942895; 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=F91PTYUlrDQnVkE7RKrpSVNT7i04Oh1Dw138WVZlpbs=; b=JZTcd7Fed6d6MEyF97USXRMaHw+sgtWUBuHPeimUwjK1rzC5oe4wagRydts4z3MQRP HyzZbp6IpjvDc+FfUHgjU/hoH7suGHRab9a3ft17mDJUCD3jjh5QixhFWwhvHVTHo1tu dzILydbycNbIOph5HeQuN/Tm4GFapGcFDSaeexgGfG4tqSTbXQp8ststuYhd/MJe0r5/ ReRpAdq2AaUnI6V4KHZzcsmP8fs/qDxugMk2woF8/PGscOi9/OlUT4p29IyMwhRQKqvv 0cfzKSNyfvQneCU+6BWWe3Ce22UuSbQa695dXI2BZFNBBD3ERkBcLYKLaHeQrrTdvxK4 KwNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686350895; x=1688942895; 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=F91PTYUlrDQnVkE7RKrpSVNT7i04Oh1Dw138WVZlpbs=; b=j02mCm2xUsmW+7PhMjfOFwgr3OsWDqfmge42Ku6BM3LF9RkKJX07cMaR/7MJuQOUcc 1/A2O7Tcg/TVUGVlPt/Tf6PpshgCwtKuG+XdWCEHYB/bRmhgQu9S39OXh6skTrXVOrjN AQMpUeQOYGWN5afzfnFOYbj9tRUguUN9ZRUu/e8iILh2UKegcgHprU5tqMR27oNxsDjO ih9qhSx5jJAvEuSr8++QcR68xwNSWOs2CQyQDxbURoPl596DsToROK6RCiy6dPIhGTbD XZbfPJjlWnNLSAG9mxnD8OmOXXwfRyCeSZXAn27pVp1S3xqYd4serSnFUR4rODj6Tz1e cVhg== X-Gm-Message-State: AC+VfDx59G2CgB1KdzKWLR7gLrCa0yelM7y84PZQLRsZVQ/7U45KZDHk CHKHAHB9Wsz0GVxXhr3811jOmGBtJgcu98v+9IbAog== X-Received: by 2002:a0d:ca92:0:b0:561:e873:9225 with SMTP id m140-20020a0dca92000000b00561e8739225mr2499230ywd.27.1686350895117; Fri, 09 Jun 2023 15:48:15 -0700 (PDT) MIME-Version: 1.0 References: <20230609005158.2421285-1-surenb@google.com> <20230609005158.2421285-6-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 9 Jun 2023 15:48:04 -0700 Message-ID: Subject: Re: [PATCH v2 5/6] mm: implement folio wait under VMA lock To: Peter Xu Cc: akpm@linux-foundation.org, willy@infradead.org, hannes@cmpxchg.org, mhocko@suse.com, josef@toxicpanda.com, jack@suse.cz, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, michel@lespinasse.org, liam.howlett@oracle.com, jglisse@google.com, vbabka@suse.cz, minchan@google.com, dave@stgolabs.net, punit.agrawal@bytedance.com, lstoakes@gmail.com, hdanton@sina.com, apopple@nvidia.com, ying.huang@intel.com, david@redhat.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 9, 2023 at 1:54=E2=80=AFPM Peter Xu wrote: > > On Thu, Jun 08, 2023 at 05:51:57PM -0700, Suren Baghdasaryan wrote: > > Follow the same pattern as mmap_lock when waiting for folio by dropping > > VMA lock before the wait and retrying once folio is available. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > include/linux/pagemap.h | 14 ++++++++++---- > > mm/filemap.c | 43 ++++++++++++++++++++++------------------- > > mm/memory.c | 13 ++++++++----- > > 3 files changed, 41 insertions(+), 29 deletions(-) > > > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > > index a56308a9d1a4..6c9493314c21 100644 > > --- a/include/linux/pagemap.h > > +++ b/include/linux/pagemap.h > > @@ -896,8 +896,8 @@ static inline bool wake_page_match(struct wait_page= _queue *wait_page, > > > > void __folio_lock(struct folio *folio); > > int __folio_lock_killable(struct folio *folio); > > -bool __folio_lock_or_retry(struct folio *folio, struct mm_struct *mm, > > - unsigned int flags); > > +bool __folio_lock_or_retry(struct folio *folio, struct vm_area_struct = *vma, > > + unsigned int flags, bool *lock_dropped); > > void unlock_page(struct page *page); > > void folio_unlock(struct folio *folio); > > > > @@ -1002,10 +1002,16 @@ static inline int folio_lock_killable(struct fo= lio *folio) > > * __folio_lock_or_retry(). > > */ > > static inline bool folio_lock_or_retry(struct folio *folio, > > - struct mm_struct *mm, unsigned int flags) > > + struct vm_area_struct *vma, unsigned int flags, > > + bool *lock_dropped) > > { > > might_sleep(); > > - return folio_trylock(folio) || __folio_lock_or_retry(folio, mm, f= lags); > > + if (folio_trylock(folio)) { > > + *lock_dropped =3D false; > > + return true; > > + } > > + > > + return __folio_lock_or_retry(folio, vma, flags, lock_dropped); > > } > > > > /* > > diff --git a/mm/filemap.c b/mm/filemap.c > > index 7cb0a3776a07..838955635fbc 100644 > > --- a/mm/filemap.c > > +++ b/mm/filemap.c > > @@ -1701,37 +1701,35 @@ static int __folio_lock_async(struct folio *fol= io, struct wait_page_queue *wait) > > > > /* > > * Return values: > > - * true - folio is locked; mmap_lock is still held. > > + * true - folio is locked. > > * false - folio is not locked. > > - * mmap_lock has been released (mmap_read_unlock(), unless flags h= ad both > > - * FAULT_FLAG_ALLOW_RETRY and FAULT_FLAG_RETRY_NOWAIT set, in > > - * which case mmap_lock is still held. > > - * If flags had FAULT_FLAG_VMA_LOCK set, meaning the operation is = performed > > - * with VMA lock only, the VMA lock is still held. > > + * > > + * lock_dropped indicates whether mmap_lock/VMA lock got dropped. > > + * mmap_lock/VMA lock is dropped when function fails to lock the f= olio, > > + * unless flags had both FAULT_FLAG_ALLOW_RETRY and FAULT_FLAG_RET= RY_NOWAIT > > + * set, in which case mmap_lock/VMA lock is still held. > > This seems to be a separate change to have "lock_dropped", would it worth= a > separate patch for it if needed? Yes, Matthew asked for the same and also to change the function to return the flags directly which should make it cleaner. IOW when this function drops the lock it will include VM_FAULT_VMA_UNLOCKED flag in its return value. And that will be done in a separate patch. > > I do agree it's confusing and it might be the reason of this change, but = I > think it may or may not help much.. as long as VM_FAULT_RETRY semantics > kept unchanged iiuc (it doesn't always imply mmap lock released, only if > !NOWAIT, which can be confusing too). > > Especially that doesn't seem like a must for the vma change. IIUC to > support vma lock here we can simply keep everything as before, but only > release proper lock based on the fault flag should work. But maybe I jus= t > missed something, so that relies on the answer to previous patch... That was my intention here, IOW I'm making the following replacement: - mmap_read_unlock(mm); + if (flags & FAULT_FLAG_VMA_LOCK) + vma_end_read(vma); + else + mmap_read_unlock(vma->vm_mm); Did I miss something which makes the function work differently between mmap_lock vs per-vma one? > > > * > > * If neither ALLOW_RETRY nor KILLABLE are set, will always return tru= e > > - * with the folio locked and the mmap_lock unperturbed. > > + * with the folio locked and the mmap_lock/VMA lock unperturbed. > > */ > > -bool __folio_lock_or_retry(struct folio *folio, struct mm_struct *mm, > > - unsigned int flags) > > +bool __folio_lock_or_retry(struct folio *folio, struct vm_area_struct = *vma, > > + unsigned int flags, bool *lock_dropped) > > { > > - /* Can't do this if not holding mmap_lock */ > > - if (flags & FAULT_FLAG_VMA_LOCK) > > - return false; > > - > > if (fault_flag_allow_retry_first(flags)) { > > - /* > > - * CAUTION! In this case, mmap_lock is not released > > - * even though return 0. > > - */ > > - if (flags & FAULT_FLAG_RETRY_NOWAIT) > > + if (flags & FAULT_FLAG_RETRY_NOWAIT) { > > + *lock_dropped =3D false; > > return false; > > + } > > > > - mmap_read_unlock(mm); > > + if (flags & FAULT_FLAG_VMA_LOCK) > > + vma_end_read(vma); > > + else > > + mmap_read_unlock(vma->vm_mm); > > if (flags & FAULT_FLAG_KILLABLE) > > folio_wait_locked_killable(folio); > > else > > folio_wait_locked(folio); > > + *lock_dropped =3D true; > > return false; > > } > > if (flags & FAULT_FLAG_KILLABLE) { > > @@ -1739,13 +1737,18 @@ bool __folio_lock_or_retry(struct folio *folio,= struct mm_struct *mm, > > > > ret =3D __folio_lock_killable(folio); > > if (ret) { > > - mmap_read_unlock(mm); > > + if (flags & FAULT_FLAG_VMA_LOCK) > > + vma_end_read(vma); > > + else > > + mmap_read_unlock(vma->vm_mm); > > + *lock_dropped =3D true; > > return false; > > } > > } else { > > __folio_lock(folio); > > } > > > > + *lock_dropped =3D false; > > return true; > > } > > > > diff --git a/mm/memory.c b/mm/memory.c > > index c234f8085f1e..acb09a3aad53 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -3568,6 +3568,7 @@ static vm_fault_t remove_device_exclusive_entry(s= truct vm_fault *vmf) > > struct folio *folio =3D page_folio(vmf->page); > > struct vm_area_struct *vma =3D vmf->vma; > > struct mmu_notifier_range range; > > + bool lock_dropped; > > > > /* > > * We need a reference to lock the folio because we don't hold > > @@ -3580,8 +3581,10 @@ static vm_fault_t remove_device_exclusive_entry(= struct vm_fault *vmf) > > if (!folio_try_get(folio)) > > return 0; > > > > - if (!folio_lock_or_retry(folio, vma->vm_mm, vmf->flags)) { > > + if (!folio_lock_or_retry(folio, vma, vmf->flags, &lock_dropped)) = { > > folio_put(folio); > > + if (lock_dropped && vmf->flags & FAULT_FLAG_VMA_LOCK) > > + return VM_FAULT_VMA_UNLOCKED | VM_FAULT_RETRY; > > return VM_FAULT_RETRY; > > } > > mmu_notifier_range_init_owner(&range, MMU_NOTIFY_EXCLUSIVE, 0, > > @@ -3704,7 +3707,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > bool exclusive =3D false; > > swp_entry_t entry; > > pte_t pte; > > - int locked; > > + bool lock_dropped; > > vm_fault_t ret =3D 0; > > void *shadow =3D NULL; > > > > @@ -3837,9 +3840,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > goto out_release; > > } > > > > - locked =3D folio_lock_or_retry(folio, vma->vm_mm, vmf->flags); > > - > > - if (!locked) { > > + if (!folio_lock_or_retry(folio, vma, vmf->flags, &lock_dropped)) = { > > + if (lock_dropped && vmf->flags & FAULT_FLAG_VMA_LOCK) > > + ret |=3D VM_FAULT_VMA_UNLOCKED; > > ret |=3D VM_FAULT_RETRY; > > goto out_release; > > } > > -- > > 2.41.0.162.gfafddb0af9-goog > > > > -- > Peter Xu >