Re: [PATCH 1/3] slab, block: generalize bvec_alloc_gfp

[Matthew Wilcox <willy@infradead.org>]

On Thu, Oct 23, 2025 at 10:08:54AM +0200, Christoph Hellwig wrote:
> +/*
> + * Make the first allocation restricted and don't dump info on allocation
> + * failures, for callers that will fall back to a mempool in case of failure.
> + */
> +static inline gfp_t try_alloc_gfp(gfp_t gfp)
> +{
> +	return (gfp & ~__GFP_DIRECT_RECLAIM) |
> +		__GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_NOWARN;
> +}

Comparing to the kvmalloc code:

        flags |= __GFP_NOWARN;

        if (!(flags & __GFP_RETRY_MAYFAIL))
                flags &= ~__GFP_DIRECT_RECLAIM;

        /* nofail semantic is implemented by the vmalloc fallback */
        flags &= ~__GFP_NOFAIL;

it's quite different.  I am by no stretch of the imagination a GFP
flags expert, but it seems to me that we should make the two the same
since they're both "try to allocate and we have a fallback if
necessary".  I suspect kvmalloc() is called with a wider range of
GFP flags than bvec allocation is, so it's probably better tested.

Is there a reason _not_ to use the kvmalloc code for bvec allocations?