From: Richard Weinberger <richard@nod.at>
To: Thorsten Knabe <linux@thorsten-knabe.de>
Cc: linux-kernel@vger.kernel.org, Thomas Meyer <thomas@m3y3r.de>,
Valdis.Kletnieks@vt.edu
Subject: Re: [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux
Date: Mon, 25 Aug 2014 15:25:21 +0200 [thread overview]
Message-ID: <53FB3941.3060504@nod.at> (raw)
In-Reply-To: <53FA6EF3.3080902@thorsten-knabe.de>
Am 25.08.2014 01:02, schrieb Thorsten Knabe:
> On 08/24/2014 02:11 PM, Richard Weinberger wrote:
>> Am 23.08.2014 19:43, schrieb Thorsten Knabe:
>>> Hi Richard.
>>>
>>> On 08/23/2014 05:34 PM, Richard Weinberger wrote:
>>>> Hi!
>>>>
>>>> Am 23.08.2014 15:47, schrieb Thorsten Knabe:
>>>>> From: Thorsten Knabe <linux@thorsten-knabe.de>
>>>>>
>>>>> UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
>>>>>
>>>>> Starting with Linux 3.12 processes get stuck in D state forever in
>>>>> UserModeLinux under sync heavy workloads. This bug was introduced by
>>>>> commit 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport).
>>>>> Fix bug by adding a check if FLUSH request was successfully submitted to
>>>>> the I/O thread and keeping the FLUSH request on the request queue on
>>>>> submission failures.
>>>>>
>>>>> Fixes: 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport)
>>>>> Signed-off-by: Thorsten Knabe <linux@thorsten-knabe.de>
>>>>
>>>> Thanks a lot for hunting this issue down.
>>>>
>>>>> ---
>>>>> Patch applies to 3.16.1.
>>>>>
>>>>> diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
>>>>> index 3716e69..b7d2840 100644
>>>>> --- a/arch/um/drivers/ubd_kern.c
>>>>> +++ b/arch/um/drivers/ubd_kern.c
>>>>> @@ -1277,7 +1277,7 @@ static void do_ubd_request(struct request_queue *q)
>>>>>
>>>>> while(1){
>>>>> struct ubd *dev = q->queuedata;
>>>>> - if(dev->end_sg == 0){
>>>>> + if(dev->request == NULL){
>>>>
>>>> Why do we need this specific change?
>>>
>>> This change is required, because for FLUSH requests dev->end_sg is
>>> initialized to 0 by blk_rq_map_sg() a few lines above, as FLUSH requests
>>> have no data blocks attached to themselves.
>>
>> You meant "below"? Looks like I really miss something here.
>> At the bottom of the while(1) loop we have
>> dev->end_sg = 0;
>> dev->request = NULL;
>
> No. The problematic line is:
> dev->end_sg = blk_rq_map_sg(q, req, dev->sg);
> and blk_rq_map_sg() returning 0 for REQ_FLUSH requests, because they
> have no associated data blocks.
>
> Hence on the next iteration of the while(1) loop:
> if(dev->end_sg == 0){
At the bottom of the while loop dev->end_sg will be set to 0 anyway, this is what puzzles
me so hard.
(And dev->request too)
Thanks,
//richard
next prev parent reply other threads:[~2014-08-25 13:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-23 13:47 [PATCH] UML: UBD: Fix for processes stuck in D state forever in UserModeLinux Thorsten Knabe
2014-08-23 15:34 ` Richard Weinberger
2014-08-23 17:43 ` Thorsten Knabe
2014-08-24 12:11 ` Richard Weinberger
2014-08-24 23:02 ` Thorsten Knabe
2014-08-25 13:25 ` Richard Weinberger [this message]
2014-08-25 14:00 ` Thorsten Knabe
2014-08-25 14:04 ` Richard Weinberger
2014-09-16 16:50 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53FB3941.3060504@nod.at \
--to=richard@nod.at \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@thorsten-knabe.de \
--cc=thomas@m3y3r.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.