Re: [PATCH 09/14] btrfs: return void from btrfs_finish_ordered_io

[Christoph Hellwig <hch@lst.de>]

On Tue, May 30, 2023 at 05:44:15PM +0200, David Sterba wrote:
> On Wed, May 24, 2023 at 05:03:12PM +0200, Christoph Hellwig wrote:
> > The callers don't check the btrfs_finish_ordered_io return value, so
> > drop it.
> 
> Same general comments like in
> https://lore.kernel.org/linux-btrfs/20230530150359.GS575@twin.jikos.cz/
> 
> "Function can return void if none of its callees return an error,
>  directly or indirectly, there are no BUG_ONs left to be turned to
>  proper error handling or there's no missing error handling"
> 
> btrfs_finish_ordered_io mixes a few error handling styles, there's
> direct return -ERROR, transaction abort or mapping_set_error. Some
> called functions are not error handling everything propely and at least
> btrfs_free_reserved_extent() returns an error but is not handled.
> 
> I'm not counting the state bit handlers (clear_extent_bit) as we know
> they "should not fail". unpin_extent_cache() does not look clean either.
> 
> If 'callers don't check error values' the question is 'Should they?'.

The clear answer is no, as we're in an I/O completion handler where
there is no one we could return them to.  The errors are propagate
through the mapping state.