On Tue, 12 Mar 2019 16:17:42 -0400 Josef Bacik <josef@xxxxxxxxxxxxxx> wrote: > We noticed a panic happening in production with the filemap fault pages > because we were unlocking a NULL page. If add_to_page_cache() fails > then we'll have a NULL page, so fix this check to only unlock if we > have a valid page. > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> > --- > mm/filemap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/filemap.c b/mm/filemap.c > index cace3eb8069f..2815cb79a246 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -1663,7 +1663,7 @@ struct page *pagecache_get_page(struct address_space *mapping, pgoff_t offset, > * add_to_page_cache_lru locks the page, and for mmap we expect > * an unlocked page. > */ > - if (fgp_flags & FGP_FOR_MMAP) > + if (page && (fgp_flags & FGP_FOR_MMAP)) > unlock_page(page); > } > Fixes "filemap: kill page_cache_read usage in filemap_fault". This patch series: filemap-kill-page_cache_read-usage-in-filemap_fault.patch filemap-kill-page_cache_read-usage-in-filemap_fault-fix.patch filemap-kill-page_cache_read-usage-in-filemap_fault-fix-2.patch filemap-pass-vm_fault-to-the-mmap-ra-helpers.patch filemap-drop-the-mmap_sem-for-all-blocking-operations.patch filemap-drop-the-mmap_sem-for-all-blocking-operations-v6.patch filemap-drop-the-mmap_sem-for-all-blocking-operations-fix.patch filemap-drop-the-mmap_sem-for-all-blocking-operations-checkpatch-fixes.patch has been stuck since December. I have a note here that syzbot reported a use-after-free. What's the situation with that? I also have a cryptic note that filemap-drop-the-mmap_sem-for-all-blocking-operations-v6.patch is "still fishy". I'm not sure what I meant by the latter - the (small amount of) review seems to be OK. Do you recall what issues there might have been and the status of those?
