fix /dev/sg allocation failures register

fix /dev/sg allocation failures register

[Christoph Hellwig]

Hi all,

Shin'ichiro reported trivially triggerable allocation failures when
using SG_IO on the sg driver.  This turn out to be caused by the
bio allocation rework, which makes non-blocking allocation fail
much easier.

This series has two independent patches to fix this from different
angles.  The first one changes the completely pointless GFP_ATOMIC
to use GFP_ATOMIC in sg.  The other drops the reduction of the gfp
mask in the bio allocator, so that atomic allocations of bios work
as expected, even if they are a pretty bad idea as the bio submission
actually needs a user context anyway.  The only other uses of this
seems to be the ocfs2 cluster managed.

[PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req

[Christoph Hellwig]

sg_start_req is called from normal user context and can sleep when
waiting for memory.  Switch it to use GFP_KERNEL, which fixes allocation
failures seend with the bio_alloc rework.

Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
---
 drivers/scsi/sg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 37bac49f30f0..43265f012ce9 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1811,7 +1811,7 @@ sg_start_req(Sg_request *srp, unsigned char *cmd)
 	}
 
 	res = blk_rq_map_user_io(rq, md, hp->dxferp, hp->dxfer_len,
-			GFP_ATOMIC, iov_count, iov_count, 1, rw);
+			GFP_KERNEL, iov_count, iov_count, 1, rw);
 	if (!res) {
 		srp->bio = rq->bio;
 
-- 
2.53.0

Re: [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req

[John Garry]

On 15/04/2026 07:08, Christoph Hellwig wrote:
> sg_start_req is called from normal user context and can sleep when
> waiting for memory.  Switch it to use GFP_KERNEL, which fixes allocation
> failures seend with the bio_alloc rework.
> 
> Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
> Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>

FWIW:

Reviewed-by: John Garry <john.g.garry@oracle.com>

Re: [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req

[Hannes Reinecke]

On 4/15/26 08:08, Christoph Hellwig wrote:
> sg_start_req is called from normal user context and can sleep when
> waiting for memory.  Switch it to use GFP_KERNEL, which fixes allocation
> failures seend with the bio_alloc rework.
> 
> Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
> Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> ---
>   drivers/scsi/sg.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index 37bac49f30f0..43265f012ce9 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -1811,7 +1811,7 @@ sg_start_req(Sg_request *srp, unsigned char *cmd)
>   	}
>   
>   	res = blk_rq_map_user_io(rq, md, hp->dxferp, hp->dxfer_len,
> -			GFP_ATOMIC, iov_count, iov_count, 1, rw);
> +			GFP_KERNEL, iov_count, iov_count, 1, rw);
>   	if (!res) {
>   		srp->bio = rq->bio;
>   
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

Re: [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req

[Bart Van Assche]

On 4/14/26 11:08 PM, Christoph Hellwig wrote:
> sg_start_req is called from normal user context and can sleep when
> waiting for memory.  Switch it to use GFP_KERNEL, which fixes allocation
> failures seend with the bio_alloc rework.

seend -> seen

Anyway:

Reviewed-by: Bart Van Assche <bvanassche@acm.org>

[PATCH 2/2] block: only restrict bio allocation gfp mask asked to block

[Christoph Hellwig]

If the caller is asking for a non-blocking allocation, we should not
further restrict the gfp mask, which just increases the likelihood
of failures.

Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 block/bio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/block/bio.c b/block/bio.c
index 641ef0928d73..12341f760b9a 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -544,7 +544,8 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 	if (WARN_ON_ONCE(!mempool_initialized(&bs->bvec_pool) && nr_vecs > 0))
 		return NULL;
 
-	gfp = try_alloc_gfp(gfp);
+	if (saved_gfp & __GFP_DIRECT_RECLAIM)
+		gfp = try_alloc_gfp(gfp);
 	if (bs->cache && nr_vecs <= BIO_INLINE_VECS) {
 		/*
 		 * Set REQ_ALLOC_CACHE even if no cached bio is available to
-- 
2.53.0

Re: [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block

[Hannes Reinecke]

On 4/15/26 08:08, Christoph Hellwig wrote:
> If the caller is asking for a non-blocking allocation, we should not
> further restrict the gfp mask, which just increases the likelihood
> of failures.
> 
> Fixes: b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath")
> Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   block/bio.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/block/bio.c b/block/bio.c
> index 641ef0928d73..12341f760b9a 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -544,7 +544,8 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
>   	if (WARN_ON_ONCE(!mempool_initialized(&bs->bvec_pool) && nr_vecs > 0))
>   		return NULL;
>   
> -	gfp = try_alloc_gfp(gfp);
> +	if (saved_gfp & __GFP_DIRECT_RECLAIM)
> +		gfp = try_alloc_gfp(gfp);
>   	if (bs->cache && nr_vecs <= BIO_INLINE_VECS) {
>   		/*
>   		 * Set REQ_ALLOC_CACHE even if no cached bio is available to

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

Re: [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block

[Bart Van Assche]

On 4/14/26 11:08 PM, Christoph Hellwig wrote:
> If the caller is asking for a non-blocking allocation, we should not
> further restrict the gfp mask, which just increases the likelihood
> of failures.
Reviewed-by: Bart Van Assche <bvanassche@acm.org>