* 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