I've been trying to figure out the best way to handle potential memory
allocation failures in evict_inode(), since there doesn't seem to be any
way to reflect errors back up to the caller, or to delay the inode
eviction until more memory might be available.
There doesn't seem to be a good solution; right now, in ext4, we mark
the file system as being inconsistent, thus triggering a remount
read-only or a panic, which seems to be.... sub-optimal.
I was looking to see what xfs does to handle this case, and as near as I
can tell, xfs_fs_evict_inode() calls xfs_inactive(), which in turn calls
xfs_free_eofblocks() --- and ignores the error return. And when I look
to see whether xfs_free_eofblocks() can return ENOMEM, it appears that
it can, via a call path that involves xfs_bmapi_read(),
xfs_iread_extents(), xfs_bmap_read_extents(), xfs_btree_read_bufl(),
xfs_trans_read_buf(), xfs_trans_read_buf_map(), xfs_buf_read_map(),
xfs_buf_get_map(), _xfs_buf_alloc(), which can return ENOMEM.
As near as I can tell, at least for ext4, we've been remarkably lucky,
in that GFP_NOFS allocations seem to rarely if ever fail. However,
under enough memory pressure, and in a situation where the OOM killer
has been configured to be less aggressive, it is possible (which is as
we would expect) for a kmalloc() to fail, and short of using
_GFP_NOFAIL, or using a retry loop, I'm not sure there's a good answer
to this problem.
Am I missing something obvious? Has someone come up with a good way of
dealing with the need to release an inode and its blocks in
evict_inode(), and what to do if a memory allocation fails for some
reason?
Thanks,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
