Re: [PATCH 2/3] mm: support fallible mempool_alloc_bulk()

[Christoph Hellwig]

On Mon, Aug 10, 2026 at 06:22:15PM +0000, Eric Biggers wrote:
> On Mon, Aug 10, 2026 at 10:21:15AM -0700, Christoph Hellwig wrote:
> > On Mon, Aug 10, 2026 at 09:14:04AM -0700, Eric Biggers wrote:
> > > On Mon, Aug 10, 2026 at 09:00:11AM -0700, Christoph Hellwig wrote:
> > > > On Thu, Aug 06, 2026 at 03:10:30PM -0700, Eric Biggers wrote:
> > > > > To fix a deadlock, blk-crypto-fallback needs to be able to make fallible
> > > > > mempool_alloc_bulk() allocations.
> > > > 
> > > > It doesn't.  fallible mempool allocations are a concept that doesn't
> > > > make much sense.  Please just go straight to the backing page allocator
> > > > instead for callers that do not need the mempool guarantees.
> > > 
> > > It does make sense.  When alloc_pages_bulk() doesn't completely succeed,
> > > there still might be pages available in the mempool.
> > 
> > But they should not go to a caller that does not need the mempool.
> 
> The caller does need the mempool.

If it does not specify a blocking GFP_* mask, it by definition does not.

> Now, as I explained in this patchset, whether this code can wait forever
> for the mempool actually depends on whether it's a recursive bio
> submission or not.  If it is, then it cannot wait, but ultimately it
> does still need to use the mempool to get a guaranteed allocation.
> 
> Falling back to the rescuer kthread (which can wait on the mempool)
> solves that.  But before taking that slow fallback, it's much more
> efficient to check the mempool directly first, since pages may be
> available there (and in fact it's fairly likely that they will be, since
> regular allocations are always used first).  The whole point of the
> mempool is that it can be used when the regular allocation fails.

What is actually efficient is do skip the mempool entirely from the
original submission context and do a non-mempool GFP_NOIO allocation,
and only in the extremely unlikely case that this fails fall back to
the rescruer thread.

> This is also the only caller of mempool_alloc_bulk().  So I'm kind of
> confused why it would not be allowed to implement the behavior that is
> desired here, especially when the non-bulk API offers it already.

Because passing GFP_ flags with all their warts is a bad idea where
we can avoid, as is using up mempool resources where not needed, and as
is having a possible failure path from a function that can only happen
for non-standard flags.  (having a return value at all is also stupid,
but that is forced on us by the braindead alloc_hooks).