From: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>
To: Bart Van Assche <bvanassche@acm.org>,
Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: jbottomley@parallels.com, linux-scsi@vger.kernel.org,
Huajun Li <huajun.li.lee@gmail.com>,
Axel Theilmann <theilmann@pre-sense.de>,
linux-kernel@vger.kernel.org
Subject: Re: Yet another hot unplug NULL pointer dereference (was Re: status of oops in sd_revalidate_disk?)
Date: Wed, 15 Feb 2012 11:26:15 +0900 [thread overview]
Message-ID: <4F3B17C7.9040107@ce.jp.nec.com> (raw)
In-Reply-To: <2173642.Y3HxI15Hxl@asus>
Hi,
Thank you for comments.
On 02/15/12 04:11, Bart Van Assche wrote:
> On Feb 14 Stefan Richter wrote:
>> Or asked differently, what is supposed to serialize the ->queuedata
>> accesses?
AFAIU the racy check is ok because
sdev does not disappear as far as the device is opened.
The oopses in scsi_prep_fn happened just because they used queuedata
without checking.
>
> How about avoiding to modify q->queuedata before scsi_free_queue() has been
> invoked, e.g. as follows ?
I think this patch is good, too.
Since QUEUE_FLAG_DEAD is also racy, it is not much different
from queuedata check, IMO.
Maybe you want additional blk_queue_dead() check in prep_fn
to keep the current behaviour.
> Note: the kfree() call in scsi_host_dev_release() probably
> should be postponed until the last put on the queue has occurred.
>
>>From 4d29b62c686a718d34d3b3f634306376b40dbdb6 Mon Sep 17 00:00:00 2001
> From: Bart Van Assche <bvanassche@acm.org>
> Date: Tue, 14 Feb 2012 13:52:21 +0100
> Subject: [PATCH] scsi-queuedata-null-deref-fix
>
> ---
> drivers/scsi/hosts.c | 4 ++--
> drivers/scsi/scsi_lib.c | 13 +++----------
> drivers/scsi/scsi_sysfs.c | 3 ---
> 3 files changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 351dc0b..5f34620 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -296,9 +296,9 @@ static void scsi_host_dev_release(struct device *dev)
> destroy_workqueue(shost->work_q);
> q = shost->uspace_req_q;
> if (q) {
> - kfree(q->queuedata);
> - q->queuedata = NULL;
> + void *qd = q->queuedata;
> scsi_free_queue(q);
> + kfree(qd);
> }
>
> scsi_destroy_command_freelist(shost);
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index f85cfa6..7c40303 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1491,7 +1491,9 @@ static void scsi_request_fn(struct request_queue *q)
> struct scsi_cmnd *cmd;
> struct request *req;
>
> - if (!sdev) {
> + BUG_ON(!sdev);
> +
> + if (test_bit(QUEUE_FLAG_DEAD, &q->queue_flags)) {
> while ((req = blk_peek_request(q)) != NULL)
> scsi_kill_request(req, q);
> return;
> @@ -1700,15 +1702,6 @@ struct request_queue *scsi_alloc_queue(struct scsi_device *sdev)
>
> void scsi_free_queue(struct request_queue *q)
> {
> - unsigned long flags;
> -
> - WARN_ON(q->queuedata);
> -
> - /* cause scsi_request_fn() to kill all non-finished requests */
> - spin_lock_irqsave(q->queue_lock, flags);
> - q->request_fn(q);
> - spin_unlock_irqrestore(q->queue_lock, flags);
> -
> blk_cleanup_queue(q);
> }
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index ea5658d..61dd107 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -976,9 +976,6 @@ void __scsi_remove_device(struct scsi_device *sdev)
> sdev->host->hostt->slave_destroy(sdev);
> transport_destroy_device(dev);
>
> - /* cause the request function to reject all I/O requests */
> - sdev->request_queue->queuedata = NULL;
> -
> /* Freeing the queue signals to block that we're done */
> scsi_free_queue(sdev->request_queue);
> put_device(dev);
--
Jun'ichi Nomura, NEC Corporation
next prev parent reply other threads:[~2012-02-15 2:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-14 17:59 status of oops in sd_revalidate_disk? Axel Theilmann
2011-12-21 14:12 ` Huajun Li
2011-12-25 20:58 ` Yet another hot unplug NULL pointer dereference (was Re: status of oops in sd_revalidate_disk?) Stefan Richter
2011-12-27 10:21 ` Axel Theilmann
2011-12-27 10:21 ` Axel Theilmann
2011-12-27 13:40 ` Stefan Richter
2012-02-14 11:34 ` Jun'ichi Nomura
2012-02-14 11:54 ` Bart Van Assche
2012-02-14 13:38 ` Stefan Richter
2012-02-14 19:11 ` Bart Van Assche
2012-02-15 2:26 ` Jun'ichi Nomura [this message]
2012-02-15 11:29 ` Bart Van Assche
2012-02-16 1:04 ` Jun'ichi Nomura
2012-03-13 18:10 ` Bart Van Assche
2012-03-16 8:58 ` Jun'ichi Nomura
2012-03-16 18:53 ` Bart Van Assche
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=4F3B17C7.9040107@ce.jp.nec.com \
--to=j-nomura@ce.jp.nec.com \
--cc=bvanassche@acm.org \
--cc=huajun.li.lee@gmail.com \
--cc=jbottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
--cc=theilmann@pre-sense.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.