On Tue, Jun 25, 2013 at 02:55:33PM +0530, Nagachandra P wrote: > > Here are some details on the platform > > Linux kernel version - 3.4.5 > Android - 4.2.2 > ext4 mounted with *errors=panic* option. > > We see memory allocation failures mostly caused by low memory kill the > ext4 process which is waiting for a allocation on slow path. (below is > one such instance) > > Is there a way in which we could avoid ext4 panic caused by allocation > failure (a method other than setting errors=continue :-) )? (or is > memory allocation failure considered as fatal as any other IO error) In this particular case, we could reflect the error all the way up to the ftruncate(2) system call. Fixing this is going to be a bit involved, unfortunately; we'll need to update a fairly large number of function signatures, including ext4_truncate(), ext4_ext_truncate(), ext4_free_blocks(), and a number of others. One of the problems is that there are code paths, such as ext4's evict_inode() call, where there is the potential that if there was a file descriptor holding the inode open at the time when it was unlinked, we can only delete the file (which involves a call to ext4_truncate) in ext4_evict_inode(), and there isn't a good error recovery path in that case. Probably the best short-term fix for now is to add a flag used by ext4_free_blocks() which retries the memory allocation in a loop (see the retry_alloc loop in jbd2_journal_write_metadata_buffer() in fs/jbd2/journal.c) and then initially add this flag to all of the callers of ext4_free_blocks(). We'll then need to fix the various callers where we can reflect the error back to userspace to do so, and then drop the flag. In the case of ext4_evict_inode(), what we can do is to call ext4_truncate() inode truncation in the unlink() system call if there are no other file descriptors keeping the inode from being deleted immediately. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
