On Fri, Aug 28, 2020 at 06:31:22PM +0100, Matthew Wilcox wrote: > On Fri, Aug 28, 2020 at 10:08:52AM -0700, Hugh Dickins wrote: > > It's a good observation of an oddity that I probably didn't think of, > > but you haven't said which kind of shmem page accounting goes wrong here > > (vm_enough_memory? df of filesystem? du of filesystem? memcg charge? > > all of the above? observed in practice?), and what needs solving. Oh, I forgot to say which > The problem I've observed in practice is following the same pattern in > truncate_inode_pages_range(). The call to delete_from_page_cache_batch() > trips the assertion that the page hasn't already been deleted from the > page cache. I think the solution is obvious -- don't add the page to > locked_pvec if page->mapping is NULL. Here's the change I'm currently testing. It's survived about eight minutes of xfstests so far, which is far longer than it was surviving before. - /* Try to split huge page, so we can truly punch the hole or truncate */ - return split_huge_page(page) >= 0; + /* + * split_huge_page may remove the page itself; if so, we should + * not attempt to remove it again. + */ + return split_huge_page(page) >= 0 && page->mapping;
