Re: [PATCH v2] lpfc: Finalize Kconfig options for nvme

2017-03-13 Thread Martin K. Petersen 
> "James" == jsmart2021   writes:

James> Reviewing the result of what was just added for Kconfig, we made
James> a poor choice. It worked well for full kernel builds, but not so
James> much for how it would be deployed on a distro.

Applied to 4.11/scsi-fixes.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [scsi] scsi: ufs: don't check unsigned type for a negative value

2017-03-13 Thread Martin K. Petersen 
> "Tomas" == Tomas Winkler  writes:

Tomas> Fix compilation warning drivers/scsi/ufs/ufshcd.c:7645:13:
Tomas> warning: comparison of unsigned expression < 0 is always false
Tomas> [-Wtype-limits] if ((value < UFS_PM_LVL_0) || (value >=
Tomas> UFS_PM_LVL_MAX))

Applied to 4.11/scsi-fixes, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH V3 0/3] hpsa updates

2017-03-13 Thread Martin K. Petersen 
> "Don" == Don Brace  writes:

Don> These patches are based on Linus's tree The changes are:
Don>  - add in a new offline volume status
Don>  - limit the number of outstanding rescan operation
Don>  - do not timeout reset operations

Applied to 4.11/scsi-fixes.

Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 0/4] megaraid_sas: Bug fixes and improvements for 4.11-rc

2017-03-13 Thread Martin K. Petersen 
> "Shivasharan" == Shivasharan S  
> writes:

Shivasharan> This patchset fixes few issues introduced during previous
Shivasharan> set of patch submissions for 4.11

Applied to 4.11/scsi-fixes.

Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] qla2xxx: Fix crash in qla2xxx_eh_abort on bad ptr

2017-03-13 Thread Martin K. Petersen 
> "Bill" == Bill Kuzeja  writes:

Hi Bill,

Bill> I've seen this issue only after a Qlogic card breaks upon
Bill> initialization (one of my test cases). After the break,
Bill> qla2x00_abort_all_cmds gets invoked. This routine has a relatively
Bill> new section introduced by these commits:

[...]

Please resubmit a v2 of this fix with a concise (~ one paragraph) patch
description. The extensive debugging write-up is fine but it should be
placed after a --- separator so it doesn't end up in the git log.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: storvsc: Add support for FC rport.

2017-03-13 Thread Martin K. Petersen 
> "Cathy" == Cathy Avery  writes:

Hi Cathy,

Cathy> I haven't received any feedback yet.

Cathy> Should I resend?

You sent this right at the beginning of the merge window. That almost
guarantees that nobody will have time to look at it.

Whereas now is a good time to send submissions for 4.12...

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2] scsi_sysfs: fix hang when removing scsi device

2017-03-13 Thread Bart Van Assche 
On Mon, 2017-03-13 at 14:55 -0700, James Bottomley wrote:
> This is true, but I don't see how it can cause the host to be freed
> before the sdev.  The memory for struct Scsi_Host is freed in the
> shost_gendev release routine, which should be pinned by the parent
> traversal from sdev.  So it should not be possible for
>  scsi_host_dev_release() to be called before
>  scsi_device_dev_release_usercontext() becase the latter has the final
> put of the parent device.

Hello James,

I will run a bisect to see whether that provides more information about
what caused the change in the reference counting behavior.

Israel, since you did not hit the reference counting issue in your tests,
can you repeat your test with patches 3, 4 and 5 applied?

Thanks,

Bart.

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

2017-03-13 Thread Laurence Oberman 


- Original Message -
> From: "Laurence Oberman" 
> To: "Himanshu Madhani" 
> Cc: "Chad Dupuis" , "Linux SCSI List" 
> 
> Sent: Monday, March 13, 2017 9:06:38 PM
> Subject: Re: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based 8Gb) 
> with BAR 3 error, work fine on 4.9
> 
> 
> 
> - Original Message -
> > From: "Laurence Oberman" 
> > To: "Himanshu Madhani" 
> > Cc: "Chad Dupuis" , "Linux SCSI List"
> > 
> > Sent: Monday, March 13, 2017 12:54:12 PM
> > Subject: Re: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based
> > 8Gb) with BAR 3 error, work fine on 4.9
> > 
> > 
> > 
> > - Original Message -
> > > From: "Himanshu Madhani" 
> > > To: "Laurence Oberman" , "Chad Dupuis"
> > > 
> > > Cc: "Linux SCSI List" 
> > > Sent: Monday, March 13, 2017 12:39:03 PM
> > > Subject: RE: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based
> > > 8Gb) with BAR 3 error, work fine on 4.9
> > > 
> > > Hi Laurence,
> > > 
> > > > -Original Message-
> > > > From: Laurence Oberman [mailto:lober...@redhat.com]
> > > > Sent: Sunday, March 12, 2017 11:31 AM
> > > > To: Dupuis, Chad ; Madhani, Himanshu
> > > > 
> > > > Cc: Linux SCSI List 
> > > > Subject: Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based
> > > > 8Gb)
> > > > with BAR 3 error, work fine on 4.9
> > > > 
> > > > 
> > > > 
> > > > - Original Message -
> > > > > From: "Laurence Oberman" 
> > > > > To: "Chad Dupuis" , "Himanshu Madhani"
> > > > > 
> > > > > Cc: "Linux SCSI List" 
> > > > > Sent: Sunday, March 12, 2017 7:39:23 AM
> > > > > Subject: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based
> > > > > 8Gb) with BAR 3 error, work fine on 4.9
> > > > >
> > > > > Chad, Himanshu
> > > > >
> > > > > Before I bisect or go chase changes, wanted to reach out because the
> > > > > driver seems to be the same version.
> > > > > Perhaps this is a PCIE change in the kernel for 4.10 affecting the
> > > > > load.
> > > > > Its the same targetLIO server I have been using for a long time with
> > > > > 4.9
> > > > >
> > > > > 27:00.0 Fibre Channel: QLogic Corp. ISP2532-based 8Gb Fibre Channel
> > > > > to
> > > > > PCI Express HBA (rev 02)
> > > > >
> > > > > With 4.9 I have no issues loading the driver for my targetLIO server.
> > > > > (DL380G8)
> > > > >
> > > > > # modinfo qla2xxx | more
> > > > > filename:
> > > > > /lib/modules/4.9.0.lobetcm+/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
> > > > > firmware:   ql2500_fw.bin
> > > > > version:8.07.00.38-k
> > > > > license:GPL
> > > > > description:QLogic Fibre Channel HBA Driver
> > > > > author: QLogic Corporation
> > > > > srcversion: 94A8431A85BFF854B97B02D
> > > > >
> > > > > [8.906351] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel
> > > > > HBA
> > > > > Driver: 8.07.00.38-k.
> > > > > [   10.014052] qla2xxx [:27:00.0]-001d: : Found an ISP2532 irq
> > > > > 106
> > > > > iobase
> > > > > 0xadce989a1000.
> > > > > [   10.455108] scsi host4: qla2xxx
> > > > > [   10.460206] qla2xxx [:27:00.0]-00fb:4: QLogic QLE2562 -
> > > > > PCI-Express
> > > > > Dual Channel 8Gb Fibre Channel HBA.
> > > > > [   10.460215] qla2xxx [:27:00.0]-00fc:4: ISP2532: PCIe (5.0GT/s
> > > > > x8)
> > > > > @
> > > > > :27:00.0 hdma+ host#=4 fw=8.03.00 (90d5).
> > > > > [   10.460545] qla2xxx [:27:00.1]-001d: : Found an ISP2532 irq
> > > > > 110
> > > > > iobase
> > > > > 0xadce989a9000.
> > > > > [   10.662120] scsi host5: qla2xxx
> > > > > [   11.007841] qla2xxx [:27:00.1]-00fb:5: QLogic QLE2562 -
> > > > > PCI-Express
> > > > > Dual Channel 8Gb Fibre Channel HBA.
> > > > > [   11.007849] qla2xxx [:27:00.1]-00fc:5: ISP2532: PCIe (5.0GT/s
> > > > > x8)
> > > > > @
> > > > > :27:00.1 hdma+ host#=5 fw=8.03.00 (90d5).
> > > > >
> > > > > Rebooting on the same server with 4.10 fails to load
> > > > >
> > > > > Linux  4.10.0+
> > > > > # modinfo qla2xxx | more
> > > > > filename:
> > > > > /lib/modules/4.10.0+/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
> > > > > firmware:   ql2500_fw.bin
> > > > > version:8.07.00.38-k
> > > > > license:GPL
> > > > > description:QLogic Fibre Channel HBA Driver
> > > > > author: QLogic Corporation
> > > > > srcversion: 939E0595E8A3C2E1BE94392
> > > > >
> > > > > [8.754040] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel
> > > > > HBA
> > > > > Driver: 8.07.00.38-k.
> > > > > [9.979523] qla2xxx [:27:00.0]-001b: : BAR 3 not enabled.
> >

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

