From: SeongJae Park <email@example.com> To: <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org> Cc: Andrew Morton <email@example.com>, <firstname.lastname@example.org>, "Josef Bacik" <email@example.com>, Robert Stupp <firstname.lastname@example.org>, Minchan Kim <email@example.com>, Jan Kara <firstname.lastname@example.org> Subject: Re: [PATCH] mm: Don't bother dropping mmap_sem for zero size readahead Date: Thu, 30 Jul 2020 13:34:35 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Hello, The commit fixed by this patch was merged in v5.1 and this patch was merged in the mainline in v5.7 (5c72feee3e45b40a3c96c7145ec422899d0e8964). Thus, the issue affects [v5.1, v5.6]. I was also able to reproduce the issue and confirm the fix works on v5.4 based kernels. However, I couldn't find this fix in neither latest stable/linux-5.4.y, nor stable-queue/master. Could you please put this patch in the queue?  https://email@example.com/ Thanks, SeongJae Park On Wed, 12 Feb 2020 11:13:56 +0100 Jan Kara <firstname.lastname@example.org> wrote: > When handling a page fault, we drop mmap_sem to start async readahead so > that we don't block on IO submission with mmap_sem held. However > there's no point to drop mmap_sem in case readahead is disabled. Handle > that case to avoid pointless dropping of mmap_sem and retrying the > fault. This was actually reported to block mlockall(MCL_CURRENT) > indefinitely. > > Fixes: 6b4c9f446981 ("filemap: drop the mmap_sem for all blocking operations") > Reported-by: Minchan Kim <email@example.com> > Reported-by: Robert Stupp <firstname.lastname@example.org> > Signed-off-by: Jan Kara <email@example.com> > --- > mm/filemap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Andrew, could you please pick up this patch? Minchan also tripped over this > bug... > > diff --git a/mm/filemap.c b/mm/filemap.c > index 1146fcfa3215..3d39c437b07e 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2458,7 +2458,7 @@ static struct file *do_async_mmap_readahead(struct vm_fault *vmf, > pgoff_t offset = vmf->pgoff; > > /* If we don't want any read-ahead, don't bother */ > - if (vmf->vma->vm_flags & VM_RAND_READ) > + if (vmf->vma->vm_flags & VM_RAND_READ || !ra->ra_pages) > return fpin; > if (ra->mmap_miss > 0) > ra->mmap_miss--; > -- > 2.16.4
next prev parent reply other threads:[~2020-07-30 11:35 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-12 10:13 Jan Kara 2020-02-12 14:13 ` Josef Bacik 2020-02-12 16:16 ` Minchan Kim 2020-07-30 11:34 ` SeongJae Park [this message] 2020-08-01 10:39 ` Greg KH
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] mm: Don'\''t bother dropping mmap_sem for zero size readahead' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.