2017-07-13 15:13:46

by Eric Whitney

[permalink] [raw]
Subject: [PATCH] ext4: clean up ext4_remove_blocks() return

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 <[email protected]>
---
fs/ext4/extents.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)

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 */
--
2.1.4


2017-07-13 22:33:54

by Theodore Ts'o

[permalink] [raw]
Subject: Re: [PATCH] ext4: clean up ext4_remove_blocks() return

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 <[email protected]>

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


2017-07-14 20:58:06

by Eric Whitney

[permalink] [raw]
Subject: Re: [PATCH] ext4: clean up ext4_remove_blocks() return

* Theodore Ts'o <[email protected]>:
> 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 <[email protected]>
>
> 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