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.
Reported-by: syzbot+c4f9cebf9d651f6e54de@syzkaller.appspotmail.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Alexandru Moise 00moses.alexander00@gmail.com --- 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(-)
diff --git a/block/blk-core.c b/block/blk-core.c index b559b9d4f1a2..47ab2d9d02d9 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -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 diff --git a/block/blk-merge.c b/block/blk-merge.c index 782940c65d8a..481dc02668f9 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -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); diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h index 17b18b91ebac..1602bf4ab4cd 100644 --- a/include/linux/blk_types.h +++ b/include/linux/blk_types.h @@ -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 */
/*
On Wed, Jul 04, 2018 at 11:16:44AM +0200, Greg KH wrote:
On Tue, Jul 03, 2018 at 11:44:53PM +0200, Alexandru Moise wrote:
commit cd4a4ae4683dc2e09380118e205e057896dcda2b upstream.
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
greg k-h
On 4 July 2018 3:25:06 PM IST, Alexandru Moise 00moses.alexander00@gmail.com wrote:
On Wed, Jul 04, 2018 at 11:16:44AM +0200, Greg KH wrote:
On Tue, Jul 03, 2018 at 11:44:53PM +0200, Alexandru Moise wrote:
commit cd4a4ae4683dc2e09380118e205e057896dcda2b upstream.
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?
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
On Wed, Jul 04, 2018 at 04:29:09PM +0530, Harsh 'Shandilya wrote:
On 4 July 2018 3:25:06 PM IST, Alexandru Moise 00moses.alexander00@gmail.com wrote:
On Wed, Jul 04, 2018 at 11:16:44AM +0200, Greg KH wrote:
On Tue, Jul 03, 2018 at 11:44:53PM +0200, Alexandru Moise wrote:
commit cd4a4ae4683dc2e09380118e205e057896dcda2b upstream.
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?
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
On Wed, Jul 04, 2018 at 01:31:54PM +0200, Greg KH wrote:
On Wed, Jul 04, 2018 at 04:29:09PM +0530, Harsh 'Shandilya wrote:
On 4 July 2018 3:25:06 PM IST, Alexandru Moise 00moses.alexander00@gmail.com wrote:
On Wed, Jul 04, 2018 at 11:16:44AM +0200, Greg KH wrote:
On Tue, Jul 03, 2018 at 11:44:53PM +0200, Alexandru Moise wrote:
commit cd4a4ae4683dc2e09380118e205e057896dcda2b upstream.
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?
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.
Understood, thank you for your patience. I was used to just sending patches, with mutt.
../Alex
thanks,
greg k-h
On Wed, Jul 04, 2018 at 01:44:48PM +0200, Alexandru Moise wrote:
On Wed, Jul 04, 2018 at 01:31:54PM +0200, Greg KH wrote:
On Wed, Jul 04, 2018 at 04:29:09PM +0530, Harsh 'Shandilya wrote:
On 4 July 2018 3:25:06 PM IST, Alexandru Moise 00moses.alexander00@gmail.com wrote:
On Wed, Jul 04, 2018 at 11:16:44AM +0200, Greg KH wrote:
On Tue, Jul 03, 2018 at 11:44:53PM +0200, Alexandru Moise wrote:
commit cd4a4ae4683dc2e09380118e205e057896dcda2b upstream.
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?
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.
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 :)
linux-stable-mirror@lists.linaro.org
-
Alexandru Moise -
Greg KH -
Harsh 'Shandilya