block: don't use blocking queue entered for recursive bio submits
Subsystems (2)
PATCH v2 1/1 block: don't use blocking queue entered for recursive bio submits
commit cd4a4ae4683dc2e09380118e205e057896dcda2b upstream.
If we end up splitting a bio and the queue goes away between the initial submission and the later split submission, then we can block forever in blk_queue_enter() waiting for the reference to drop to zero. This will never happen, since we already hold a reference.
Mark a split bio as already having entered the queue, so we can just use the live non-blocking queue enter variant.
Thanks to Tetsuo Handa for the analysis.
We're running fio tests and the tasks get stuck in a D state forever when systemd-udevd tries to read the partition table. This patch solves it. Please apply to 4.17 stable.
---
v2: Changed "From:" The email sent as being from Jens instead of me,
sorry again Jens.
block/blk-core.c | 4 +++- block/blk-merge.c | 10 ++++++++++ include/linux/blk_types.h | 2 ++ 3 files changed, 15 insertions(+), 1 deletion(-)
block/blk-core.c +3 -1
@@ -2392,7 +2392,9 @@ blk_qc_t generic_make_request(struct bio *bio)if (bio->bi_opf &REQ_NOWAIT ) flags =BLK_MQ_REQ_NOWAIT ; -if (blk_queue_enter (q, flags) <0 ) { +if (bio_flagged (bio,BIO_QUEUE_ENTERED )) +blk_queue_enter_live (q); +else if (blk_queue_enter (q, flags) <0 ) {if (!blk_queue_dying (q) && (bio->bi_opf &REQ_NOWAIT ))bio_wouldblock_error (bio);else
block/blk-merge.c +10 -0
@@ -210,6 +210,16 @@ void blk_queue_split(struct request_queue *q, struct bio **bio)/* there isn't chance to merge the splitted bio */ split->bi_opf |=REQ_NOMERGE ; +/* +* Since we're recursing into make_request here, ensure +* that we mark this bio as already having entered the queue. +* If not, and the queue is going away, we can get stuck +* forever on waiting for the queue reference to drop. But +* that will never happen, as we're already holding a +* reference to it. +*/ +bio_set_flag (*bio,BIO_QUEUE_ENTERED ); +bio_chain (split, *bio);trace_block_split (q, split, (*bio)->bi_iter.bi_sector);generic_make_request (*bio);
include/linux/blk_types.h +2 -0
@@ -186,6 +186,8 @@ struct bio {* throttling rules. Don't do it again. */ #define BIO_TRACE_COMPLETION 10/* bio_endio() should trace the final completion * of this bio. */ +#define BIO_QUEUE_ENTERED 11/* can use blk_queue_enter_live() */ +/* See BVEC_POOL_OFFSET below before adding new flags */ /*
Signature · 1 line
2.18.0
Greg KH
maintainerQuoted 1 line · Alexandru Moise
commit
cd4a4ae4683dc2e09380118e205e057896dcda2bupstream.
Who wrote this patch? Please keep the correct ownership of patches...
greg k-h
Quoted 5 lines · Greg KH
Quoted 1 line · Alexandru Moise
commit
cd4a4ae4683dc2e09380118e205e057896dcda2bupstream.Who wrote this patch? Please keep the correct ownership of patches...
This is Jenses work, I have absolutely nothing to do with it. I just want to make sure it reaches 4.17, I tried my best to follow these guidelines:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
I assumed that the first Signed-off is implicitly the author of the patch. Is there something I am missing? Am I misinterpeting the stable kernel rules?
../Alex
Quoted 1 line
greg k-h
Quoted 12 lines · Alexandru Moise
Quoted 4 lines · Greg KH
Quoted 1 line · Alexandru Moise
commit
cd4a4ae4683dc2e09380118e205e057896dcda2bupstream.Who wrote this patch? Please keep the correct ownership of
patches...
Quoted 1 line
This is Jenses work, I have absolutely nothing to do with it. I just want
to make sure it reaches 4.17, I tried my best to follow these guidelines:
Quoted 6 lines
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
I assumed that the first Signed-off is implicitly the author of the patch.
Is there something I am missing? Am I misinterpeting the stable kernel rules?
If you use git format-patch and git send-email for your patches, they'll come out looking like https://www.spinics.net/lists/stable/msg236090.html, which appears to be the proper format since Greg applied those patches without pointing out any flaws in the format.
Try
Signature · 1 line
Harsh Shandilya, PRJKT Development LLC
Greg KH
maintainerQuoted 20 lines · Harsh 'Shandilya
Quoted 12 lines · Alexandru Moise
Quoted 4 lines · Greg KH
Quoted 1 line · Alexandru Moise
commit
cd4a4ae4683dc2e09380118e205e057896dcda2bupstream.Who wrote this patch? Please keep the correct ownership of
patches...
Quoted 1 line
This is Jenses work, I have absolutely nothing to do with it. I just want
to make sure it reaches 4.17, I tried my best to follow these guidelines:Quoted 6 lines
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
I assumed that the first Signed-off is implicitly the author of the patch.
Is there something I am missing? Am I misinterpeting the stable kernel rules?
Quoted 5 lines
If you use git format-patch and git send-email for your patches, they'll come out looking like
https://www.spinics.net/lists/stable/msg236090.html, which appears to be the proper format since Greg applied those patches without pointing out any flaws in the format.
That is correct, you need the first line that says "From:" to show that the patch comes from someone other than you. Please fix that up and resend.
thanks,
greg k-h
Quoted 27 lines · Greg KH
Quoted 20 lines · Harsh 'Shandilya
Quoted 12 lines · Alexandru Moise
Quoted 4 lines · Greg KH
Quoted 1 line · Alexandru Moise
commit
cd4a4ae4683dc2e09380118e205e057896dcda2bupstream.Who wrote this patch? Please keep the correct ownership of
patches...
Quoted 1 line
This is Jenses work, I have absolutely nothing to do with it. I just want
to make sure it reaches 4.17, I tried my best to follow these guidelines:Quoted 6 lines
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
I assumed that the first Signed-off is implicitly the author of the patch.
Is there something I am missing? Am I misinterpeting the stable kernel rules?Quoted 5 lines
If you use git format-patch and git send-email for your patches, they'll come out looking like
https://www.spinics.net/lists/stable/msg236090.html, which appears to be the proper format since Greg applied those patches without pointing out any flaws in the format.
Quoted 3 lines
That is correct, you need the first line that says "From:" to show that the patch comes from someone other than you. Please fix that up and resend.
Understood, thank you for your patience. I was used to just sending patches, with mutt.
../Alex
Quoted 4 lines
thanks,
greg k-h
Greg KH
maintainerQuoted 28 lines · Alexandru Moise
Quoted 27 lines · Greg KH
Quoted 25 lines · Harsh 'Shandilya
Quoted 12 lines · Alexandru Moise
Quoted 4 lines · Greg KH
Quoted 1 line · Alexandru Moise
commit
cd4a4ae4683dc2e09380118e205e057896dcda2bupstream.Who wrote this patch? Please keep the correct ownership of
patches...
Quoted 1 line
This is Jenses work, I have absolutely nothing to do with it. I just want
to make sure it reaches 4.17, I tried my best to follow these guidelines:Quoted 6 lines
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
I assumed that the first Signed-off is implicitly the author of the patch.
Is there something I am missing? Am I misinterpeting the stable kernel rules?If you use git format-patch and git send-email for your patches, they'll come out looking like
https://www.spinics.net/lists/stable/msg236090.html, which appears to be the proper format since Greg applied those patches without pointing out any flaws in the format.
Quoted 5 lines
Quoted 3 lines
That is correct, you need the first line that says "From:" to show that the patch comes from someone other than you. Please fix that up and resend.
Understood, thank you for your patience. I was used to just sending patches, with mutt.
mutt works great too, just don't change the author "from:" line :)