xfs
[Top] [All Lists]

Re: [PATCH 14/15] xfs: prevent stack overflows from page cache allocatio

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 14/15] xfs: prevent stack overflows from page cache allocation
From: Ben Myers <bpm@xxxxxxx>
Date: Wed, 30 Oct 2013 16:40:18 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1383045118-31107-15-git-send-email-david@xxxxxxxxxxxxx>
References: <1383045118-31107-1-git-send-email-david@xxxxxxxxxxxxx> <1383045118-31107-15-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Oct 29, 2013 at 10:11:57PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> 
> Page cache allocation doesn't always go through ->begin_write and
> hence we don't always get the opportunity to set the allocation
> context to GFP_NOFS. Failing to do this means we open up the direct
> relcaim stack to recurse into the filesystem and consume a
> significant amount of stack.
> 
> On RHEL6.4 kernels we are seeing ra_submit() and
> generic_file_splice_read() from an nfsd context recursing into the
> filesystem via the inode cache shrinker and evicting inodes. This is
> causing truncation to be run (e.g EOF block freeing) and causing
> bmap btree block merges and free space btree block splits to occur.
> These btree manipulations are occurring with the call chain already
> 30 functions deep and hence there is not enough stack space to
> complete such operations.
> 
> To avoid these specific overruns, we need to prevent the page cache
> allocation from recursing via direct reclaim. We can do that because
> the allocation functions take the allocation context from that which
> is stored in the mapping for the inode. We don't set that right now,
> so the default is GFP_HIGHUSER_MOVABLE, which is effectively a
> GFP_KERNEL context. We need it to be the equivalent of GFP_NOFS, so
> when we initialise an inode, set the mapping gfp mask appropriately.
> 
> This makes the use of AOP_FLAG_NOFS redundant from other parts of
> the XFS IO path, so get rid of it.
> 
> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>

Applied this.

<Prev in Thread] Current Thread [Next in Thread>