Re: [RFC 00/12] bio cleanups

On Mon, Dec 08, 2025 at 12:10:07PM +0000, Andreas Gruenbacher wrote:
> Hello,
> 
> we are not quite careful enough about setting bio->bi_status in all
> places (see BACKGROUND below).  This patch queue tries to fix this by
> systematically eliminating the direct assignments to bi_status sprinkled
> all throughout the code.  Please comment.
> 
> 
> The first patch ("bio: rename bio_chain arguments") is an loosely
> related cleanup.  The remaining changes are:
> 
> - Use bio_io_error() in more places.
> 
> - Add a bio_set_errno() helper for setting bi_status based on an errno.
>   Use this helper throughout the code.
> 
> - Add a bio_set_status() helper for setting bi_status to a blk_status_t
>   status code.  Use this helper in places in the code where it's
>   necessary, or at least useful without adding any overhead.
> 
> And on top of that, we have two more cleanups:
> 
> - Add a bio_endio_errno() helper that combines bio_set_errno() and
>   bio_endio().
> 
> - Add a bio_endio_status() helper that combines bio_set_status() and
>   bio_endio().
> 
> The patches are currently based on v6.18.
> 
> GIT tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/log/?h=bio-cleanups
> 
> With these changes, only a few direct assignments to bio->bi_status
> remain, in BTRFS and in MD, and SOME OF THOSE MAY BE UNSAFE.  Could the
> maintainers of those subsystems please have a look?

The btrfs bits look good to me, we expect the same semantics, ie. not
overwrite existing error with 0. If there are racing writes to the
status like in btrfs_bio_end_io() we use cmpxchg() so we don't overwrite
it.

> Once the remaining direct assignments to bi_status are gone, we may want
> to think about "write protecting" bi_status to prevent unintended new
> direct assignments from creeping back in.

This makes sense, though I'm not sure if this takes into account the
mentioned cmpxchg pattern:

	if (status != BLK_STS_OK)
		cmpxchg(&bbio->status, BLK_STS_OK, status);