Skip to content

Commit e7676a7

Browse files
committed
ext4: don't allow ext4_free_blocks() to fail due to ENOMEM
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 <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Cc: [email protected]
1 parent bdafe42 commit e7676a7

File tree

1 file changed

+8
-3
lines changed

1 file changed

+8
-3
lines changed

fs/ext4/mballoc.c

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -4740,11 +4740,16 @@ void ext4_free_blocks(handle_t *handle, struct inode *inode,
47404740
* blocks being freed are metadata. these blocks shouldn't
47414741
* be used until this transaction is committed
47424742
*/
4743+
retry:
47434744
new_entry = kmem_cache_alloc(ext4_free_data_cachep, GFP_NOFS);
47444745
if (!new_entry) {
4745-
ext4_mb_unload_buddy(&e4b);
4746-
err = -ENOMEM;
4747-
goto error_return;
4746+
/*
4747+
* We use a retry loop because
4748+
* ext4_free_blocks() is not allowed to fail.
4749+
*/
4750+
cond_resched();
4751+
congestion_wait(BLK_RW_ASYNC, HZ/50);
4752+
goto retry;
47484753
}
47494754
new_entry->efd_start_cluster = bit;
47504755
new_entry->efd_group = block_group;

0 commit comments

Comments
 (0)