From: sthumma@codeaurora.org
To: Aaron Lu <aaron.lu@intel.com>
Cc: sthumma@codeaurora.org, stern@rowland.harvard.edu,
linux-scsi@vger.kernel.org
Subject: Re: Race condition in block layer runtime PM init and scsi disk driver
Date: Thu, 10 Oct 2013 04:55:07 -0000 [thread overview]
Message-ID: <04811251e7b06dd74849872257d9bb7c.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <52551CD3.2060803@intel.com>
> On 10/09/2013 04:32 PM, sthumma@codeaurora.org wrote:
>>> Hi Aaron,
>>>
>>> I found a race condition with the block layer runtime PM due to which
>>> the q->nr_pending is decremented to less than zero (0xFFFF_FFFF (-1))
>>> and hence the blk pre-runtime suspend always returns -EBUSY.
>>>
>>>
>>> The issue is easily reproduced with a scsi disk with disabled tagged
>>> command queuing
>>>
>>> sd_probe_async() ->
>>> add_disk() ->
>>> disk_add_event() ->
>>> schedule(disk_events_workfn)
>>> sd_revalidate_disk()
>>> blk_pm_runtime_init()
>>> return;
>>>
>>> Let's say the disk_events_workfn() calls sd_check_events() which tries
>>> to send test_unit_ready() and because of sd_revalidate_disk() trying to
>>> send another commands the test_unit_ready() might be re-queued as the
>>> tagged command queuing is disabled.
>>>
>>> So the race condition is -
>>>
>>> Thread 1 | Thread 2
>>> sd_revalidate_disk() | sd_check_events()
>>> ...nr_pending = 0 as q->dev = NULL| scsi_queue_insert()
>>> blk_runtime_pm_init() | blk_pm_requeue_request() ->
>>> | nr_pending = -1 since
>>> | q->dev != NULL
>>>
>>> Do you have any suggestions on how to fix this issue?
>
> Thanks for the report. I wonder if the following patch helps?
Thanks it works. Would you like to send formal patch for this?
You can add my tested-by ack.
Tested-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
>
> Do the runtime init related work before add_disk, so that every request
> is counted properly.
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index e62d17d..5693f6d 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2854,6 +2854,7 @@ static void sd_probe_async(void *data,
> async_cookie_t cookie)
> gd->events |= DISK_EVENT_MEDIA_CHANGE;
> }
>
> + blk_pm_runtime_init(sdp->request_queue, dev);
> add_disk(gd);
> if (sdkp->capacity)
> sd_dif_config_host(sdkp);
> @@ -2862,7 +2863,6 @@ static void sd_probe_async(void *data,
> async_cookie_t cookie)
>
> sd_printk(KERN_NOTICE, sdkp, "Attached SCSI %sdisk\n",
> sdp->removable ? "removable " : "");
> - blk_pm_runtime_init(sdp->request_queue, dev);
> scsi_autopm_put_device(sdp);
> put_device(&sdkp->dev);
> }
>
> Thanks,
> Aaron
>
>>>
>>>
>>> --
>>> Regards,
>>> Sujit
>>>
>>
>>
>
>
next prev parent reply other threads:[~2013-10-10 4:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 8:32 (unknown), sthumma
2013-10-09 8:32 ` Race condition in block layer runtime PM init and scsi disk driver sthumma
2013-10-09 9:07 ` Aaron Lu
2013-10-10 4:55 ` sthumma [this message]
2013-10-10 5:22 ` [PATCH] [SCSI] sd: call blk_pm_runtime_init before add_disk Aaron Lu
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=04811251e7b06dd74849872257d9bb7c.squirrel@www.codeaurora.org \
--to=sthumma@codeaurora.org \
--cc=aaron.lu@intel.com \
--cc=linux-scsi@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).