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

Matthew Wilcox
2025-10-26T21:19:34Z

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?