2017-03-13 Thread Laurence Oberman 


- Original Message -
> From: "Laurence Oberman" 
> To: "Himanshu Madhani" 
> Cc: "Chad Dupuis" , "Linux SCSI List" 
> 
> Sent: Monday, March 13, 2017 12:54:12 PM
> Subject: Re: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based 8Gb) 
> with BAR 3 error, work fine on 4.9
> 
> 
> 
> - Original Message -
> > From: "Himanshu Madhani" 
> > To: "Laurence Oberman" , "Chad Dupuis"
> > 
> > Cc: "Linux SCSI List" 
> > Sent: Monday, March 13, 2017 12:39:03 PM
> > Subject: RE: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based
> > 8Gb) with BAR 3 error, work fine on 4.9
> > 
> > Hi Laurence,
> > 
> > > -Original Message-
> > > From: Laurence Oberman [mailto:lober...@redhat.com]
> > > Sent: Sunday, March 12, 2017 11:31 AM
> > > To: Dupuis, Chad ; Madhani, Himanshu
> > > 
> > > Cc: Linux SCSI List 
> > > Subject: Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based
> > > 8Gb)
> > > with BAR 3 error, work fine on 4.9
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Laurence Oberman" 
> > > > To: "Chad Dupuis" , "Himanshu Madhani"
> > > > 
> > > > Cc: "Linux SCSI List" 
> > > > Sent: Sunday, March 12, 2017 7:39:23 AM
> > > > Subject: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based
> > > > 8Gb) with BAR 3 error, work fine on 4.9
> > > >
> > > > Chad, Himanshu
> > > >
> > > > Before I bisect or go chase changes, wanted to reach out because the
> > > > driver seems to be the same version.
> > > > Perhaps this is a PCIE change in the kernel for 4.10 affecting the
> > > > load.
> > > > Its the same targetLIO server I have been using for a long time with
> > > > 4.9
> > > >
> > > > 27:00.0 Fibre Channel: QLogic Corp. ISP2532-based 8Gb Fibre Channel to
> > > > PCI Express HBA (rev 02)
> > > >
> > > > With 4.9 I have no issues loading the driver for my targetLIO server.
> > > > (DL380G8)
> > > >
> > > > # modinfo qla2xxx | more
> > > > filename:
> > > > /lib/modules/4.9.0.lobetcm+/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
> > > > firmware:   ql2500_fw.bin
> > > > version:8.07.00.38-k
> > > > license:GPL
> > > > description:QLogic Fibre Channel HBA Driver
> > > > author: QLogic Corporation
> > > > srcversion: 94A8431A85BFF854B97B02D
> > > >
> > > > [8.906351] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA
> > > > Driver: 8.07.00.38-k.
> > > > [   10.014052] qla2xxx [:27:00.0]-001d: : Found an ISP2532 irq 106
> > > > iobase
> > > > 0xadce989a1000.
> > > > [   10.455108] scsi host4: qla2xxx
> > > > [   10.460206] qla2xxx [:27:00.0]-00fb:4: QLogic QLE2562 -
> > > > PCI-Express
> > > > Dual Channel 8Gb Fibre Channel HBA.
> > > > [   10.460215] qla2xxx [:27:00.0]-00fc:4: ISP2532: PCIe (5.0GT/s
> > > > x8)
> > > > @
> > > > :27:00.0 hdma+ host#=4 fw=8.03.00 (90d5).
> > > > [   10.460545] qla2xxx [:27:00.1]-001d: : Found an ISP2532 irq 110
> > > > iobase
> > > > 0xadce989a9000.
> > > > [   10.662120] scsi host5: qla2xxx
> > > > [   11.007841] qla2xxx [:27:00.1]-00fb:5: QLogic QLE2562 -
> > > > PCI-Express
> > > > Dual Channel 8Gb Fibre Channel HBA.
> > > > [   11.007849] qla2xxx [:27:00.1]-00fc:5: ISP2532: PCIe (5.0GT/s
> > > > x8)
> > > > @
> > > > :27:00.1 hdma+ host#=5 fw=8.03.00 (90d5).
> > > >
> > > > Rebooting on the same server with 4.10 fails to load
> > > >
> > > > Linux  4.10.0+
> > > > # modinfo qla2xxx | more
> > > > filename:
> > > > /lib/modules/4.10.0+/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
> > > > firmware:   ql2500_fw.bin
> > > > version:8.07.00.38-k
> > > > license:GPL
> > > > description:QLogic Fibre Channel HBA Driver
> > > > author: QLogic Corporation
> > > > srcversion: 939E0595E8A3C2E1BE94392
> > > >
> > > > [8.754040] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA
> > > > Driver: 8.07.00.38-k.
> > > > [9.979523] qla2xxx [:27:00.0]-001b: : BAR 3 not enabled.
> > > > [   10.201268] qla2xxx [:27:00.0]-001d: : Found an ISP2532 irq 110
> > > > iobase
> > > > 0xacbf189b1000.
> > > > [   10.407865] scsi host5: qla2xxx
> > > > [   10.444281] qla2xxx: probe of :27:00.0 failed with error -22
> > > > [   10.444519] qla2xxx [:27:00.1]-001b: : BAR 3 not enabled.
> > > > [   10.444522] qla2xxx [:27:00.1]-001d: : Found an ISP2532 irq 110
> > > > iobase
> > > > 0xacbf189b9000.
> > > > [   10.645932] scsi host5: qla2xxx
> > > > [   10.682233] qla2xxx: probe of :27:00.1 failed with error -22
> > > >
> > > > Thanks
> > > > Laurence
> > > >
> > > 
> > > I started bisecting this, cannot believe others

Re: [scsi] scsi: ufs: don't check unsigned type for a negative value

2017-03-13 Thread Subhash Jadavani 

On 2017-03-12 03:22, Tomas Winkler wrote:

Fix compilation warning

drivers/scsi/ufs/ufshcd.c:7645:13: warning: comparison of unsigned
expression < 0 is always false [-Wtype-limits]
if ((value < UFS_PM_LVL_0) || (value >= UFS_PM_LVL_MAX))

Signed-off-by: Tomas Winkler 
---
 drivers/scsi/ufs/ufshcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 1359913bf840..e8c26e6e6237 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7642,7 +7642,7 @@ static inline ssize_t ufshcd_pm_lvl_store(struct
device *dev,
if (kstrtoul(buf, 0, ))
return -EINVAL;

-   if ((value < UFS_PM_LVL_0) || (value >= UFS_PM_LVL_MAX))
+   if (value >= UFS_PM_LVL_MAX)
return -EINVAL;

spin_lock_irqsave(hba->host->host_lock, flags);


LGTM.
Reviewed-by: Subhash Jadavani 

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 net-next] qed*: Utilize Firmware 8.15.3.0

2017-03-13 Thread David Miller 
From: Christoph Hellwig 
Date: Mon, 13 Mar 2017 16:19:47 -0700

> On Mon, Mar 13, 2017 at 03:33:47PM -0700, David Miller wrote:
>> Applied, thanks.
> 
> So everyone who doesn't have the very latests linux-firmware will now
> have a non-working card after upgrading the kernel?

I deeply regret that you've missed more than a decade of precedence on
this matter.

Re: [PATCH v2 net-next] qed*: Utilize Firmware 8.15.3.0

2017-03-13 Thread Christoph Hellwig 
On Mon, Mar 13, 2017 at 03:33:47PM -0700, David Miller wrote:
> Applied, thanks.

So everyone who doesn't have the very latests linux-firmware will now
have a non-working card after upgrading the kernel?

Re: [PATCH v2 net-next] qed*: Utilize Firmware 8.15.3.0

2017-03-13 Thread David Miller 
From: Yuval Mintz 
Date: Sat, 11 Mar 2017 18:39:18 +0200

