[PATCH] block: restore mempool reserves for non-block

[PATCH] block: restore mempool reserves for non-block

[Carlos Llamas]

Commit b520c4eef83d ("block: split bio_alloc_bioset more clearly into a
fast and slowpath") prevents non-blocking allocations from falling back
to mempool_alloc() after the initial slab allocation has failed. This
was based on the assumption that mempool_alloc() would simply retry the
slab and fail again (for non-block).

However, mempool_alloc() also attempts to dip into the pool reserves,
even for non-blocking requests, and this option is no longer available
after adding the early fail. This was noticed through the SCSI generic
module which calls blk_rq_map_user_io() with GFP_ATOMIC.

Remove the check to allow mempool reserves to be used for non-blocking
requests, restoring the previous behavior.

Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
Signed-off-by: Carlos Llamas <cmllamas@google.com>
---
 block/bio.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index b8972dba68a0..e8f4934593b3 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -576,13 +576,6 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 	}
 
 	if (unlikely(!bio)) {
-		/*
-		 * Give up if we are not allow to sleep as non-blocking mempool
-		 * allocations just go back to the slab allocation.
-		 */
-		if (!(saved_gfp & __GFP_DIRECT_RECLAIM))
-			return NULL;
-
 		punt_bios_to_rescuer(bs);
 
 		/*
-- 
2.54.0.545.g6539524ca2-goog

Re: [PATCH] block: restore mempool reserves for non-block

[Bart Van Assche]

On 5/3/26 2:17 AM, Carlos Llamas wrote:
> Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")

Hi Carlos,

Please help with verifying whether this patch series is sufficient: 
Christoph Hellwig, fix /dev/sg allocation failures register, April 15.
This patch series can be found by searching for "b520c4eef83d" on
lore.kernel.org.

Thanks,

Bart.

Re: [PATCH] block: restore mempool reserves for non-block

[Carlos Llamas]

On Sun, May 03, 2026 at 06:26:48AM +0200, Bart Van Assche wrote:
> On 5/3/26 2:17 AM, Carlos Llamas wrote:
> > Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
> 
> Hi Carlos,
> 
> Please help with verifying whether this patch series is sufficient:
> Christoph Hellwig, fix /dev/sg allocation failures register, April 15.
> This patch series can be found by searching for "b520c4eef83d" on
> lore.kernel.org.

Hey Bart,

I did look for fixes but I totally missed commit 7b03c93d2beb ("scsi:
sg: Don't use GFP_ATOMIC in sg_start_req()") from mkp tree. Sorry, this
patch definitely fixes the issue I'm facing. Thanks!

I actually started with this same approach as there was no apparent
reason for using GFP_ATOMIC in sg_start_req(), there is even another
might-sleep call with scsi_alloc_request() a few lines above.

However, it seemed odd to me that after removing the check added by
Christoph the mempool allocation would succeed. So there was something
else besides a failed slab request that made it work. That is how I
eventually found out about the mempool reserves.

My (very limited) understanding is that mempool_alloc() attempts to
allocate in the following order: (1) from the slab cache, (2) mempool
reserves and finally (3) sleep and wait. In this scenario, we now that
(1) has failed and (3) is not an option because of no-block flags.
However, mempool reserves are still a valid option.

Anyway, I just wanted to point that out in case the check needs to be
revisited. I'll cherry-pick the fix from Martin's tree for now.

Cheers!
--
Carlos Llamas

Re: [PATCH] block: restore mempool reserves for non-block

[Christoph Hellwig]

On Sun, May 03, 2026 at 03:01:53PM +0000, Carlos Llamas wrote:
> On Sun, May 03, 2026 at 06:26:48AM +0200, Bart Van Assche wrote:
> > On 5/3/26 2:17 AM, Carlos Llamas wrote:
> > > Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
> > 
> > Hi Carlos,
> > 
> > Please help with verifying whether this patch series is sufficient:
> > Christoph Hellwig, fix /dev/sg allocation failures register, April 15.
> > This patch series can be found by searching for "b520c4eef83d" on
> > lore.kernel.org.
> 
> Hey Bart,
> 
> I did look for fixes but I totally missed commit 7b03c93d2beb ("scsi:
> sg: Don't use GFP_ATOMIC in sg_start_req()") from mkp tree. Sorry, this
> patch definitely fixes the issue I'm facing. Thanks!

Also b5129bda5bbc ("block: only restrict bio allocation gfp mask asked
to block") in the block tree.  Both of these should fix the issue
you're seeing, and both are good on their own.