| Message ID | 20200212101356.30759-1-jack@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mm: Don't bother dropping mmap_sem for zero size readahead | expand |
On 2/12/20 5:13 AM, Jan Kara 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 <minchan@kernel.org> > Reported-by: Robert Stupp <snazy@gmx.de> > Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Thanks, Josef
On Wed, Feb 12, 2020 at 11:13:56AM +0100, Jan Kara 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 <minchan@kernel.org> > Reported-by: Robert Stupp <snazy@gmx.de> > Signed-off-by: Jan Kara <jack@suse.cz> Reveiewed-by: Minchan Kim <minchan@kernel.org>
Hello, The commit fixed by this patch[1] 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? [1] https://lore.kernel.org/linux-mm/20200212101356.30759-1-jack@suse.cz/ Thanks, SeongJae Park On Wed, 12 Feb 2020 11:13:56 +0100 Jan Kara <jack@suse.cz> 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 <minchan@kernel.org> > Reported-by: Robert Stupp <snazy@gmx.de> > Signed-off-by: Jan Kara <jack@suse.cz> > --- > 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
On Thu, Jul 30, 2020 at 01:34:35PM +0200, SeongJae Park wrote: > Hello, > > > The commit fixed by this patch[1] 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? > > [1] https://lore.kernel.org/linux-mm/20200212101356.30759-1-jack@suse.cz/ Now queued up, thanks. greg k-h
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--;
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 <minchan@kernel.org> Reported-by: Robert Stupp <snazy@gmx.de> Signed-off-by: Jan Kara <jack@suse.cz> --- 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...