[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181217144101.GN10600@bombadil.infradead.org>
Date: Mon, 17 Dec 2018 06:41:01 -0800
From: Matthew Wilcox <willy@...radead.org>
To: Michal Hocko <mhocko@...nel.org>
Cc: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Hou Tao <houtao1@...wei.com>, phillip@...ashfs.org.uk,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH] squashfs: enable __GFP_FS in ->readpage to prevent hang
in mem alloc
On Mon, Dec 17, 2018 at 03:10:44PM +0100, Michal Hocko wrote:
> On Mon 17-12-18 04:25:46, Matthew Wilcox wrote:
> > It's worth noticing that squashfs _is_ in fact holding a page locked in
> > squashfs_copy_cache() when it calls grab_cache_page_nowait(). I'm not
> > sure if this will lead to trouble or not because I'm insufficiently
> > familiar with the reclaim path.
>
> Hmm, this is more interesting then. If there is any memcg accounted
> allocation down that path _and_ the squashfs writeout can lock more
> pages and mark them writeback before they are really sent to the storage
> then we have a problem. See [1]
>
> [1] http://lkml.kernel.org/r/20181213092221.27270-1-mhocko@kernel.org
Squashfs is read only, so it'll never have dirty pages and never do
writeout.
But ... maybe the GFP flags being used for grab_cache_page_nowait() are
wrong. It does, after all, say "nowait". Perhaps it shouldn't be trying
direct reclaim at all, but rather fail earlier. Like this:
+++ b/mm/filemap.c
@@ -1550,6 +1550,8 @@ struct page *pagecache_get_page(struct address_space *mapping, pgoff_t offset,
gfp_mask |= __GFP_WRITE;
if (fgp_flags & FGP_NOFS)
gfp_mask &= ~__GFP_FS;
+ if (fgp_flags & FGP_NOWAIT)
+ gfp_mask &= ~__GFP_DIRECT_RECLAIM;
page = __page_cache_alloc(gfp_mask);
if (!page)
Powered by blists - more mailing lists