From: James Bottomley <jbottomley@parallels.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>,
Bart Van Assche <bvanassche@acm.org>,
Elric Fu <elricfu1@gmail.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Felipe Balbi <balbi@ti.com>, Alex He <alex.he@amd.com>,
Andiry Xu <andiry.xu@amd.com>,
Greg KH <gregkh@linuxfoundation.org>,
Linux USB Mailing List <linux-usb@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>
Subject: Re: An oops will occur while SCSI core is being used in 3.4-rc1
Date: Wed, 18 Apr 2012 07:53:17 +0000 [thread overview]
Message-ID: <1334735594.4410.15.camel@dabdike> (raw)
In-Reply-To: <yq18vi2ckrj.fsf@sermon.lab.mkp.net>
On Wed, 2012-04-11 at 12:10 -0400, Martin K. Petersen wrote:
> >>>>> "Mike" == Mike Christie <michaelc@cs.wisc.edu> writes:
>
> >>>> I have observed crashes at the same point while testing device
> >>>> removal with the ib_srp driver. As far as I can see that code was
> >>>> added through commit 18a4d0a22ed6c54b67af7718c305cd010f09ddf8
> >>>> (February 9, 2012). The approach of that patch looks questionable
> >>>> to me: what guarantees that the struct scsi_driver will be
> >>>> available at the time the SCSI error handler needs it ?
>
> Sorry about that!
>
>
> Mike> That is wrong. I guess REQ_DISCARD and REQ_FLUSH will, so I guess
> Mike> we just have to check for a NULL sdrv above.
>
> How about we do this?
>
>
> SCSI: Fix error handling when no ULD is attached
>
> Commit 18a4d0a2 introduced a bug in which we would attempt to
> dereference the scsi driver even when the device had no ULD attached.
>
> Ensure that a driver is registered and make the driver accessor function
> more resilient to errors during device discovery.
>
> Reported-by: Elric Fu <elricfu1@gmail.com>
> Reported-by: Bart Van Assche <bvanassche@acm.org>
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 2cfcbff..386f0c5 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -835,7 +835,7 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd,
>
> scsi_eh_restore_cmnd(scmd, &ses);
>
> - if (sdrv->eh_action)
> + if (sdrv && sdrv->eh_action)
> rtn = sdrv->eh_action(scmd, cmnd, cmnd_size, rtn);
>
> return rtn;
> diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
> index 377df4a..1e11985 100644
> --- a/include/scsi/scsi_cmnd.h
> +++ b/include/scsi/scsi_cmnd.h
> @@ -134,6 +134,9 @@ struct scsi_cmnd {
>
> static inline struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
> {
> + if (!cmd->request->rq_disk)
> + return NULL;
> +
> return *(struct scsi_driver **)cmd->request->rq_disk->private_data;
> }
I'm not entirely convinced by this. If medium access timeout processing
is so important, shouldn't it be done all the time rather than only when
the ULD is bound? In which case it should be part of the error handler
core?
James
next prev parent reply other threads:[~2012-04-18 7:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 1:22 An oops will occur while SCSI core is being used in 3.4-rc1 Elric Fu
2012-04-10 8:16 ` Bart Van Assche
2012-04-10 16:37 ` Mike Christie
[not found] ` <4F8461E3.3050808-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>
2012-04-10 16:45 ` Mike Christie
2012-04-10 16:51 ` Mike Christie
2012-04-11 16:10 ` Martin K. Petersen
2012-04-11 16:40 ` Bart Van Assche
[not found] ` <4F85B3E8.7040704-HInyCGIudOg@public.gmane.org>
2012-04-11 20:01 ` Bart Van Assche
[not found] ` <4F85E312.6070205-HInyCGIudOg@public.gmane.org>
2012-04-12 0:48 ` Martin K. Petersen
2012-04-18 7:53 ` James Bottomley [this message]
2012-04-13 0:30 ` Rustad, Mark D
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=1334735594.4410.15.camel@dabdike \
--to=jbottomley@parallels.com \
--cc=alex.he@amd.com \
--cc=andiry.xu@amd.com \
--cc=balbi@ti.com \
--cc=bvanassche@acm.org \
--cc=elricfu1@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michaelc@cs.wisc.edu \
--cc=sarah.a.sharp@linux.intel.com \
--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