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 <nagachandra@gmail.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org
This commit is contained in:
		
							parent
							
								
									bdafe42aaf
								
							
						
					
					
						commit
						e7676a704e
					
				| @ -4740,11 +4740,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; | ||||
|  | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user