| Message ID | 20170713151703.GA6383@localhost.localdomain |
|---|---|
| State | Rejected, archived |
| Headers | show |
On Thu, Jul 13, 2017 at 11:17:03AM -0400, Eric Whitney wrote: > ext4_remove_blocks() never returns anything other than 0, signifying > success. Convert the function to void type to make this immediately > obvious at the call site. > > Signed-off-by: Eric Whitney <enwlinux@gmail.com> Actually, what we should do is to bubble errors up from ext4_remove_blocks to the callers of ext4_ext_rm_leaf(). At the moment it doesn't return any errors, but eventually we should be returning errors all the way up to ext4 truncate. The reason why it's a little tricky is it's more than just not deleting the call to ext4_std_error() and then returning error up to the caller. We need to make sure that file system is in a self-consistent state before we return an error up to the caller. Cheers, - Ted
* Theodore Ts'o <tytso@mit.edu>: > On Thu, Jul 13, 2017 at 11:17:03AM -0400, Eric Whitney wrote: > > ext4_remove_blocks() never returns anything other than 0, signifying > > success. Convert the function to void type to make this immediately > > obvious at the call site. > > > > Signed-off-by: Eric Whitney <enwlinux@gmail.com> > > Actually, what we should do is to bubble errors up from > ext4_remove_blocks to the callers of ext4_ext_rm_leaf(). At the > moment it doesn't return any errors, but eventually we should be > returning errors all the way up to ext4 truncate. > > The reason why it's a little tricky is it's more than just not > deleting the call to ext4_std_error() and then returning error up to > the caller. We need to make sure that file system is in a > self-consistent state before we return an error up to the caller. > > Cheers, > > - Ted > OK, that confirms a suspicion I had. That looks more like a small project than a quick cleanup, so I'll withdraw the patch and perhaps revisit this in the future. Thanks, Eric
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index e0a8425..27da180 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -2496,10 +2496,10 @@ static inline int get_default_free_blocks_flags(struct inode *inode) return 0; } -static int ext4_remove_blocks(handle_t *handle, struct inode *inode, - struct ext4_extent *ex, - long long *partial_cluster, - ext4_lblk_t from, ext4_lblk_t to) +static void ext4_remove_blocks(handle_t *handle, struct inode *inode, + struct ext4_extent *ex, + long long *partial_cluster, + ext4_lblk_t from, ext4_lblk_t to) { struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); unsigned short ee_len = ext4_ext_get_actual_len(ex); @@ -2592,7 +2592,6 @@ static int ext4_remove_blocks(handle_t *handle, struct inode *inode, ext4_error(sbi->s_sb, "strange request: removal(2) " "%u-%u from %u:%u", from, to, le32_to_cpu(ex->ee_block), ee_len); - return 0; } @@ -2720,10 +2719,7 @@ ext4_ext_rm_leaf(handle_t *handle, struct inode *inode, if (err) goto out; - err = ext4_remove_blocks(handle, inode, ex, partial_cluster, - a, b); - if (err) - goto out; + ext4_remove_blocks(handle, inode, ex, partial_cluster, a, b); if (num == 0) /* this extent is removed; mark slot entirely unused */
ext4_remove_blocks() never returns anything other than 0, signifying success. Convert the function to void type to make this immediately obvious at the call site. Signed-off-by: Eric Whitney <enwlinux@gmail.com> --- fs/ext4/extents.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-)