| From e7676a704ee0a1ef71a6b23760b5a8f6896cb1a1 Mon Sep 17 00:00:00 2001 |
| From: Theodore Ts'o <tytso@mit.edu> |
| Date: Sat, 13 Jul 2013 00:40:35 -0400 |
| Subject: ext4: don't allow ext4_free_blocks() to fail due to ENOMEM |
| |
| From: Theodore Ts'o <tytso@mit.edu> |
| |
| commit e7676a704ee0a1ef71a6b23760b5a8f6896cb1a1 upstream. |
| |
| The filesystem should not be marked inconsistent if ext4_free_blocks() |
| is not able to allocate memory. Unfortunately some callers (most |
| notably ext4_truncate) don't have a way to reflect an error back up to |
| the VFS. And even if we did, most userspace applications won't deal |
| with most system calls returning ENOMEM anyway. |
| |
| Reported-by: Nagachandra P <nagachandra@gmail.com> |
| Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> |
| Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| |
| --- |
| fs/ext4/mballoc.c | 11 ++++++++--- |
| 1 file changed, 8 insertions(+), 3 deletions(-) |
| |
| --- a/fs/ext4/mballoc.c |
| +++ b/fs/ext4/mballoc.c |
| @@ -4622,11 +4622,16 @@ do_more: |
| * blocks being freed are metadata. these blocks shouldn't |
| * be used until this transaction is committed |
| */ |
| + retry: |
| new_entry = kmem_cache_alloc(ext4_free_data_cachep, GFP_NOFS); |
| if (!new_entry) { |
| - ext4_mb_unload_buddy(&e4b); |
| - err = -ENOMEM; |
| - goto error_return; |
| + /* |
| + * We use a retry loop because |
| + * ext4_free_blocks() is not allowed to fail. |
| + */ |
| + cond_resched(); |
| + congestion_wait(BLK_RW_ASYNC, HZ/50); |
| + goto retry; |
| } |
| new_entry->efd_start_cluster = bit; |
| new_entry->efd_group = block_group; |