> This patch advances the qed* drivers into using the newer firmware -
> This solves several firmware bugs, mostly related [but not limited to]
> various init/deinit issues in various offloaded protocols.
> 
> It also introduces a major 4-Cached SGE change in firmware, which can be
> seen in the storage drivers' changes.
> 
> In addition, this firmware is required for supporting the new QL41xxx
> series of adapters; While this patch doesn't add the actual support,
> the firmware contains the necessary initialization & firmware logic to
> operate such adapters [actual support would be added later on].
> 
> Changes from Previous versions:
> ---
>  - V2 - fix kbuild-test robot warnings
> 
> Signed-off-by: Tomer Tayar 
> Signed-off-by: Ram Amrani 
> Signed-off-by: Manish Rangankar 
> Signed-off-by: Chad Dupuis 
> Signed-off-by: Yuval Mintz 

Applied, thanks.

Re: [PATCH v2] scsi_sysfs: fix hang when removing scsi device

2017-03-13 Thread James Bottomley 
On Mon, 2017-03-13 at 20:33 +, Bart Van Assche wrote:
> On Mon, 2017-03-13 at 12:23 -0700, James Bottomley wrote:
> > On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote:
> > > diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> > > index 7bfbcfa7af40..b3bb49d06943 100644
> > > --- a/drivers/scsi/scsi.c
> > > +++ b/drivers/scsi/scsi.c
> > > @@ -602,7 +602,7 @@ EXPORT_SYMBOL(scsi_device_get);
> > >   */
> > >  void scsi_device_put(struct scsi_device *sdev)
> > >  {
> > > -   module_put(sdev->host->hostt->module);
> > > +   module_put(sdev->hostt->module);
> > > put_device(>sdev_gendev);
> > >  }
> > >  EXPORT_SYMBOL(scsi_device_put);
> > > diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> > > index 6f7128f49c30..7134487abbb1 100644
> > > --- a/drivers/scsi/scsi_scan.c
> > > +++ b/drivers/scsi/scsi_scan.c
> > > @@ -227,6 +227,7 @@ static struct scsi_device
> > > *scsi_alloc_sdev(struct
> > > scsi_target *starget,
> > > sdev->model = scsi_null_device_strs;
> > > sdev->rev = scsi_null_device_strs;
> > > sdev->host = shost;
> > > +   sdev->hostt = shost->hostt;
> > > sdev->queue_ramp_up_period = SCSI_DEFAULT_RAMP_UP_PERIOD;
> > > sdev->id = starget->id;
> > > sdev->lun = lun;
> > > diff --git a/include/scsi/scsi_device.h
> > > b/include/scsi/scsi_device.h
> > > index 6f22b39f1b0c..cda620ed5922 100644
> > > --- a/include/scsi/scsi_device.h
> > > +++ b/include/scsi/scsi_device.h
> > > @@ -82,6 +82,7 @@ struct scsi_event {
> > >  
> > >  struct scsi_device {
> > > struct Scsi_Host *host;
> > > +   struct scsi_host_template *hostt;
> > > struct request_queue *request_queue;
> > >  
> > 
> > The apparent assumption behind this patch is that sdev->host can be
> > freed but the sdev will still exist?  That shouldn't be correct:
> > the
> > rule for struct devices is that the child always holds the parent
> > and
> > the host is parented (albeit not necessarily directly) to the sdev,
> > so
> > it looks like something has gone wrong if the host had been freed
> > before the sdev.
> 
> Hello James,
> 
> scsi_remove_host() decreases the sdev reference count but does not 
> wait until the sdev release work has finished. This is why the SCSI
> host can already have disappeared before the last scsi_device_put()
> call occurs.

This is true, but I don't see how it can cause the host to be freed
before the sdev.  The memory for struct Scsi_Host is freed in the
shost_gendev release routine, which should be pinned by the parent
traversal from sdev.  So it should not be possible for
 scsi_host_dev_release() to be called before
 scsi_device_dev_release_usercontext() becase the latter has the final
put of the parent device.

James

Re: [PATCH v2] scsi_sysfs: fix hang when removing scsi device

2017-03-13 Thread Bart Van Assche 
On Mon, 2017-03-13 at 12:23 -0700, James Bottomley wrote:
> On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote:
> > diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> > index 7bfbcfa7af40..b3bb49d06943 100644
> > --- a/drivers/scsi/scsi.c
> > +++ b/drivers/scsi/scsi.c
> > @@ -602,7 +602,7 @@ EXPORT_SYMBOL(scsi_device_get);
> >   */
> >  void scsi_device_put(struct scsi_device *sdev)
> >  {
> > -   module_put(sdev->host->hostt->module);
> > +   module_put(sdev->hostt->module);
> > put_device(>sdev_gendev);
> >  }
> >  EXPORT_SYMBOL(scsi_device_put);
> > diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> > index 6f7128f49c30..7134487abbb1 100644
> > --- a/drivers/scsi/scsi_scan.c
> > +++ b/drivers/scsi/scsi_scan.c
> > @@ -227,6 +227,7 @@ static struct scsi_device *scsi_alloc_sdev(struct
> > scsi_target *starget,
> > sdev->model = scsi_null_device_strs;
> > sdev->rev = scsi_null_device_strs;
> > sdev->host = shost;
> > +   sdev->hostt = shost->hostt;
> > sdev->queue_ramp_up_period = SCSI_DEFAULT_RAMP_UP_PERIOD;
> > sdev->id = starget->id;
> > sdev->lun = lun;
> > diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> > index 6f22b39f1b0c..cda620ed5922 100644
> > --- a/include/scsi/scsi_device.h
> > +++ b/include/scsi/scsi_device.h
> > @@ -82,6 +82,7 @@ struct scsi_event {
> >  
> >  struct scsi_device {
> > struct Scsi_Host *host;
> > +   struct scsi_host_template *hostt;
> > struct request_queue *request_queue;
> >  
> 
> The apparent assumption behind this patch is that sdev->host can be
> freed but the sdev will still exist?  That shouldn't be correct: the
> rule for struct devices is that the child always holds the parent and
> the host is parented (albeit not necessarily directly) to the sdev, so
> it looks like something has gone wrong if the host had been freed
> before the sdev.

Hello James,

scsi_remove_host() decreases the sdev reference count but does not wait
until the sdev release work has finished. This is why the SCSI host can
already have disappeared before the last scsi_device_put() call occurs.

Bart.

Re: [PATCH v2] scsi_sysfs: fix hang when removing scsi device

2017-03-13 Thread James Bottomley 
On Mon, 2017-03-13 at 18:49 +, Bart Van Assche wrote:
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 7bfbcfa7af40..b3bb49d06943 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -602,7 +602,7 @@ EXPORT_SYMBOL(scsi_device_get);
>   */
>  void scsi_device_put(struct scsi_device *sdev)
>  {
> -   module_put(sdev->host->hostt->module);
> +   module_put(sdev->hostt->module);
> put_device(>sdev_gendev);
>  }
>  EXPORT_SYMBOL(scsi_device_put);
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 6f7128f49c30..7134487abbb1 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -227,6 +227,7 @@ static struct scsi_device *scsi_alloc_sdev(struct
> scsi_target *starget,
> sdev->model = scsi_null_device_strs;
> sdev->rev = scsi_null_device_strs;
> sdev->host = shost;
> +   sdev->hostt = shost->hostt;
> sdev->queue_ramp_up_period = SCSI_DEFAULT_RAMP_UP_PERIOD;
> sdev->id = starget->id;
> sdev->lun = lun;
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index 6f22b39f1b0c..cda620ed5922 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -82,6 +82,7 @@ struct scsi_event {
>  
>  struct scsi_device {
> struct Scsi_Host *host;
> +   struct scsi_host_template *hostt;
> struct request_queue *request_queue;
>  

The apparent assumption behind this patch is that sdev->host can be
freed but the sdev will still exist?  That shouldn't be correct: the
rule for struct devices is that the child always holds the parent and
the host is parented (albeit not necessarily directly) to the sdev, so
it looks like something has gone wrong if the host had been freed
before the sdev.

James

[PATCH] scsi: cxgb3i: remove redundant null check and kfree on skb

2017-03-13 Thread Colin King 
From: Colin Ian King 

On the error exit path, skb is always null, so the non-null check
and __kfree_skb call are redundant.  Remove the redundant code,
rename the rel_release label to err and make error paths jump to
the err exit path.

Detected by CoverityScan, CID#114328 ("Logically Dead Code")

Signed-off-by: Colin Ian King 
---
 drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c 
b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
index 1880eb6..f453a78 100644
--- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
+++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
@@ -972,21 +972,21 @@ static int init_act_open(struct cxgbi_sock *csk)
  >daddr.sin_addr.s_addr);
if (!csk->l2t) {
pr_err("NO l2t available.\n");
-   return -EINVAL;
+   goto err;
}
cxgbi_sock_get(csk);
 
csk->atid = cxgb3_alloc_atid(t3dev, _client, csk);
if (csk->atid < 0) {
pr_err("NO atid available.\n");
-   goto rel_resource;
+   goto err;
}
cxgbi_sock_set_flag(csk, CTPF_HAS_ATID);
cxgbi_sock_get(csk);
 
skb = alloc_wr(sizeof(struct cpl_act_open_req), 0, GFP_KERNEL);
if (!skb)
-   goto rel_resource;
+   goto err;
skb->sk = (struct sock *)csk;
set_arp_failure_handler(skb, act_open_arp_failure);
csk->snd_win = cxgb3i_snd_win;
@@ -1008,9 +1008,7 @@ static int init_act_open(struct cxgbi_sock *csk)
send_act_open_req(csk, skb, csk->l2t);
return 0;
 
-rel_resource:
-   if (skb)
-   __kfree_skb(skb);
+err:
return -EINVAL;
 }
 
-- 
2.10.2

Re: [PATCH v2] scsi_sysfs: fix hang when removing scsi device

2017-03-13 Thread Bart Van Assche 
On Sun, 2017-03-12 at 12:26 +0200, Israel Rukshin wrote:
> scsi_device_get() affects I/O because scsi_target_unblock() use it and calls 
> to blk_start_queue().
> terminate_rport_io() is called after scsi_target_unblock() and completes all 
> the commands
> including the SYNCHRONIZE CACHE command.
> 
> I applied your patch and you can see that QUEUE_FLAG_STOPPED is on.

Hello Israel,

Thanks, that's very interesting feedback. Sorry but I prefer to fix
scsi_target_unblock() instead of changing __scsi_remove_device(). Would it
be possible to verify whether the five attached patches fix the issue you
had reported?

Thanks,

Bart.From 3c5882c9cd88265ff81f6321edc3caf2a2981f55 Mon Sep 17 00:00:00 2001
From: Bart Van Assche 
Date: Fri, 3 Mar 2017 11:13:39 -0800
Subject: [PATCH 1/5] Avoid that scsi_device_put() triggers a use-after-free

Avoid that the following crash occurs, a crash that is easy to
trigger with kernel v4.11-rc1 but that I only saw sporadically
in the past:

general protection fault:  [#1] SMP
RIP: 0010:scsi_device_put+0xb/0x30
Call Trace:
 scsi_disk_put+0x2d/0x40
 sd_release+0x3d/0xb0
 __blkdev_put+0x29e/0x360
 blkdev_put+0x49/0x170
 dm_put_table_device+0x58/0xc0 [dm_mod]
 dm_put_device+0x70/0xc0 [dm_mod]
 free_priority_group+0x92/0xc0 [dm_multipath]
 free_multipath+0x70/0xc0 [dm_multipath]
 multipath_dtr+0x19/0x20 [dm_multipath]
 dm_table_destroy+0x67/0x120 [dm_mod]
 dev_suspend+0xde/0x240 [dm_mod]
 ctl_ioctl+0x1f5/0x520 [dm_mod]
 dm_ctl_ioctl+0xe/0x20 [dm_mod]
 do_vfs_ioctl+0x8f/0x700
 SyS_ioctl+0x3c/0x70
 entry_SYSCALL_64_fastpath+0x18/0xad

Signed-off-by: Bart Van Assche 
Cc: 
---
 drivers/scsi/scsi.c| 2 +-
 drivers/scsi/scsi_scan.c   | 1 +
 include/scsi/scsi_device.h | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 7bfbcfa7af40..b3bb49d06943 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -602,7 +602,7 @@ EXPORT_SYMBOL(scsi_device_get);
  */
 void scsi_device_put(struct scsi_device *sdev)
 {
-	module_put(sdev->host->hostt->module);
+	module_put(sdev->hostt->module);
 	put_device(>sdev_gendev);
 }
 EXPORT_SYMBOL(scsi_device_put);
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 6f7128f49c30..7134487abbb1 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -227,6 +227,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
 	sdev->model = scsi_null_device_strs;
 	sdev->rev = scsi_null_device_strs;
 	sdev->host = shost;
+	sdev->hostt = shost->hostt;
 	sdev->queue_ramp_up_period = SCSI_DEFAULT_RAMP_UP_PERIOD;
 	sdev->id = starget->id;
 	sdev->lun = lun;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 6f22b39f1b0c..cda620ed5922 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -82,6 +82,7 @@ struct scsi_event {
 
 struct scsi_device {
 	struct Scsi_Host *host;
+	struct scsi_host_template *hostt;
 	struct request_queue *request_queue;
 
 	/* the next two are protected by the host->host_lock */
-- 
2.12.0

From ec349df5c6b0336c746c109895d717b2be8151cb Mon Sep 17 00:00:00 2001
From: Bart Van Assche 
Date: Fri, 3 Mar 2017 11:05:13 -0800
Subject: [PATCH 2/5] Change sdev->host->hostt into sdev->hostt

Now that the host template pointer is cached in the SCSI device
structure, use that pointer instead of going around through the
SCSI host. This patch does not change any functionality.

Signed-off-by: Bart Van Assche 
---
 drivers/scsi/osst.c   |  7 +++
 drivers/scsi/raid_class.c |  2 +-
 drivers/scsi/scsi.c   |  2 +-
 drivers/scsi/scsi_error.c | 10 +-
 drivers/scsi/scsi_ioctl.c |  4 ++--
 drivers/scsi/scsi_lib.c   |  2 +-
 drivers/scsi/scsi_scan.c  |  4 ++--
 drivers/scsi/scsi_sysfs.c | 16 
 drivers/scsi/sd.c |  8 
 drivers/scsi/sg.c | 14 +-
 drivers/scsi/st.c |  5 ++---
 11 files changed, 34 insertions(+), 40 deletions(-)

diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c
index c47f4b349bac..410a5865eae3 100644
--- a/drivers/scsi/osst.c
+++ b/drivers/scsi/osst.c
@@ -5285,11 +5285,10 @@ static long osst_compat_ioctl(struct file * file, unsigned int cmd_in, unsigned
 	struct osst_tape *STp = file->private_data;
 	struct scsi_device *sdev = STp->device;
 	int ret = -ENOIOCTLCMD;
-	if (sdev->host->hostt->compat_ioctl) {
 
-		ret = sdev->host->hostt->compat_ioctl(sdev, cmd_in, (void __user *)arg);
-
-	}
+	if (sdev->hostt->compat_ioctl)
+		ret = sdev->hostt->compat_ioctl(sdev, cmd_in,
+		(void __user *)arg);
 	return ret;
 }
 #endif
diff --git a/drivers/scsi/raid_class.c b/drivers/scsi/raid_class.c
index 2c146b44d95f..ccde6e1d8dd5 100644
--- a/drivers/scsi/raid_class.c
+++ b/drivers/scsi/raid_class.c
@@ -67,7 +67,7 @@ static int raid_match(struct attribute_container *cont, struct

Re: [PATCH] libata: make ata_sg_clean static over again

2017-03-13 Thread Tejun Heo 
On Fri, Mar 10, 2017 at 10:05:40AM +0800, Jason Yan wrote:
> Fixes the following sparse warning:
> 
> drivers/ata/libata-core.c:4913:6: warning: symbol 'ata_sg_clean' was not
> declared. Should it be static?
> 
> Signed-off-by: Jason Yan 

Applied to libata/for-4.12.

Thanks.

-- 
tejun

Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

2017-03-13 Thread Laurence Oberman 


- Original Message -
> From: "Himanshu Madhani" 
> To: "Laurence Oberman" , "Chad Dupuis" 
> 
> Cc: "Linux SCSI List" 
> Sent: Monday, March 13, 2017 12:39:03 PM
> Subject: RE: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based 8Gb) 
> with BAR 3 error, work fine on 4.9
> 
> Hi Laurence,
> 
> > -Original Message-
> > From: Laurence Oberman [mailto:lober...@redhat.com]
> > Sent: Sunday, March 12, 2017 11:31 AM
> > To: Dupuis, Chad ; Madhani, Himanshu
> > 
> > Cc: Linux SCSI List 
> > Subject: Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb)
> > with BAR 3 error, work fine on 4.9
> > 
> > 
> > 
> > - Original Message -
> > > From: "Laurence Oberman" 
> > > To: "Chad Dupuis" , "Himanshu Madhani"
> > > 
> > > Cc: "Linux SCSI List" 
> > > Sent: Sunday, March 12, 2017 7:39:23 AM
> > > Subject: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based
> > > 8Gb) with BAR 3 error, work fine on 4.9
> > >
> > > Chad, Himanshu
> > >
> > > Before I bisect or go chase changes, wanted to reach out because the
> > > driver seems to be the same version.
> > > Perhaps this is a PCIE change in the kernel for 4.10 affecting the load.
> > > Its the same targetLIO server I have been using for a long time with
> > > 4.9
> > >
> > > 27:00.0 Fibre Channel: QLogic Corp. ISP2532-based 8Gb Fibre Channel to
> > > PCI Express HBA (rev 02)
> > >
> > > With 4.9 I have no issues loading the driver for my targetLIO server.
> > > (DL380G8)
> > >
> > > # modinfo qla2xxx | more
> > > filename:
> > > /lib/modules/4.9.0.lobetcm+/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
> > > firmware:   ql2500_fw.bin
> > > version:8.07.00.38-k
> > > license:GPL
> > > description:QLogic Fibre Channel HBA Driver
> > > author: QLogic Corporation
> > > srcversion: 94A8431A85BFF854B97B02D
> > >
> > > [8.906351] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA
> > > Driver: 8.07.00.38-k.
> > > [   10.014052] qla2xxx [:27:00.0]-001d: : Found an ISP2532 irq 106
> > > iobase
> > > 0xadce989a1000.
> > > [   10.455108] scsi host4: qla2xxx
> > > [   10.460206] qla2xxx [:27:00.0]-00fb:4: QLogic QLE2562 -
> > > PCI-Express
> > > Dual Channel 8Gb Fibre Channel HBA.
> > > [   10.460215] qla2xxx [:27:00.0]-00fc:4: ISP2532: PCIe (5.0GT/s x8)
> > > @
> > > :27:00.0 hdma+ host#=4 fw=8.03.00 (90d5).
> > > [   10.460545] qla2xxx [:27:00.1]-001d: : Found an ISP2532 irq 110
> > > iobase
> > > 0xadce989a9000.
> > > [   10.662120] scsi host5: qla2xxx
> > > [   11.007841] qla2xxx [:27:00.1]-00fb:5: QLogic QLE2562 -
> > > PCI-Express
> > > Dual Channel 8Gb Fibre Channel HBA.
> > > [   11.007849] qla2xxx [:27:00.1]-00fc:5: ISP2532: PCIe (5.0GT/s x8)
> > > @
> > > :27:00.1 hdma+ host#=5 fw=8.03.00 (90d5).
> > >
> > > Rebooting on the same server with 4.10 fails to load
> > >
> > > Linux  4.10.0+
> > > # modinfo qla2xxx | more
> > > filename:
> > > /lib/modules/4.10.0+/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
> > > firmware:   ql2500_fw.bin
> > > version:8.07.00.38-k
> > > license:GPL
> > > description:QLogic Fibre Channel HBA Driver
> > > author: QLogic Corporation
> > > srcversion: 939E0595E8A3C2E1BE94392
> > >
> > > [8.754040] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA
> > > Driver: 8.07.00.38-k.
> > > [9.979523] qla2xxx [:27:00.0]-001b: : BAR 3 not enabled.
> > > [   10.201268] qla2xxx [:27:00.0]-001d: : Found an ISP2532 irq 110
> > > iobase
> > > 0xacbf189b1000.
> > > [   10.407865] scsi host5: qla2xxx
> > > [   10.444281] qla2xxx: probe of :27:00.0 failed with error -22
> > > [   10.444519] qla2xxx [:27:00.1]-001b: : BAR 3 not enabled.
> > > [   10.444522] qla2xxx [:27:00.1]-001d: : Found an ISP2532 irq 110
> > > iobase
> > > 0xacbf189b9000.
> > > [   10.645932] scsi host5: qla2xxx
> > > [   10.682233] qla2xxx: probe of :27:00.1 failed with error -22
> > >
> > > Thanks
> > > Laurence
> > >
> > 
> > I started bisecting this, cannot believe others have not bumped into this
> > on
> > 4.10.
> > This is a generic QLE2562 and firmware is loaded by the driver so wondering
> > why I am seeing this and other are not.
> > There is nothing special with the PCIE bus on this DL380G8.
> > 
> > Anyway during the bisect I got to a point where in the 4.10 commits I still
> > saw
> > the "BAR 3" message but the probe worked.
> > 
> > [7.208237] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA
> > Driver:
> > 8.07.00.38-k.
> > [7.208492] qla2xxx [:27:00.0]-001b: : BAR 3 not enabled.
> > 
> >see this above but probe did not fail
> > 
> > [7.208494] qla2xxx

RE: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb) with BAR 3 error, work fine on 4.9

2017-03-13 Thread Madhani, Himanshu 
Hi Laurence,

> -Original Message-
> From: Laurence Oberman [mailto:lober...@redhat.com]
> Sent: Sunday, March 12, 2017 11:31 AM
> To: Dupuis, Chad ; Madhani, Himanshu
> 
> Cc: Linux SCSI List 
> Subject: Re: 4.10+ qla2xxx driver wont load for qla2xxx (ISP2532-based 8Gb)
> with BAR 3 error, work fine on 4.9
> 
> 
> 
> - Original Message -
> > From: "Laurence Oberman" 
> > To: "Chad Dupuis" , "Himanshu Madhani"
> > 
> > Cc: "Linux SCSI List" 
> > Sent: Sunday, March 12, 2017 7:39:23 AM
> > Subject: 4.10+ qla2xxx  driver wont load for qla2xxx (ISP2532-based
> > 8Gb) with BAR 3 error, work fine on 4.9
> >
> > Chad, Himanshu
> >
> > Before I bisect or go chase changes, wanted to reach out because the
> > driver seems to be the same version.
> > Perhaps this is a PCIE change in the kernel for 4.10 affecting the load.
> > Its the same targetLIO server I have been using for a long time with
> > 4.9
> >
> > 27:00.0 Fibre Channel: QLogic Corp. ISP2532-based 8Gb Fibre Channel to
> > PCI Express HBA (rev 02)
> >
> > With 4.9 I have no issues loading the driver for my targetLIO server.
> > (DL380G8)
> >
> > # modinfo qla2xxx | more
> > filename:
> > /lib/modules/4.9.0.lobetcm+/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
> > firmware:   ql2500_fw.bin
> > version:8.07.00.38-k
> > license:GPL
> > description:QLogic Fibre Channel HBA Driver
> > author: QLogic Corporation
> > srcversion: 94A8431A85BFF854B97B02D
> >
> > [8.906351] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA
> > Driver: 8.07.00.38-k.
> > [   10.014052] qla2xxx [:27:00.0]-001d: : Found an ISP2532 irq 106 
> > iobase
> > 0xadce989a1000.
> > [   10.455108] scsi host4: qla2xxx
> > [   10.460206] qla2xxx [:27:00.0]-00fb:4: QLogic QLE2562 - PCI-Express
> > Dual Channel 8Gb Fibre Channel HBA.
> > [   10.460215] qla2xxx [:27:00.0]-00fc:4: ISP2532: PCIe (5.0GT/s x8) @
> > :27:00.0 hdma+ host#=4 fw=8.03.00 (90d5).
> > [   10.460545] qla2xxx [:27:00.1]-001d: : Found an ISP2532 irq 110 
> > iobase
> > 0xadce989a9000.
> > [   10.662120] scsi host5: qla2xxx
> > [   11.007841] qla2xxx [:27:00.1]-00fb:5: QLogic QLE2562 - PCI-Express
> > Dual Channel 8Gb Fibre Channel HBA.
> > [   11.007849] qla2xxx [:27:00.1]-00fc:5: ISP2532: PCIe (5.0GT/s x8) @
> > :27:00.1 hdma+ host#=5 fw=8.03.00 (90d5).
> >
> > Rebooting on the same server with 4.10 fails to load
> >
> > Linux  4.10.0+
> > # modinfo qla2xxx | more
> > filename:   /lib/modules/4.10.0+/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
> > firmware:   ql2500_fw.bin
> > version:8.07.00.38-k
> > license:GPL
> > description:QLogic Fibre Channel HBA Driver
> > author: QLogic Corporation
> > srcversion: 939E0595E8A3C2E1BE94392
> >
> > [8.754040] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA
> > Driver: 8.07.00.38-k.
> > [9.979523] qla2xxx [:27:00.0]-001b: : BAR 3 not enabled.
> > [   10.201268] qla2xxx [:27:00.0]-001d: : Found an ISP2532 irq 110 
> > iobase
> > 0xacbf189b1000.
> > [   10.407865] scsi host5: qla2xxx
> > [   10.444281] qla2xxx: probe of :27:00.0 failed with error -22
> > [   10.444519] qla2xxx [:27:00.1]-001b: : BAR 3 not enabled.
> > [   10.444522] qla2xxx [:27:00.1]-001d: : Found an ISP2532 irq 110 
> > iobase
> > 0xacbf189b9000.
> > [   10.645932] scsi host5: qla2xxx
> > [   10.682233] qla2xxx: probe of :27:00.1 failed with error -22
> >
> > Thanks
> > Laurence
> >
> 
> I started bisecting this, cannot believe others have not bumped into this on
> 4.10.
> This is a generic QLE2562 and firmware is loaded by the driver so wondering
> why I am seeing this and other are not.
> There is nothing special with the PCIE bus on this DL380G8.
> 
> Anyway during the bisect I got to a point where in the 4.10 commits I still 
> saw
> the "BAR 3" message but the probe worked.
> 
> [7.208237] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver:
> 8.07.00.38-k.
> [7.208492] qla2xxx [:27:00.0]-001b: : BAR 3 not enabled.
> 
>see this above but probe did not fail
> 
> [7.208494] qla2xxx [:27:00.0]-001d: : Found an ISP2532 irq 97 iobase
> 0xc02f98989000.
> [7.414738] scsi host4: qla2xxx
> 
> [7.419267] qla2xxx [:27:00.0]-00fb:4: QLogic QLE2562 - PCI-Express 
> Dual
> Channel 8Gb Fibre Channel HBA.
> [7.419278] qla2xxx [:27:00.0]-00fc:4: ISP2532: PCIe (5.0GT/s x8) @
> :27:00.0 hdma+ host#=4 fw=8.03.00 (90d5).
> [7.419698] qla2xxx [:27:00.1]-001b: : BAR 3 not enabled.
> [7.419701] qla2xxx [:27:00.1]-001d: : Found an ISP2532 irq 100 iobase
> 0xc02f989b1000.
> [7.625691] scsi host6: qla2xxx
> [7.629218] qla2xxx [:27:00.1]-00fb:6: QLogic QLE2562 - PCI-Express 
> Dual
> Channel

[Bug 194837] VM with virtio-scsi drive often crashes during boot with kernel 4.11rc1

2017-03-13 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=194837

--- Comment #5 from Adam Williamson (ad...@happyassassin.net) ---
Only here and downstream Bugzilla. I'm not really signed up to any kernel
mailing lists. Please do feel free to forward it anywhere appropriate...

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [PATCHv3 1/6] scsi_error: count medium access timeout only once per EH run

2017-03-13 Thread Mauricio Faria de Oliveira 

On 03/13/2017 11:48 AM, Hannes Reinecke wrote:

This is assuming that we're always running on a scsi_disk, and that
scsi_disk is the only one implementing 'eh_action'.
Neither of which is necessarily true.


Ah, OK. Thanks for explaining.


--
Mauricio Faria de Oliveira
IBM Linux Technology Center

Re: [PATCHv4 09/12] mpt3sas: simplify task management functions

2017-03-13 Thread Hannes Reinecke 
On 03/06/2017 06:16 AM, Sreekanth Reddy wrote:
> I feel that using these flags are not working as expected. From the
> driver's prospective it should return status of the TM based on
> whether it has cleared reference of the timed out IO in the driver or
> not (i.e. if it is successfully able to clear the reference (i.e.
> cleared from scsi lookup) of the timed out IO from driver, firmware
> then return success status otherwise return failure status). It should
> not check for it's above layer reference.
> 
Looking into it you are actually right.

The SCSI midlayer will only decrease a 'device_busy' and the like if the
commands are completed, ie after ->scsi_done() has been called.
But the whole point of the error handler OTOH is that ->scsi_done() is
_not_ called, but rather the commands are left alone until SCSI EH
completed, and only _then_ calling ->scsi_done().

Hence 'device_busy' et al trivially can never be zero while SCSI EH is
running.

I'll be rewriting that for the next submission.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[Bug 194837] VM with virtio-scsi drive often crashes during boot with kernel 4.11rc1

2017-03-13 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=194837

--- Comment #4 from Thorsten Leemhuis (li...@leemhuis.info) ---
(In reply to Adam Williamson from comment #1)
> so the delta is to 'v4.10-11319-gc82be9d', but I dunno what that means
> exactly.

FWIW, most likely suspects afaics: the second batches with changes to KVM and
SCSI
https://git.kernel.org/torvalds/c/2d62e0768d3c28536d4cfe4c40ba1e5e8e442a93
https://git.kernel.org/torvalds/c/a3b4924b027f9a4b95ce89a914c1e0459e76f18a

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 194837] VM with virtio-scsi drive often crashes during boot with kernel 4.11rc1

2017-03-13 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=194837

Thorsten Leemhuis (li...@leemhuis.info) changed:

   What|Removed |Added

 CC||li...@leemhuis.info

--- Comment #3 from Thorsten Leemhuis (li...@leemhuis.info) ---
Seeing this also (RHEL Host, KVM)

Adam, did you report this here only or also to some mailinglist?

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [PATCH] scsi: storvsc: Add support for FC rport.

2017-03-13 Thread Cathy Avery 

Hi,

I haven't received any feedback yet.

Should I resend?

Thanks,

Cathy

On 02/28/2017 01:45 PM, Cathy Avery wrote:

Included in the current storvsc driver for Hyper-V is the ability
to access luns on an FC fabric via a virtualized fiber channel
adapter exposed by the Hyper-V host. The driver also attaches to the FC
transport to allow host and port names to be published under
/sys/class/fc_host/hostX. Current customer tools running on the VM
require that these names be available in the well known standard
location under fc_host/hostX.

A problem arose when attaching to the FC transport. The scsi_scan
code attempts to call fc_user_scan which has basically become a no-op
due to the fact that the virtualized FC device does not expose rports.
At this point you cannot refresh the scsi bus after mapping or unmapping
luns on the SAN without a reboot of the VM.

This patch stubs in an rport per fc_host in storvsc so that the
requirement of a defined rport is now met within the fc_transport and
echo "- - -" > /sys/class/scsi_host/hostX/scan now works.

Signed-off-by: Cathy Avery 
---
  drivers/scsi/storvsc_drv.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 585e54f..6d7b932 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -478,6 +478,9 @@ struct storvsc_device {
 */
u64 node_name;
u64 port_name;
+#if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
+   struct fc_rport *rport;
+#endif
  };
  
  struct hv_host_device {

@@ -1823,8 +1826,16 @@ static int storvsc_probe(struct hv_device *device,
}
  #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
if (host->transportt == fc_transport_template) {
+   struct fc_rport_identifiers ids;
+
+   ids.node_name = 0;
+   ids.port_name = 0;
+   ids.port_id = 0;
+   ids.roles |= FC_PORT_ROLE_FCP_TARGET;
+
fc_host_node_name(host) = stor_device->node_name;
fc_host_port_name(host) = stor_device->port_name;
+   stor_device->rport = fc_remote_port_add(host, 0, );
}
  #endif
return 0;
@@ -1854,8 +1865,10 @@ static int storvsc_remove(struct hv_device *dev)
struct Scsi_Host *host = stor_device->host;
  
  #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)

-   if (host->transportt == fc_transport_template)
+   if (host->transportt == fc_transport_template) {
+   fc_remote_port_delete(stor_device->rport);
fc_remove_host(host);
+   }
  #endif
scsi_remove_host(host);
storvsc_dev_remove(dev);

Re: [PATCHv3 1/6] scsi_error: count medium access timeout only once per EH run

2017-03-13 Thread Hannes Reinecke 
On 03/13/2017 02:37 PM, Mauricio Faria de Oliveira wrote:
> Hannes,
> 
> On 03/01/2017 06:15 AM, Hannes Reinecke wrote:
>> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
>> index f2cafae..cec439c 100644
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -58,6 +58,7 @@
>>  static int scsi_eh_try_stu(struct scsi_cmnd *scmd);
>>  static int scsi_try_to_abort_cmd(struct scsi_host_template *,
>>   struct scsi_cmnd *);
>> +static int scsi_eh_reset(struct scsi_cmnd *scmd);
>>
>>  /* called with shost->host_lock held */
>>  void scsi_eh_wakeup(struct Scsi_Host *shost)
>> @@ -249,6 +250,7 @@ int scsi_eh_scmd_add(struct scsi_cmnd *scmd, int
>> eh_flag)
>>  if (scmd->eh_eflags & SCSI_EH_ABORT_SCHEDULED)
>>  eh_flag &= ~SCSI_EH_CANCEL_CMD;
>>  scmd->eh_eflags |= eh_flag;
>> +scsi_eh_reset(scmd);
>>  list_add_tail(>eh_entry, >eh_cmd_q);
>>  shost->host_failed++;
>>  scsi_eh_wakeup(shost);
>> @@ -1107,7 +1109,19 @@ static int scsi_eh_action(struct scsi_cmnd
>> *scmd, int rtn)
>>  if (!blk_rq_is_passthrough(scmd->request)) {
>>  struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
>>  if (sdrv->eh_action)
>> -rtn = sdrv->eh_action(scmd, rtn);
>> +rtn = sdrv->eh_action(scmd, rtn, false);
>> +}
>> +return rtn;
>> +}
>> +
>> +static int scsi_eh_reset(struct scsi_cmnd *scmd)
>> +{
>> +int rtn = SUCCESS;
>> +
>> +if (!blk_rq_is_passthrough(scmd->request)) {
>> +struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
>> +if (sdrv->eh_action)
>> +rtn = sdrv->eh_action(scmd, rtn, true);
>>  }
>>  return rtn;
>>  }
> 
> Apparently we can de-duplicate code in scsi_eh_reset()/scsi_eh_action(),
> and change less of sd_eh_action() (i.e., no new parameter).
> 
> Something like this.  Thoughts?
> 
> 
> - Deduplicate code in scsi_eh_reset() and scsi_eh_action()
>   - A call to scsi_eh_reset() with reset == false calls into eh_action()
> 
>   - A call to scsi_eh_reset() with reset == true returns early,
> (as happens with/if sd_eh_action() is called in your patch)
> 
>   - A call to scsi_eh_reset() in scsi_eh_scmd_add() uses SUCCESS just
> for consistency with scsi_eh_reset() in your patch, as the return
> value is ignored in it.
> 
> - Less changes to sd_eh_action()
>   - Removed one chunk in sd_eh_action() ('reset gate variable')
>   - No more parameter changes in sd_eh_action() (no 'reset' parameter)
> 
> - Removed forward declaration of scsi_eh_reset(), as already suggested
> 
> 
> 
> static int scsi_eh_reset(struct scsi_cmnd *scmd, int eh_disp, bool reset)
> {
> int rtn = eh_disp;
> 
> if (!blk_rq_is_passthrough(scmd->request)) {
> struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
> if (sdrv->eh_action) {
> if (reset) {
>  struct scsi_disk *sdkp =
> scsi_disk(scmd->request->rq_disk);
> 
> /* New SCSI EH run, reset gate variable */
> sdkp->medium_access_reset = 0;
> return rtn;
> }
> rtn = sdrv->eh_action(scmd, rtn);
> }
>  }
>  return rtn;
> }
> 
Nope.

This is assuming that we're always running on a scsi_disk, and that
scsi_disk is the only one implementing 'eh_action'.
Neither of which is necessarily true.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCHv3 1/6] scsi_error: count medium access timeout only once per EH run

2017-03-13 Thread Mauricio Faria de Oliveira 

Hannes,

On 03/01/2017 06:15 AM, Hannes Reinecke wrote:

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index f2cafae..cec439c 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -58,6 +58,7 @@
 static int scsi_eh_try_stu(struct scsi_cmnd *scmd);
 static int scsi_try_to_abort_cmd(struct scsi_host_template *,
 struct scsi_cmnd *);
+static int scsi_eh_reset(struct scsi_cmnd *scmd);

 /* called with shost->host_lock held */
 void scsi_eh_wakeup(struct Scsi_Host *shost)
@@ -249,6 +250,7 @@ int scsi_eh_scmd_add(struct scsi_cmnd *scmd, int eh_flag)
if (scmd->eh_eflags & SCSI_EH_ABORT_SCHEDULED)
eh_flag &= ~SCSI_EH_CANCEL_CMD;
scmd->eh_eflags |= eh_flag;
+   scsi_eh_reset(scmd);
list_add_tail(>eh_entry, >eh_cmd_q);
shost->host_failed++;
scsi_eh_wakeup(shost);
@@ -1107,7 +1109,19 @@ static int scsi_eh_action(struct scsi_cmnd *scmd, int 
rtn)
if (!blk_rq_is_passthrough(scmd->request)) {
struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
if (sdrv->eh_action)
-   rtn = sdrv->eh_action(scmd, rtn);
+   rtn = sdrv->eh_action(scmd, rtn, false);
+   }
+   return rtn;
+}
+
+static int scsi_eh_reset(struct scsi_cmnd *scmd)
+{
+   int rtn = SUCCESS;
+
+   if (!blk_rq_is_passthrough(scmd->request)) {
+   struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
+   if (sdrv->eh_action)
+   rtn = sdrv->eh_action(scmd, rtn, true);
}
return rtn;
 }


Apparently we can de-duplicate code in scsi_eh_reset()/scsi_eh_action(),
and change less of sd_eh_action() (i.e., no new parameter).

Something like this.  Thoughts?


- Deduplicate code in scsi_eh_reset() and scsi_eh_action()
  - A call to scsi_eh_reset() with reset == false calls into eh_action()

  - A call to scsi_eh_reset() with reset == true returns early,
(as happens with/if sd_eh_action() is called in your patch)

  - A call to scsi_eh_reset() in scsi_eh_scmd_add() uses SUCCESS just
for consistency with scsi_eh_reset() in your patch, as the return
value is ignored in it.

- Less changes to sd_eh_action()
  - Removed one chunk in sd_eh_action() ('reset gate variable')
  - No more parameter changes in sd_eh_action() (no 'reset' parameter)

- Removed forward declaration of scsi_eh_reset(), as already suggested



static int scsi_eh_reset(struct scsi_cmnd *scmd, int eh_disp, bool reset)
{
int rtn = eh_disp;

if (!blk_rq_is_passthrough(scmd->request)) {
struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
if (sdrv->eh_action) {
if (reset) {
struct scsi_disk *sdkp = 
scsi_disk(scmd->request->rq_disk);

/* New SCSI EH run, reset gate variable */
sdkp->medium_access_reset = 0;
return rtn;
}
rtn = sdrv->eh_action(scmd, rtn);
}
}
return rtn;
}

Plus,

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index f2cafae..cec439c 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -249,6 +250,7 @@ int scsi_eh_scmd_add(struct scsi_cmnd *scmd, int 
eh_flag)

if (scmd->eh_eflags & SCSI_EH_ABORT_SCHEDULED)
eh_flag &= ~SCSI_EH_CANCEL_CMD;
scmd->eh_eflags |= eh_flag;
+	scsi_eh_reset(scmd, SUCCESS, true); // return value is ignored (early 
exit due to reset)

list_add_tail(>eh_entry, >eh_cmd_q);
shost->host_failed++;
scsi_eh_wakeup(shost);
@@ -1107,7 +1109,19 @@ static int scsi_eh_action(struct scsi_cmnd *scmd, 
int rtn)

-   if (!blk_rq_is_passthrough(scmd->request)) {
-   struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
-   if (sdrv->eh_action)
-   rtn = sdrv->eh_action(scmd, rtn);
-   }
-   return rtn;
+   return scsi_eh_reset(scmd, rtn, false);
 }


And the rest, without the 'reset' parameter.

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index c7839f6..c794686 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1689,X +1689,Y @@ static int sd_pr_clear(struct block_device *bdev, 
u64 key)

  * sd_eh_action - error handling callback
  * @scmd:  sd-issued command that has failed
  * @eh_disp:   The recovery disposition suggested by the midlayer
  *
  * This function is called by the SCSI midlayer upon completion of an
  * error test command (currently TEST UNIT READY). The result of sending
  * the eh command is passed in eh_disp.  We're looking for devices that
  * fail medium access commands but are OK with non access commands like
  * test unit ready (so wrongly see the device as having a successful
- *

Re: [PATCHv3 1/6] scsi_error: count medium access timeout only once per EH run

2017-03-13 Thread Hannes Reinecke 
On 03/02/2017 09:16 PM, Benjamin Block wrote:
> Hej Hannes,
> 
> On Wed, Mar 01, 2017 at 10:15:15AM +0100, Hannes Reinecke wrote:
>> The current medium access timeout counter will be increased for
>> each command, so if there are enough failed commands we'll hit
>> the medium access timeout for even a single failure.
>> Fix this by making the timeout per EH run, ie the counter will
>> only be increased once per device and EH run.
>>
>> Cc: Ewan Milne 
>> Cc: Lawrence Obermann 
>> Cc: Benjamin Block 
>> Cc: Steffen Maier 
>> Signed-off-by: Hannes Reinecke 
> 
> Steffen already suggested it, It would be nice to have a stable-tag
> here. This already caused multiple real-world false-positive outages, I
> think that qualifies for stable :)
> 
>> ---
>>  drivers/scsi/scsi_error.c  | 16 +++-
>>  drivers/scsi/sd.c  | 21 +
>>  drivers/scsi/sd.h  |  1 +
>>  include/scsi/scsi_driver.h |  2 +-
>>  4 files changed, 34 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
>> index f2cafae..cec439c 100644
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -58,6 +58,7 @@
>>  static int scsi_eh_try_stu(struct scsi_cmnd *scmd);
>>  static int scsi_try_to_abort_cmd(struct scsi_host_template *,
>>   struct scsi_cmnd *);
>> +static int scsi_eh_reset(struct scsi_cmnd *scmd);
>>
>>  /* called with shost->host_lock held */
>>  void scsi_eh_wakeup(struct Scsi_Host *shost)
>> @@ -249,6 +250,7 @@ int scsi_eh_scmd_add(struct scsi_cmnd *scmd, int eh_flag)
>>  if (scmd->eh_eflags & SCSI_EH_ABORT_SCHEDULED)
>>  eh_flag &= ~SCSI_EH_CANCEL_CMD;
>>  scmd->eh_eflags |= eh_flag;
>> +scsi_eh_reset(scmd);
>>  list_add_tail(>eh_entry, >eh_cmd_q);
>>  shost->host_failed++;
>>  scsi_eh_wakeup(shost);
>> @@ -1107,7 +1109,19 @@ static int scsi_eh_action(struct scsi_cmnd *scmd, int 
>> rtn)
>>  if (!blk_rq_is_passthrough(scmd->request)) {
>>  struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
>>  if (sdrv->eh_action)
>> -rtn = sdrv->eh_action(scmd, rtn);
>> +rtn = sdrv->eh_action(scmd, rtn, false);
>> +}
>> +return rtn;
>> +}
>> +
>> +static int scsi_eh_reset(struct scsi_cmnd *scmd)
>> +{
>> +int rtn = SUCCESS;
>> +
>> +if (!blk_rq_is_passthrough(scmd->request)) {
>> +struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
>> +if (sdrv->eh_action)
>> +rtn = sdrv->eh_action(scmd, rtn, true);
>>  }
>>  return rtn;
>>  }
>> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
>> index c7839f6..c794686 100644
>> --- a/drivers/scsi/sd.c
>> +++ b/drivers/scsi/sd.c
>> @@ -115,7 +115,7 @@
>>  static int sd_init_command(struct scsi_cmnd *SCpnt);
>>  static void sd_uninit_command(struct scsi_cmnd *SCpnt);
>>  static int sd_done(struct scsi_cmnd *);
>> -static int sd_eh_action(struct scsi_cmnd *, int);
>> +static int sd_eh_action(struct scsi_cmnd *, int, bool);
>>  static void sd_read_capacity(struct scsi_disk *sdkp, unsigned char *buffer);
>>  static void scsi_disk_release(struct device *cdev);
>>  static void sd_print_sense_hdr(struct scsi_disk *, struct scsi_sense_hdr *);
>> @@ -1689,18 +1689,28 @@ static int sd_pr_clear(struct block_device *bdev, 
>> u64 key)
>>   *  sd_eh_action - error handling callback
>>   *  @scmd:  sd-issued command that has failed
>>   *  @eh_disp:   The recovery disposition suggested by the midlayer
>> + *  @reset: Reset medium access counter
>>   *
>>   *  This function is called by the SCSI midlayer upon completion of an
>>   *  error test command (currently TEST UNIT READY). The result of sending
>>   *  the eh command is passed in eh_disp.  We're looking for devices that
>>   *  fail medium access commands but are OK with non access commands like
>>   *  test unit ready (so wrongly see the device as having a successful
>> - *  recovery)
>> + *  recovery).
>> + *  We have to be careful to count a medium access failure only once
>> + *  per SCSI EH run; there might be several timed out commands which
>> + *  will cause the 'max_medium_access_timeouts' counter to trigger
>> + *  after the first SCSI EH run already and set the device to offline.
>>   **/
>> -static int sd_eh_action(struct scsi_cmnd *scmd, int eh_disp)
>> +static int sd_eh_action(struct scsi_cmnd *scmd, int eh_disp, bool reset)
>>  {
>>  struct scsi_disk *sdkp = scsi_disk(scmd->request->rq_disk);
>>
>> +if (reset) {
>> +/* New SCSI EH run, reset gate variable */
>> +sdkp->medium_access_reset = 0;
>> +return eh_disp;
>> +}
>>  if (!scsi_device_online(scmd->device) ||
>>  !scsi_medium_access_command(scmd) ||
>>  host_byte(scmd->result) != DID_TIME_OUT ||
>> @@ -1714,7

Getting "Wrong diagnostic page; asked for 7 got 0" error message on HBA's virtual SES device

2017-03-13 Thread Sreekanth Reddy 
Hi,

Our LSI(Broadcom) SAS3.5 HBA device's support virtual SES device.

Whenever we load the mpt3sas driver then we are observing below error message,

"Wrong diagnostic page; asked for 7 got 0"

Our virtual SES device doesn't support Diagnostic page 7, it supports
only below diagnostic pages,

• 00h List of Supported Diagnostic Pages
• 01h SES Configuration Diagnostic Page
• 02h SES Enclosure Control/Enclosure Status Diagnostic Page
• 0Ah SES Additional Element Status Diagnostic Page

Page Code 07 is Element Descriptor Diagnostic Page
Per SES3 spec (see table 10) this page is optional and not supported
by our internal VSES.

But 'ses' kernel module is issuing a RECEIVE_DIAGNOSTIC command for
diagnostic page 7 without checking whether target device supports this
page or not (i.e. without looking into 00h page) as shown below,

result = ses_recv_diag(sdev, 7, hdr_buf, INIT_ALLOC_SIZE);
if (result)
goto simple_populate;

As the virtual SES devices doesn't support this page 7, so it has
failed this RECEIVE_DIAGNOSTIC command with illegal request sense key
as shown below,

ses 11:0:0:0: tag#0 Send: scmd 0x883fee898000
ses 11:0:0:0: tag#0 CDB: Receive Diagnostic 1c 01 07 00 20 00
ses 11:0:0:0: tag#0 CDB: Receive Diagnostic 1c 01 07 00 20 00
mpt3sas_cm1:sas_address(0x510600b012345600), phy(16)
mpt3sas_cm1:enclosure_logical_id(0x500605b012345600),slot(16)
mpt3sas_cm1:enclosure level(0x), connector name( )
mpt3sas_cm1:handle(0x0011), ioc_status(success)(0x), smid(1)
mpt3sas_cm1:request_len(32), underflow(0), resid(32)
mpt3sas_cm1:tag(0), transfer_count(0), sc->result(0x0002)
mpt3sas_cm1:scsi_status(check condition)(0x02),
scsi_state(autosense valid )(0x01)
mpt3sas_cm1:[sense_key,asc,ascq]: [0x05,0x26,0x00], count(18)
mpt3sas_cm1: log_info(0x31200205): originator(PL), code(0x20), sub_code(0x0205)
ses 11:0:0:0: tag#0 Done: SUCCESS Result: hostbyte=DID_TARGET_FAILURE
driverbyte=DRIVER_OK
ses 11:0:0:0: tag#0 CDB: Receive Diagnostic 1c 01 07 00 20 00
ses 11:0:0:0: tag#0 Sense Key : Illegal Request [current]
ses 11:0:0:0: tag#0 Add. Sense: Invalid field in parameter list
ses 11:0:0:0: tag#0 scsi host busy 1 failed 0
ses 11:0:0:0: Notifying upper driver of completion (result 812)
ses 11:0:0:0: tag#0 0 sectors total, 32 bytes done.
ses 11:0:0:0: Wrong diagnostic page; asked for 7 got 0

As the command is failed with illegal request sense key, so the buffer
used In function 'ses_recv_diag' will be not updated and so it will
have all zero's. so the page_code will be zero and we observe below
wrong error message even though vSES device has failed the command
with illegal request error message and it has not returned any wrong
diagnostic page.

sdev_printk(KERN_ERR, sdev,
"Wrong diagnostic page; asked for %d got %u\n",
page_code, recv_page_code);

Thanks,
Sreekanth