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 -- 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
