[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BY2PR0301MB1654D797E802F3CF5355942FA0F60@BY2PR0301MB1654.namprd03.prod.outlook.com>
Date: Fri, 8 Jan 2016 18:58:20 +0000
From: KY Srinivasan <kys@...rosoft.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"ohering@...e.com" <ohering@...e.com>,
"jbottomley@...allels.com" <jbottomley@...allels.com>,
"hch@...radead.org" <hch@...radead.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"apw@...onical.com" <apw@...onical.com>,
"vkuznets@...hat.com" <vkuznets@...hat.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"hare@...e.de" <hare@...e.de>
CC: "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error
handling function
> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@...senPartnership.com]
> Sent: Thursday, January 7, 2016 3:49 PM
> To: KY Srinivasan <kys@...rosoft.com>; gregkh@...uxfoundation.org; linux-
> kernel@...r.kernel.org; devel@...uxdriverproject.org; ohering@...e.com;
> jbottomley@...allels.com; hch@...radead.org; linux-scsi@...r.kernel.org;
> apw@...onical.com; vkuznets@...hat.com; jasowang@...hat.com;
> martin.petersen@...cle.com; hare@...e.de
> Cc: stable@...r.kernel.org
> Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error
> handling function
>
> On Thu, 2016-01-07 at 16:40 -0800, K. Y. Srinivasan wrote:
> > The macro startget_to_rport() can return NULL; handle that case
> > properly.
>
> OK, can we unwind why you think you could possibly need this? It would
> mean that fc_timed_out was called for a non-FC device, which was
> thought to be an impossibility when the fc transport class was
> designed.
As you know, on Hyper-V, FC devices are handled exactly like normal scsi
devices and the only additional information that is provided for FC devices
is the WWN for port and node. Till recently, I was not publishing the WWN in
the guest and so I was not even using the FC transport. Recently, I implemented
support for publishing the WWN in the guest and for that I am using the FC transport
for FC hosts. When an FC LUN is dynamically removed, sometimes I see the timeout
occurring and since there is no rport associated with these devices I am hitting the issue
this patch is addressing. I could have addressed this problem by establishing a storvsc specific
time out function even for FC devices - the same timeout function that I currently use for scsi
devices - storvsc_eh_timed_out(). I chose to instead fix the fc_timed_out() function since
the code was not handling a possible condition.
Regards,
K. Y
>
> James
>
> > Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>
> > Cc: <stable@...r.kernel.org>
> > ---
> > drivers/scsi/scsi_transport_fc.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/scsi/scsi_transport_fc.c
> > b/drivers/scsi/scsi_transport_fc.c
> > index 24eaaf6..42a908f 100644
> > --- a/drivers/scsi/scsi_transport_fc.c
> > +++ b/drivers/scsi/scsi_transport_fc.c
> > @@ -2081,7 +2081,7 @@ fc_timed_out(struct scsi_cmnd *scmd)
> > {
> > struct fc_rport *rport = starget_to_rport(scsi_target(scmd
> > ->device));
> >
> > - if (rport->port_state == FC_PORTSTATE_BLOCKED)
> > + if ((rport == NULL) || (rport->port_state ==
> > FC_PORTSTATE_BLOCKED))
> > return BLK_EH_RESET_TIMER;
> >
> > return BLK_EH_NOT_HANDLED;
Powered by blists - more mailing lists