Re: How to handle an kmalloc failure in evict_inode()?

[Theodore Ts'o <tytso@mit.edu>]

On Tue, Aug 05, 2014 at 11:13:56AM +1000, Dave Chinner wrote:
> Sure, because failing to free EOF blocks on referenced inodes (i.e. link
> count > 0) is not a serious problem. i.e. freeing speculative preallocation
> beyond EOF is a best effort operation so lock inversions or memory
> allocation failure simply means we don't do it. It'll get cleaned up
> in the future (i.e. next time the inode gets pulled into cache).

I was worried about the case where the link count == 0 and
evict_inode() needs to release the inode --- and you get a memory
allocation failure.

I didn't realize that xfs's kmem_*alloc() functions uses a retry loop.
I think these days the preferred solution from the MM folks is to use
GFP_NOFAIL (although for a long time folks like David Rientjes were
trying to claim that both GFP_NOFAIL and looping was evil, and that
all kernel code had to be able to handle memory allocation failures).

As near as I can tell, in the case of evict_inode and link_count == 0,
using either GFP_NOFAIL or GFP_NOWARN and a retry loop is the only way
to deal because in the evict_inode and link_count == 0 case, failure
is simply not an option.

> Yup, that's why XFS uses __GFP_NOWARN and a retry loop - because
> there are places where failure to allocate memory can have only
> one result: denial of service via a filesystem shutdown.

Great, the next time David Rijentes whines at me, I'll direct him in
your direction, and we can flame him together.  :-)

							- Ted