Re: add more bio helper

[Christoph Hellwig <hch@lst.de>]

On Wed, Apr 23, 2025 at 06:37:41AM -0400, Kent Overstreet wrote:
> > It also don't support bio chaining or error handling and requires a
> > single bio that is guaranteed to fit the required number of vectors.
> 
> Why would bio chaining ever be required? The caller allocates both the
> buf and the bio, I've never seen an instance where you'd want that; just
> allocate a bio with the correct number of vecs, which your
> bio_vmalloc_max_vecs() helps with.

If you go beyond 1MB I/O for vmalloc you need it because a single
bio can't hold enough page size chunks.  That is unless you want
to use your own allocation for it and call bio_init which has various
other downsides.

> The "abstract over vmalloc and normal physically contigious allocations"
> bit that bch2_bio_map() does is the important part.
> 
> It's not uncommon to prefer physically contiguous allocations but have a
> vmalloc fallback; bcachefs does, and  xfs does with a clever "try the
> big allocation if it's cheap, fall back to vmalloc to avoid waiting on
> compaction" that I might steal.
> 
> is_vmalloc_addr() is also cheap, it's just a pointer comparison (and it
> really should be changed to a static inline).

The problem with transparent vmalloc handling is that it's not possible.
The magic handling for virtually indexed caches can be hidden on the
submission side, but the completion side also needs to call
invalidate_kernel_vmap_range for reads.  Requiring the caller to know
they deal vmalloc is a way to at least keep that on the radar.

The other benefit is that by forcing different calls it is much
easier to pick the optimal number of bvecs (1) for the non-vmalloc
path, although that is of course also possible without it.

Not for a purely synchronous helper we could handle both, but so far
I've not seen anything but the xfs log recovery code that needs it,
and we'd probably get into needing to pass a bio_set to avoid
deadlock when used deeper in the stack, etc.  I can look into that
if we have more than a single user, but for now it doesn't seem
worth it.

Having a common helper for vmalloc and the kernel direct mapping
is actually how I started, but then I ran into all the issues with
it and with the extremely simple helpers for the direct mapping
which are used a lot, and the more complicated version for vmalloc
which just has a few users instead.