public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
* fix /dev/sg allocation failures register
@ 2026-04-15  6:08 Christoph Hellwig
  2026-04-15  6:08 ` [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req Christoph Hellwig
  2026-04-15  6:08 ` [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block Christoph Hellwig
  0 siblings, 2 replies; 8+ messages in thread
From: Christoph Hellwig @ 2026-04-15  6:08 UTC (permalink / raw)
  To: Jens Axboe, Doug Gilbert, Martin K. Petersen
  Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req
  2026-04-15  6:08 fix /dev/sg allocation failures register Christoph Hellwig
@ 2026-04-15  6:08 ` Christoph Hellwig
  2026-04-15  8:02   ` John Garry
                     ` (2 more replies)
  2026-04-15  6:08 ` [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block Christoph Hellwig
  1 sibling, 3 replies; 8+ messages in thread
From: Christoph Hellwig @ 2026-04-15  6:08 UTC (permalink / raw)
  To: Jens Axboe, Doug Gilbert, Martin K. Petersen
  Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi

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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block
  2026-04-15  6:08 fix /dev/sg allocation failures register Christoph Hellwig
  2026-04-15  6:08 ` [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req Christoph Hellwig
@ 2026-04-15  6:08 ` Christoph Hellwig
  2026-04-16  6:26   ` Hannes Reinecke
  2026-04-16 15:07   ` Bart Van Assche
  1 sibling, 2 replies; 8+ messages in thread
From: Christoph Hellwig @ 2026-04-15  6:08 UTC (permalink / raw)
  To: Jens Axboe, Doug Gilbert, Martin K. Petersen
  Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi

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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req
  2026-04-15  6:08 ` [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req Christoph Hellwig
@ 2026-04-15  8:02   ` John Garry
  2026-04-16  6:25   ` Hannes Reinecke
  2026-04-16 15:05   ` Bart Van Assche
  2 siblings, 0 replies; 8+ messages in thread
From: John Garry @ 2026-04-15  8:02 UTC (permalink / raw)
  To: Christoph Hellwig, Jens Axboe, Doug Gilbert, Martin K. Petersen
  Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi

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>



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req
  2026-04-15  6:08 ` [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req Christoph Hellwig
  2026-04-15  8:02   ` John Garry
@ 2026-04-16  6:25   ` Hannes Reinecke
  2026-04-16 15:05   ` Bart Van Assche
  2 siblings, 0 replies; 8+ messages in thread
From: Hannes Reinecke @ 2026-04-16  6:25 UTC (permalink / raw)
  To: Christoph Hellwig, Jens Axboe, Doug Gilbert, Martin K. Petersen
  Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block
  2026-04-15  6:08 ` [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block Christoph Hellwig
@ 2026-04-16  6:26   ` Hannes Reinecke
  2026-04-16 15:07   ` Bart Van Assche
  1 sibling, 0 replies; 8+ messages in thread
From: Hannes Reinecke @ 2026-04-16  6:26 UTC (permalink / raw)
  To: Christoph Hellwig, Jens Axboe, Doug Gilbert, Martin K. Petersen
  Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req
  2026-04-15  6:08 ` [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req Christoph Hellwig
  2026-04-15  8:02   ` John Garry
  2026-04-16  6:25   ` Hannes Reinecke
@ 2026-04-16 15:05   ` Bart Van Assche
  2 siblings, 0 replies; 8+ messages in thread
From: Bart Van Assche @ 2026-04-16 15:05 UTC (permalink / raw)
  To: Christoph Hellwig, Jens Axboe, Doug Gilbert, Martin K. Petersen
  Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi

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>


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block
  2026-04-15  6:08 ` [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block Christoph Hellwig
  2026-04-16  6:26   ` Hannes Reinecke
@ 2026-04-16 15:07   ` Bart Van Assche
  1 sibling, 0 replies; 8+ messages in thread
From: Bart Van Assche @ 2026-04-16 15:07 UTC (permalink / raw)
  To: Christoph Hellwig, Jens Axboe, Doug Gilbert, Martin K. Petersen
  Cc: Shin'ichiro Kawasaki, linux-block, linux-scsi

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>


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-04-16 15:07 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-15  6:08 fix /dev/sg allocation failures register Christoph Hellwig
2026-04-15  6:08 ` [PATCH 1/2] sg: don't use GFP_ATOMIC in sg_start_req Christoph Hellwig
2026-04-15  8:02   ` John Garry
2026-04-16  6:25   ` Hannes Reinecke
2026-04-16 15:05   ` Bart Van Assche
2026-04-15  6:08 ` [PATCH 2/2] block: only restrict bio allocation gfp mask asked to block Christoph Hellwig
2026-04-16  6:26   ` Hannes Reinecke
2026-04-16 15:07   ` Bart Van Assche

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox