From: Hannes Reinecke <hare@suse.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ankit Jain <mail@ankitjain.org>, Jack Wang <jack_wang@usish.com>,
Dan Williams <dan.j.williams@intel.com>,
Alan Stern <stern@rowland.harvard.edu>,
Andi Kleen <andi@firstfloor.org>,
axboe@kernel.dk, Dave Jones <davej@redhat.com>,
SCSI development list <linux-scsi@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: Linux 3.0 oopses when pulling a USB CDROM
Date: Fri, 21 Oct 2011 15:26:47 +0200 [thread overview]
Message-ID: <4EA17317.1020506@suse.de> (raw)
In-Reply-To: <1318973425.5169.39.camel@dabdike.int.hansenpartnership.com>
On 10/18/2011 11:30 PM, James Bottomley wrote:
> On Wed, 2011-10-19 at 02:46 +0530, Ankit Jain wrote:
>> On Wed, Jul 20, 2011 at 3:28 PM, Jack Wang<jack_wang@usish.com> wrote:
>>>>
>> <snip>
>>>> On Sat, Jul 2, 2011 at 12:59 PM, Alan Stern<stern@rowland.harvard.edu>
>>> wrote:
>>>>> On Sat, 2 Jul 2011, Andi Kleen wrote:
>>>>>
>>>>>>> The problem is that blk_peek_request() calls scsi_prep_fn(), which
>>>>>>> does this:
>>>>>>>
>>>>>>> struct scsi_device *sdev = q->queuedata;
>>>>>>> int ret = BLKPREP_KILL;
>>>>>>>
>>>>>>> if (req->cmd_type == REQ_TYPE_BLOCK_PC)
>>>>>>> ret = scsi_setup_blk_pc_cmnd(sdev, req);
>>>>>>> return scsi_prep_return(q, req, ret);
>>>>>>>
>>>>>>> It doesn't check to see if sdev is NULL, nor does
>>>>>>> scsi_setup_blk_pc_cmnd(). That accounts for this error:
>>>>>>
>>>>>> I actually added a NULL check in scsi_setup_blk_pc_cmnd early on,
>>>>>> but that just caused RCU CPU stalls afterwards and then eventually
>>>>>> a hung system.
>>>>>
>>>>> The RCU problem is likely to be a separate issue. It might even be a
>>>>> result of the use-after-free problem with the elevator.
>>>>>
>>>>> At any rate, it's clear that the crash in the refcounting log you
>>>>> posted occurred because scsi_setup_blk_pc_cmnd() called
>>>>> scsi_prep_state_check(), which tried to dereference the NULL pointer.
>>>>>
>>>>> Would you like to try this patch to see if it fixes the problem? As I
>>>>> said before, I'm not certain it's the best thing to do, but it worked
>>>>> on my system.
>>>>>
>>>>> Alan Stern
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Index: usb-3.0/drivers/scsi/scsi_lib.c
>>>>> ===================================================================
>>>>> --- usb-3.0.orig/drivers/scsi/scsi_lib.c
>>>>> +++ usb-3.0/drivers/scsi/scsi_lib.c
>>>>> @@ -1247,6 +1247,8 @@ int scsi_prep_fn(struct request_queue *q
>>>>> struct scsi_device *sdev = q->queuedata;
>>>>> int ret = BLKPREP_KILL;
>>>>>
>>>>> + if (!sdev)
>>>>> + return ret;
>>>>> if (req->cmd_type == REQ_TYPE_BLOCK_PC)
>>>>> ret = scsi_setup_blk_pc_cmnd(sdev, req);
>>>>> return scsi_prep_return(q, req, ret);
>>>>> Index: usb-3.0/drivers/scsi/scsi_sysfs.c
>>>>> ===================================================================
>>>>> --- usb-3.0.orig/drivers/scsi/scsi_sysfs.c
>>>>> +++ usb-3.0/drivers/scsi/scsi_sysfs.c
>>>>> @@ -322,6 +322,8 @@ static void scsi_device_dev_release_user
>>>>> kfree(evt);
>>>>> }
>>>>>
>>>>> + /* Freeing the queue signals to block that we're done */
>>>>> + scsi_free_queue(sdev->request_queue);
>>>>> blk_put_queue(sdev->request_queue);
>>>>> /* NULL queue means the device can't be used */
>>>>> sdev->request_queue = NULL;
>>>>> @@ -936,8 +938,6 @@ void __scsi_remove_device(struct scsi_de
>>>>> /* 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);
>>>>> }
>>>>
>>>> This patch seems to resolve the block/scsi null-ptr de-references in
>>>> our libsas/isci environment, we have yet to try James' alternative
>>>> [1]. Do we potentially need both?
>>>>
>>>> Commit 86cbfb56 moved scsi_free_queue to __scsi_remove_device() but it
>>>> seems only the "sdev->request_queue->queuedata = NULL" needed to be
>>>> moved?
>>>>
>>>> The conversation appeared to be awaiting test results...
>>>>
>>>> [1]: http://marc.info/?l=linux-scsi&m=131007155700831&w=2
>>>>
>>>> --
>>>> Dan
>>> [Jack Wang]
>>> This patch fix kernel panic issue when hot-plut disk during I/O, I test it
>>> using pm8001 with 3.0.0-rc6 with above patch.
>>
>> I don't see this patch in scsi-misc-2.6 or linus' tree. Is there a
>> different patch that fixes the
>> issue?
>
> It should be fixed by
>
> commit 777eb1bf15b8532c396821774bf6451e563438f5
> Author: Hannes Reinecke<hare@suse.de>
> Date: Wed Sep 28 08:07:01 2011 -0600
>
> block: Free queue resources at blk_release_queue()
>
As much as I've hate to admit it, but it looks as if this is only a
fix for the second part of the original patch.
I've got reports that we still see crashes, which are fixed by the
patch to scsi_lib.c.
So please include this part.
Do you need a resend?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
next prev parent reply other threads:[~2011-10-21 13:26 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 17:05 Linux 3.0 oopses when pulling a USB CDROM Andi Kleen
2011-07-01 18:14 ` Dave Jones
2011-07-01 18:32 ` Andi Kleen
2011-07-01 18:40 ` Dave Jones
2011-07-02 15:13 ` Christoph Fritz
2011-07-01 20:29 ` James Bottomley
2011-07-01 20:43 ` [PATCH] USB: fix regression occurring during device removal Alan Stern
2011-07-01 21:04 ` Andi Kleen
2011-07-01 21:04 ` Linux 3.0 oopses when pulling a USB CDROM Alan Stern
2011-07-01 21:13 ` James Bottomley
2011-07-02 2:03 ` Alan Stern
2011-07-02 6:08 ` Andi Kleen
2011-07-02 12:24 ` James Bottomley
2011-07-02 17:05 ` Andi Kleen
2011-07-02 17:09 ` James Bottomley
2011-07-02 18:15 ` Andi Kleen
2011-07-02 20:05 ` Alan Stern
2011-07-03 1:16 ` Andi Kleen
2011-07-03 15:29 ` Alan Stern
2011-07-03 16:06 ` Alan Stern
2011-07-02 17:37 ` Alan Stern
2011-07-02 18:11 ` Andi Kleen
2011-07-02 19:59 ` Alan Stern
2011-07-03 1:17 ` Andi Kleen
2011-07-07 20:47 ` solved was " Andi Kleen
2011-07-18 16:59 ` Dan Williams
2011-07-18 18:00 ` Andi Kleen
2011-07-20 9:58 ` Jack Wang
2011-10-18 21:16 ` Ankit Jain
2011-10-18 21:30 ` James Bottomley
2011-10-21 13:26 ` Hannes Reinecke [this message]
2011-07-03 9:14 ` Dan Williams
2011-07-03 18:16 ` Andi Kleen
2011-07-03 20:37 ` Stefan Richter
2011-07-08 13:37 ` Stefan Richter
2011-07-08 13:41 ` Stefan Richter
2011-07-04 11:27 ` Heiko Carstens
2011-07-04 16:04 ` Alan Stern
2011-07-06 6:50 ` Heiko Carstens
2011-07-12 18:49 ` Jonathan McDowell
2011-07-02 12:38 ` Alan Stern
2011-07-02 18:10 ` Andi Kleen
2011-07-02 12:48 ` Rafael J. Wysocki
2011-07-02 17:06 ` Andi Kleen
2011-07-01 19:20 ` James Bottomley
2011-07-01 19:33 ` James Bottomley
2011-07-01 19:45 ` James Bottomley
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=4EA17317.1020506@suse.de \
--to=hare@suse.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=andi@firstfloor.org \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@intel.com \
--cc=davej@redhat.com \
--cc=jack_wang@usish.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mail@ankitjain.org \
--cc=rjw@sisk.pl \
--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).