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

[Carlos Llamas <cmllamas@google.com>]

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