Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2696007imm; Thu, 18 Oct 2018 20:45:06 -0700 (PDT) X-Google-Smtp-Source: ACcGV63D8qV+fh+bZnwooS+bs04WIkf53Y9j46eRQVvqdLfsL1JrtshIPLnH/s/x+Gz5mA7Zqjcj X-Received: by 2002:a17:902:9a4c:: with SMTP id x12-v6mr31713068plv.92.1539920706567; Thu, 18 Oct 2018 20:45:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539920706; cv=none; d=google.com; s=arc-20160816; b=lEhtU/q3Sx7kM735Nt15E16xXOCI0RoitZqF/ikNz/bnTEU8oKzs5k9+nm+Uyz766R t/XQXIVAneu7Q++UD5VGX+5Z9J55/tn2/jnqNfwazwNkM0+Y/kFDCZws33iR4Ads+f9t RU9tWymTu6526zduZE+g8mTPbDiLqiqod0CtCcr1qxm2/j6lNBZM+s/xvfjsuUcCLE1o LvzSAkCWCt/CUStyefWXmvvSnGgXbSHu9jjS2fEi5qSU9oVNAOUiJ+x96CqdM9S6y7ht ypvNBpoophFnQC/RYjzWKJa8aMsddcCLIOU5vXnwavF4pNmooeNClD3fAU39c6d5QSQO 4SsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=755ncIFIe7AaH8goAAJy6fkjqf/HjrEMLXaQF3tatGY=; b=fZ1KdPLguRmkuUKNHwqWp112YxKP6Sdbx5DjSO62FDJ7Osd14cuq7jMQmwGuRH3gw+ Q3RvLLEeRuUsqhZ9d8/xXOyrpUrhEiQPSo3oAI1S1UyvBudjcAmAbCLj+PxmpRVcFQPy H4IgGxVfDS3C4Rh/j2Ri/SZcktX6lgQU6Cf3ANrCTKnA48TZajXhL5Yr1TrjeqdEA9Px syr4oeaDGp3i3StqzSXyOtfMSaqKj5PJN+4fEJ6iZPumj94eurXxLvTbJ4lHDpdfyEUK oCPkg29N1q0cK80iW7w8+TdLkzzXE19pp1WV90hZjarrJ25t7L+Uj7C+TGKaWlQ8Pigx orYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s18-v6si23243413pgg.538.2018.10.18.20.44.48; Thu, 18 Oct 2018 20:45:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726952AbeJSLsh (ORCPT + 99 others); Fri, 19 Oct 2018 07:48:37 -0400 Received: from ipmail03.adl2.internode.on.net ([150.101.137.141]:14612 "EHLO ipmail03.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726567AbeJSLsh (ORCPT ); Fri, 19 Oct 2018 07:48:37 -0400 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail03.adl2.internode.on.net with ESMTP; 19 Oct 2018 13:51:55 +1030 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1gDLMI-0006a3-Jn; Fri, 19 Oct 2018 14:21:54 +1100 Date: Fri, 19 Oct 2018 14:21:54 +1100 From: Dave Chinner To: Josef Bacik Cc: kernel-team@fb.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, tj@kernel.org, akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, riel@fb.com, linux-mm@kvack.org Subject: Re: [PATCH 3/7] mm: drop the mmap_sem in all read fault cases Message-ID: <20181019032154.GI18822@dastard> References: <20181018202318.9131-1-josef@toxicpanda.com> <20181018202318.9131-4-josef@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181018202318.9131-4-josef@toxicpanda.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 18, 2018 at 04:23:14PM -0400, Josef Bacik wrote: > Johannes' patches didn't quite cover all of the IO cases that we need to > drop the mmap_sem for, this patch covers the rest of them. > > Signed-off-by: Josef Bacik > --- > mm/filemap.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/mm/filemap.c b/mm/filemap.c > index 1ed35cd99b2c..65395ee132a0 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2523,6 +2523,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf) > int error; > struct mm_struct *mm = vmf->vma->vm_mm; > struct file *file = vmf->vma->vm_file; > + struct file *fpin = NULL; > struct address_space *mapping = file->f_mapping; > struct file_ra_state *ra = &file->f_ra; > struct inode *inode = mapping->host; > @@ -2610,11 +2611,15 @@ vm_fault_t filemap_fault(struct vm_fault *vmf) > return ret | VM_FAULT_LOCKED; > > no_cached_page: > + fpin = maybe_unlock_mmap_for_io(vmf->vma, vmf->flags); > + > /* > * We're only likely to ever get here if MADV_RANDOM is in > * effect. > */ > error = page_cache_read(file, offset, vmf->gfp_mask); > + if (fpin) > + goto out_retry; Please put the unlock after the comment explaining the goto label so it's clear that the pin is associated only with the read operations like so: no_cached_page: /* * We're only likely to ever get here if MADV_RANDOM is in * effect. */ fpin = maybe_unlock_mmap_for_io(vmf->vma, vmf->flags); error = page_cache_read(file, offset, vmf->gfp_mask); if (fpin) goto out_retry; > > /* > * The page we want has now been added to the page cache. > @@ -2634,6 +2639,8 @@ vm_fault_t filemap_fault(struct vm_fault *vmf) > return VM_FAULT_SIGBUS; > > page_not_uptodate: > + fpin = maybe_unlock_mmap_for_io(vmf->vma, vmf->flags); > + > /* > * Umm, take care of errors if the page isn't up-to-date. > * Try to re-read it _once_. We do this synchronously, Same here. Cheers, Dave. -- Dave Chinner david@fromorbit.com