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@xxxxxxx/ Thanks, SeongJae Park On Wed, 12 Feb 2020 11:13:56 +0100 Jan Kara <jack@xxxxxxx> 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@xxxxxxxxxx> > Reported-by: Robert Stupp <snazy@xxxxxx> > Signed-off-by: Jan Kara <jack@xxxxxxx> > --- > 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
