Re: [PATCHv2 3/5] scsi: Move user-shareable stuff in scsi/scsi.h to uapi/linux/scsi.h

2015-02-02 Thread Christoph Hellwig
On Thu, Jan 29, 2015 at 05:24:13PM -0800, James Bottomley wrote:
> I think this is too much: lots of things in scsi.h have no meaning to
> the user: our internal definition of scsi_lun for instance, internal
> return codes, mid level queue instructions, our internal markers for
> SCSI levels ...
> 
> What you put in this file becomes a contract for userspace.  The rule
> should be don't put anything in unless we want the user to use it (and
> we're willing to stick by it).
> 
> I really think that nothing that isn't already
> in /usr/include/scsi/scsi.h is a great rule to follow and then, if
> necessary, justify why any additional stuff.

I think basically nothing in scsi.h needs to be exposed to userspace,
only the ioctl defintions moved to scsi_ioctl.h earlier should.  While
userspace can use SCSI opcodes and status codes they are not a kernel
ABI, but a protocol defintion.  It isn't really the kernels job
to export those, epecially as protocols evolve with new versions.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/8] vhost/scsi: Add ANY_LAYOUT support

2015-02-02 Thread Christoph Hellwig
Hi Nic,

Al has been rewriting the vhost code to use iov_iter primitives,
can you please rebase it on top of that istead of using the obsolete
infrastructure?

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: block layer copying user io vectors

2015-02-02 Thread Christoph Hellwig
On Fri, Jan 30, 2015 at 05:43:04PM +, Andy Falanga (afalanga) wrote:
> > > This function does something that seems rather strange.  On line 859,
> > > a for loop determines the number of pages needed for the copying of
> > > the user data to kernel space.  Then the memory is allocated (line
> > > 886 bio_kmalloc()).  Then, strangely, on line 895, there is this
> > > conditional:
> > 
> > This is because the function can also be used with preallocated pages,
> > a feature only used by the sg and tape drivers.
> > 
> > Make sure your user memory is 4k aligned, and you should be able to
> > avoid the copy entirely (1).
> 
> Where is this 4k alignment being enforced?  When sg_start_req calls to
> blk_rq_map_user_iov, the only check for alignment is that the data buffers
> are 4-byte aligned (q->dma_alignment == 3).  I have verified that they are.

Indeed, I though we had the more strict direct I/O alignment.

Still doesn't help because the sg driver refuses to directly map user
pages for vectored I/O.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v1] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Suman Tripathi
This patch addresses the issue with ATA_CMD_SMART pio mode
command for enumeration and device detection with ATA devices.
The X-Gene AHCI controller has an errata in which it cannot clear
the BSY bit after the PIO setup FIS. The dma state machine enters
CMFatalErrorUpdate state and locks up. It is the same issue as
in the patch(Commit ID : 2a0bdff6b958d1b2523d2754b6cd5e0ea4053016).

Signed-off-by: Suman Tripathi 
---
---
 drivers/ata/ahci_xgene.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 7f68875..506cf5f 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -211,7 +211,8 @@ static unsigned int xgene_ahci_qc_issue(struct 
ata_queued_cmd *qc)
}

if (unlikely((ctx->last_cmd[ap->port_no] == ATA_CMD_ID_ATA) ||
-   (ctx->last_cmd[ap->port_no] == ATA_CMD_PACKET)))
+   (ctx->last_cmd[ap->port_no] == ATA_CMD_PACKET) ||
+   (ctx->last_cmd[ap->port_no] == ATA_CMD_SMART)))
xgene_ahci_restart_engine(ap);

rc = ahci_qc_issue(qc);
--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v1] Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Suman Tripathi
v1 changes:
 * Update the commit id as per Tejun's comments.
 * Add a bit explanation.

Signed-off-by: Suman Tripathi 
---

Suman Tripathi (1):
  ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO
mode command.

 drivers/ata/ahci_xgene.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v1] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Sergei Shtylyov

Hello.

On 2/2/2015 1:18 PM, Suman Tripathi wrote:


This patch addresses the issue with ATA_CMD_SMART pio mode
command for enumeration and device detection with ATA devices.
The X-Gene AHCI controller has an errata in which it cannot clear
the BSY bit after the PIO setup FIS. The dma state machine enters
CMFatalErrorUpdate state and locks up. It is the same issue as
in the patch(Commit ID : 2a0bdff6b958d1b2523d2754b6cd5e0ea4053016).


   Just "in the commit 2a0bdff6b958d1b2523d2754b6cd5e0ea4053016". And you 
also need to specify the commit's summary line in parens.



Signed-off-by: Suman Tripathi 


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Kernel Ooops upon USB disconnect of a Western Digital My Passport 1TB drive

2015-02-02 Thread Athlion
Hello all.

On my Thunkpad T420i with 3.18.2 (possibly earlier as well but
definitely not 3.17.6), 3.18.3, 3.18.4 and 3.18.5 kernels, I can
reproduce the following behaviour 100% of the time:

1. Connect one of my (NTFS-formatted) WD 1TB 'My Passport' drives via USB.
2. Disconnect the cable.
3. Kernel Ooops.

Please note that the drive need not be mounted at all. In fact, this
even happens if I stop all graphical and automount services and
plug-in and then disconnect the cable. Also, other USB drives and USB
flash disks do not exhibit this behaviour... Go figure!

The oops as caught and reported by netconsole is the following:

[  169.827703] usb 2-1.2: new high-speed USB device number 3 using ehci-pci
[  169.980222] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[  169.982264] scsi host6: usb-storage 2-1.2:1.0
[  169.984548] usbcore: registered new interface driver usb-storage
[  169.989296] usbcore: registered new interface driver uas
[  170.989458] scsi 6:0:0:0: Direct-Access WD   My Passport
0748 1016 PQ: 0 ANSI: 6
[  170.992673] scsi 6:0:0:1: Enclosure WD   SES Device
  1016 PQ: 0 ANSI: 6
[  171.002766] sd 6:0:0:0: [sdb] Spinning up disk...
[  172.009278] .ready
[  173.012719] sd 6:0:0:0: [sdb] 1953458176 512-byte logical blocks:
(1.00 TB/931 GiB)
[  173.016434] sd 6:0:0:0: [sdb] Write Protect is off
[  173.017780] ses 6:0:0:1: Attached Enclosure device
[  173.021519] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
[  173.024736] sd 6:0:0:0: [sdb] No Caching mode page found
[  173.026785] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  173.040339]  sdb: sdb1
[  173.045652] sd 6:0:0:0: [sdb] Attached SCSI disk
[  183.706124] usb 2-1.2: USB disconnect, device number 3
[  183.725921] BUG: unable to handle kernel NULL pointer dereference
at 01a0
[  183.728560] IP: [] blk_post_runtime_resume+0x65/
0x80
[  183.730820] PGD 0
[  183.733038] Oops: 0002 [#1] PREEMPT SMP
[  183.735285] Modules linked in: ses enclosure uas usb_storage
netconsole joydev mousedev snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_codec_generic coretemp arc4 intel_rapl x86_pkg_temp_thermal
intel_powerclamp kvm_intel iwldvm kvm mac80211 crct10dif_pclmul
crc32_pclmul crc32c_intel iTCO_wdt iTCO_vendor_support
ghash_clmulni_intel aesni_intel iwlwifi aes_x86_64 lrw gf128mul
glue_helper ablk_helper cryptd psmouse serio_raw i2c_i801 cfg80211
ip6t_REJECT nf_reject_ipv6 thinkpad_acpi wmi nvram xt_hl rfkill
ip6t_rt hwmon battery ac snd_hda_intel tpm_tis snd_hda_controller tpm
snd_hda_codec snd_hwdep nf_conntrack_ipv6 snd_pcm nf_defrag_ipv6 evdev
snd_timer e1000e snd thermal mac_hid mei_me soundcore mei ptp
ipt_REJECT lpc_ich nf_reject_ipv4 pps_core shpchp processor xt_limit
xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack
ip6table_filter ip6_tables nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack
e1000e snd thermal mac_hid mei_me soundcore mei ptp ipt_REJECT lpc_ich
nf_reject_ipv4 pps_core shpchp processor xt_limit xt_tcpudp
xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack
ip6table_filter ip6_tables nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack
iptable_filter ip_tables x_tables sch_fq_codel vboxdrv(O) usbnet mii
tp_smapi(O) thinkpad_ec(O) nfs lockd grace sunrpc fscache
cpufreq_powersave acpi_call(O) ext4 crc16 mbcache jbd2 sd_mod atkbd
libps2 sdhci_pci sdhci led_class ahci libahci libata ehci_pci ehci_hcd
scsi_mod mmc_core usbcore usb_common i8042 serio i915 button intel_gtt
i2c_algo_bit video drm_kms_helper drm i2c_core
[  183.981709] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G UD O
3.18.5-1-ARCH #1
[  183.985915] Hardware name: LENOVO 4177CTO/4177CTO, BIOS 83ET70WW
(1.40 ) 06/12/2012
[  183.990082] task: 880212941e30 ti: 88021296c000 task.ti:
88021296c000
[  183.994203] RIP: 0010:[] []
kthread_data+0x10/0x20
[  183.998426] RSP: 0018:88021296f3e8  EFLAGS: 00010092
[  184.002645] RAX:  RBX:  RCX: 
[  184.006893] RDX: 000f RSI:  RDI: 880212941e30
[  184.011063] RBP: 88021296f3e8 R08:  R09: 880215803a00
[  184.015247] R10: 88021e216480 R11: ea000846fc40 R12: 88021e213640
[  184.019428] R13: 88021e213640 R14: 880212941e30 R15: 
[  184.023591] FS:  () GS:88021e20()
knlGS:
[  184.027820] CS:  0010 DS:  ES:  CR0: 80050033
[  184.032041] CR2: 0028 CR3: 01811000 CR4: 000407f0
[  184.036227] Stack:
[  184.040518]  88021296f408 8108c275 88021296f408

[  184.044910]  88021296f528 81550f55 880212941e30
00013640
[  184.235199]  [] ret_from_fork+0x7c/0xb0
[  184.237699]  [] ? kthread_create_on_node+0x1c0/0x1c0
[  184.240179] Code: 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01

What can I do

[PATCH v2] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Suman Tripathi
This patch addresses the issue with ATA_CMD_SMART pio mode
command for enumeration and device detection with ATA devices.
The X-Gene AHCI controller has an errata in which it cannot clear
the BSY bit after the PIO setup FIS. The dma state machine enters
CMFatalErrorUpdate state and locks up. It is the same issue as
in the commit 2a0bdff6b958d1b2523d2754b6cd5e0ea4053016(fix the
dma state machine lockup for the IDENTIFY DEVICE PIO mode
command).

For example :  without this patch it results in READ DMA command failure
as show below :

 [  126.700072] ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x6 frozen
 [  126.707089] ata2.00: failed command: READ DMA
 [  126.711426] ata2.00: cmd c8/00:08:00:55:57/00:00:00:00:00/e1 tag 1
dma 4096 in
 [  126.711426]  res 40/00:ff:00:00:00/00:00:00:00:00/40 Emask
0x4 (timeout)
 [  126.725956] ata2.00: status: { DRDY }

Signed-off-by: Suman Tripathi 
Reported-by:   Mark Langsdorf 
---
---
 drivers/ata/ahci_xgene.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 7f68875..506cf5f 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -211,7 +211,8 @@ static unsigned int xgene_ahci_qc_issue(struct 
ata_queued_cmd *qc)
}

if (unlikely((ctx->last_cmd[ap->port_no] == ATA_CMD_ID_ATA) ||
-   (ctx->last_cmd[ap->port_no] == ATA_CMD_PACKET)))
+   (ctx->last_cmd[ap->port_no] == ATA_CMD_PACKET) ||
+   (ctx->last_cmd[ap->port_no] == ATA_CMD_SMART)))
xgene_ahci_restart_engine(ap);

rc = ahci_qc_issue(qc);
--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Suman Tripathi
v1 changes:
 * Update the commit id as per Tejun's comments.
 * Add a bit explanation.

v2 changes:
 * Update the comments from sergei.

Signed-off-by: Suman Tripathi 
---

Suman Tripathi (1):
  ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO
mode command.

 drivers/ata/ahci_xgene.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3] scsi: serialize ->rescan against ->remove

2015-02-02 Thread Christoph Hellwig
On Fri, Jan 30, 2015 at 10:46:17AM +0100, Paolo Bonzini wrote:
> Great, we might want to revert that patch in 3.21.

Is that fix in any tree yet?  Seems like I missed it for the scsi
tree at least.  So unless you want it for 3.19/stable we might as well
ust skip that patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/3] scsi: serialize ->rescan against ->remove

2015-02-02 Thread Christoph Hellwig
Lock the device embedded in the scsi_device to protect against
concurrent calls to ->remove.

Signed-off-by: Christoph Hellwig 
Acked-by: Alan Stern 
---
 drivers/scsi/scsi_scan.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 983aed1..523faee 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1593,16 +1593,15 @@ EXPORT_SYMBOL(scsi_add_device);
 
 void scsi_rescan_device(struct device *dev)
 {
-   if (!dev->driver)
-   return;
-
-   if (try_module_get(dev->driver->owner)) {
+   device_lock(dev);
+   if (dev->driver && try_module_get(dev->driver->owner)) {
struct scsi_driver *drv = to_scsi_driver(dev->driver);
 
if (drv->rescan)
drv->rescan(dev);
module_put(dev->driver->owner);
}
+   device_unlock(dev);
 }
 EXPORT_SYMBOL(scsi_rescan_device);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/3] sd: don't grab a device references from driver methods

2015-02-02 Thread Christoph Hellwig
The device model already takes care of races between ->remove and
->shutdown vs its other methods, and we now take care about locking
them out for ->rescan as well.

This is a partial revert of commit 39b7f1 ("[SCSI] sd: Fix refcounting").

Signed-off-by: Christoph Hellwig 
---
 drivers/scsi/sd.c | 55 +++
 1 file changed, 11 insertions(+), 44 deletions(-)

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 3995169..1f06274 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -564,10 +564,12 @@ static int sd_major(int major_idx)
}
 }
 
-static struct scsi_disk *__scsi_disk_get(struct gendisk *disk)
+static struct scsi_disk *scsi_disk_get(struct gendisk *disk)
 {
struct scsi_disk *sdkp = NULL;
 
+   mutex_lock(&sd_ref_mutex);
+
if (disk->private_data) {
sdkp = scsi_disk(disk);
if (scsi_device_get(sdkp->device) == 0)
@@ -575,27 +577,6 @@ static struct scsi_disk *__scsi_disk_get(struct gendisk 
*disk)
else
sdkp = NULL;
}
-   return sdkp;
-}
-
-static struct scsi_disk *scsi_disk_get(struct gendisk *disk)
-{
-   struct scsi_disk *sdkp;
-
-   mutex_lock(&sd_ref_mutex);
-   sdkp = __scsi_disk_get(disk);
-   mutex_unlock(&sd_ref_mutex);
-   return sdkp;
-}
-
-static struct scsi_disk *scsi_disk_get_from_dev(struct device *dev)
-{
-   struct scsi_disk *sdkp;
-
-   mutex_lock(&sd_ref_mutex);
-   sdkp = dev_get_drvdata(dev);
-   if (sdkp)
-   sdkp = __scsi_disk_get(sdkp->disk);
mutex_unlock(&sd_ref_mutex);
return sdkp;
 }
@@ -610,8 +591,6 @@ static void scsi_disk_put(struct scsi_disk *sdkp)
mutex_unlock(&sd_ref_mutex);
 }
 
-
-
 static unsigned char sd_setup_protect_cmnd(struct scsi_cmnd *scmd,
   unsigned int dix, unsigned int dif)
 {
@@ -1525,12 +1504,9 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
 
 static void sd_rescan(struct device *dev)
 {
-   struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
+   struct scsi_disk *sdkp = dev_get_drvdata(dev);
 
-   if (sdkp) {
-   revalidate_disk(sdkp->disk);
-   scsi_disk_put(sdkp);
-   }
+   revalidate_disk(sdkp->disk);
 }
 
 
@@ -3147,13 +3123,13 @@ static int sd_start_stop_device(struct scsi_disk *sdkp, 
int start)
  */
 static void sd_shutdown(struct device *dev)
 {
-   struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
+   struct scsi_disk *sdkp = dev_get_drvdata(dev);
 
if (!sdkp)
return; /* this can happen */
 
if (pm_runtime_suspended(dev))
-   goto exit;
+   return;
 
if (sdkp->WCE && sdkp->media_present) {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
@@ -3164,14 +3140,11 @@ static void sd_shutdown(struct device *dev)
sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n");
sd_start_stop_device(sdkp, 0);
}
-
-exit:
-   scsi_disk_put(sdkp);
 }
 
 static int sd_suspend_common(struct device *dev, bool ignore_stop_errors)
 {
-   struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
+   struct scsi_disk *sdkp = dev_get_drvdata(dev);
int ret = 0;
 
if (!sdkp)
@@ -3197,7 +3170,6 @@ static int sd_suspend_common(struct device *dev, bool 
ignore_stop_errors)
}
 
 done:
-   scsi_disk_put(sdkp);
return ret;
 }
 
@@ -3213,18 +3185,13 @@ static int sd_suspend_runtime(struct device *dev)
 
 static int sd_resume(struct device *dev)
 {
-   struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
-   int ret = 0;
+   struct scsi_disk *sdkp = dev_get_drvdata(dev);
 
if (!sdkp->device->manage_start_stop)
-   goto done;
+   return 0;
 
sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
-   ret = sd_start_stop_device(sdkp, 1);
-
-done:
-   scsi_disk_put(sdkp);
-   return ret;
+   return sd_start_stop_device(sdkp, 1);
 }
 
 /**
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/3] scsi: proper state checking and module refcount handling in scsi_device_get

2015-02-02 Thread Christoph Hellwig
This effectively reverts commits 85b6c7 ("[SCSI] sd: fix cache flushing on
module removal (and individual device removal)" and dc4515ea ("scsi: always
increment reference count").

We now never call scsi_device_get from the shutdown path, and the fact
that we started grabbing reference there in commit 85b6c7 turned out
turned out to create more problems than it solves, and required
workarounds for workarounds for workarounds. Move back to properly checking
the device state and carefully handle module refcounting.

Signed-off-by: Christoph Hellwig 
---
 drivers/scsi/scsi.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 9b38299..9b7fd0b 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -979,18 +979,24 @@ EXPORT_SYMBOL(scsi_report_opcode);
  * Description: Gets a reference to the scsi_device and increments the use 
count
  * of the underlying LLDD module.  You must hold host_lock of the
  * parent Scsi_Host or already have a reference when calling this.
+ *
+ * This will fail if a device is deleted or cancelled, or when the LLD module
+ * is in the process of being unloaded.
  */
 int scsi_device_get(struct scsi_device *sdev)
 {
-   if (sdev->sdev_state == SDEV_DEL)
-   return -ENXIO;
+   if (sdev->sdev_state == SDEV_DEL || sdev->sdev_state == SDEV_CANCEL)
+   goto fail;
if (!get_device(&sdev->sdev_gendev))
-   return -ENXIO;
-   /* We can fail try_module_get if we're doing SCSI operations
-* from module exit (like cache flush) */
-   __module_get(sdev->host->hostt->module);
-
+   goto fail;
+   if (!try_module_get(sdev->host->hostt->module))
+   goto fail_put_device;
return 0;
+
+fail_put_device:
+   put_device(&sdev->sdev_gendev);
+fail:
+   return -ENXIO;
 }
 EXPORT_SYMBOL(scsi_device_get);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3] scsi: serialize ->rescan against ->remove

2015-02-02 Thread Paolo Bonzini


On 02/02/2015 13:59, Christoph Hellwig wrote:
> On Fri, Jan 30, 2015 at 10:46:17AM +0100, Paolo Bonzini wrote:
>> > Great, we might want to revert that patch in 3.21.
> Is that fix in any tree yet?  Seems like I missed it for the scsi
> tree at least.  So unless you want it for 3.19/stable we might as well
> ust skip that patch.

Yes, I agree.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


sequential I/O on SSD disk varies from 20 to 300 MBytes/s every week

2015-02-02 Thread Siim Vahtre

Hello,

I have an extremely odd situation when the I/O speed changes for both SATA 
and SSD disks every few days or weeks with no apparent reason.


The servers have clean base install with nothing but SSH running and the 
test I am doing is the following:


# dd if=/dev/zero of=/dev/sda4 bs=1M count=10240 conv=fsync

And the results are:
1) 3.5Mbytes/s - 120Mbytes/s for SATA disks
2) 20Mbytes/s - 300Mbytes/s for SSD disks


Note that:

1) for every disk, the speed (either slow or fast) is usually consistent 
2-14 days, and then it randomly changes.


2) One disk speed does not correlate with the speeds of other disks in the 
same server - one can be 100Mbyte/s while other is 10Mbytes/s) and month 
later it might be vice-versa.


3) I have not yet discovered anything that triggers the change of speed. 
Seemingly it is just random: on week 1 the speed is ~70-80Mbytes/s, and 
then on week two it goes to 20Mbytes/s, and then few days later goes to 
90Mbyte/s. But the speed (slow or fast) is consistent for a longer period 
of time - it does not usually change in matter of hours.


4) Speed is slow for reads as well, but the difference is a bit less 
dramatic. (eg. 400Mbytes/s vs 500Mbytes/s).


5) The random I/O speed also changes, but as it is easier to test.


During the testing period of about 5 months I have concluded:

1) There are 3 identical Fujitsu RX200 S6 test servers which all show the 
same problem, but I also reproduced it on some Sun Fire and Dell server.


2) The problem happens with both HW RAID (MegaRAID SAS 2108) and when 
disks were directly on integrated SATA card.


3) The problem happens with different Kernel versions (tried 3.14, 3.16, 
3.18)


4) The problem happens with newest FW/BIOS versions and on older version

5) I have checked/replaced the cabling.

6) It is not a caching issue (controller/disk caches were off during 
testing, but even putting them on had minor impact on the results)


7) The problem happens with both 2.5" SATA (12 x HGST Travelstar 1TB, 3 x 
WD Black 750G), and SSD disks (3 x Samsung Pro 840)


8) I have NOT been able to reproduce it on Windows - the speeds have been 
good for all disks at all times.


9) Changing the disks (eg. taking currently slow disk and putting it to 
another server) has mixed results - it usually triggers some change of 
speed (slow becomes fast or vice-versa) but not always.



The only thing that somewhat correlates with the change of speed is the 
environment: the IO speed of disks is generally better when testing in the 
office vs if that exact same server is in the server room. It might just 
been luck, however.


I did not find correlation with the uptime, restarts, change of 
temperature, etc, so I assumed it might be the vibrations/rotations for 
SATA disks, but now that I have reproduced it with expensive SSD disks as 
well, I am out of ideas.


Only 20Mbytes/s on SSD must be wrong, right? (Especially if week earlier 
or week later it is ~300MBytes/s).


Any comments would be highly appreciated.

--
Siim Vahtre
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: sequential I/O on SSD disk varies from 20 to 300 MBytes/s every week

2015-02-02 Thread Suman Tripathi
Hi,

I have an extremely odd situation when the I/O speed changes for both
SATA and SSD disks every few days or weeks with no apparent reason.

The servers have clean base install with nothing but SSH running and
the test I am doing is the following:

# dd if=/dev/zero of=/dev/sda4 bs=1M count=10240 conv=fsync

And the results are:
1) 3.5Mbytes/s - 120Mbytes/s for SATA disks
2) 20Mbytes/s - 300Mbytes/s for SSD disks

The previous reply failed to deliver as plaintext mode was not.
Please check whether write cache is enabled in the drive . This can be
checked from the logs during bootup and also check whether NCQ is
enabled or not.

you can enable write cache by :

hdparm -W 1 /dev/

On Mon, Feb 2, 2015 at 6:37 PM, Siim Vahtre  wrote:
> Hello,
>
> I have an extremely odd situation when the I/O speed changes for both SATA
> and SSD disks every few days or weeks with no apparent reason.
>
> The servers have clean base install with nothing but SSH running and the
> test I am doing is the following:
>
> # dd if=/dev/zero of=/dev/sda4 bs=1M count=10240 conv=fsync
>
> And the results are:
> 1) 3.5Mbytes/s - 120Mbytes/s for SATA disks
> 2) 20Mbytes/s - 300Mbytes/s for SSD disks
>
>
> Note that:
>
> 1) for every disk, the speed (either slow or fast) is usually consistent
> 2-14 days, and then it randomly changes.
>
> 2) One disk speed does not correlate with the speeds of other disks in the
> same server - one can be 100Mbyte/s while other is 10Mbytes/s) and month
> later it might be vice-versa.
>
> 3) I have not yet discovered anything that triggers the change of speed.
> Seemingly it is just random: on week 1 the speed is ~70-80Mbytes/s, and then
> on week two it goes to 20Mbytes/s, and then few days later goes to
> 90Mbyte/s. But the speed (slow or fast) is consistent for a longer period of
> time - it does not usually change in matter of hours.
>
> 4) Speed is slow for reads as well, but the difference is a bit less
> dramatic. (eg. 400Mbytes/s vs 500Mbytes/s).
>
> 5) The random I/O speed also changes, but as it is easier to test.
>
>
> During the testing period of about 5 months I have concluded:
>
> 1) There are 3 identical Fujitsu RX200 S6 test servers which all show the
> same problem, but I also reproduced it on some Sun Fire and Dell server.
>
> 2) The problem happens with both HW RAID (MegaRAID SAS 2108) and when disks
> were directly on integrated SATA card.
>
> 3) The problem happens with different Kernel versions (tried 3.14, 3.16,
> 3.18)
>
> 4) The problem happens with newest FW/BIOS versions and on older version
>
> 5) I have checked/replaced the cabling.
>
> 6) It is not a caching issue (controller/disk caches were off during
> testing, but even putting them on had minor impact on the results)
>
> 7) The problem happens with both 2.5" SATA (12 x HGST Travelstar 1TB, 3 x WD
> Black 750G), and SSD disks (3 x Samsung Pro 840)
>
> 8) I have NOT been able to reproduce it on Windows - the speeds have been
> good for all disks at all times.
>
> 9) Changing the disks (eg. taking currently slow disk and putting it to
> another server) has mixed results - it usually triggers some change of speed
> (slow becomes fast or vice-versa) but not always.
>
>
> The only thing that somewhat correlates with the change of speed is the
> environment: the IO speed of disks is generally better when testing in the
> office vs if that exact same server is in the server room. It might just
> been luck, however.
>
> I did not find correlation with the uptime, restarts, change of temperature,
> etc, so I assumed it might be the vibrations/rotations for SATA disks, but
> now that I have reproduced it with expensive SSD disks as well, I am out of
> ideas.
>
> Only 20Mbytes/s on SSD must be wrong, right? (Especially if week earlier or
> week later it is ~300MBytes/s).
>
> Any comments would be highly appreciated.
>
> --
> Siim Vahtre
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,
with regards,
Suman Tripathi
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: sequential I/O on SSD disk varies from 20 to 300 MBytes/s every week

2015-02-02 Thread Siim Vahtre

Please check whether write cache is enabled in the drive
also check whether NCQ is enabled or not.


About caches please note quote from my e-mail below. Changing NCQ 
enabled/disabled had no effect either.


6) It is not a caching issue (controller/disk caches were off during 
testing, but even putting them on had minor impact on the results)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v1] Revert "scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE) support for UFS"

2015-02-02 Thread Yaniv Gardi
This reverts commit 54acb89a8d8682d99ee8594f9ce0dd863a2df80d.

Since ICE driver hasn't been uploaded to upstream, ICE support for
UFS driver could not be functional at this time.
Therefore this change should be reverted.
---
 drivers/scsi/ufs/Kconfig|  12 -
 drivers/scsi/ufs/Makefile   |   1 -
 drivers/scsi/ufs/ufs-qcom-ice.c | 520 
 drivers/scsi/ufs/ufs-qcom-ice.h | 113 -
 drivers/scsi/ufs/ufs-qcom.c |  56 +
 drivers/scsi/ufs/ufs-qcom.h |  25 --
 6 files changed, 1 insertion(+), 726 deletions(-)
 delete mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c
 delete mode 100644 drivers/scsi/ufs/ufs-qcom-ice.h

diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index ecf34ed..8a1f4b3 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,15 +83,3 @@ config SCSI_UFS_QCOM
 
  Select this if you have UFS controller on QCOM chipset.
  If unsure, say N.
-
-config SCSI_UFS_QCOM_ICE
-   bool "QCOM specific hooks to Inline Crypto Engine for UFS driver"
-   depends on SCSI_UFS_QCOM && CRYPTO_DEV_QCOM_ICE
-   help
- This selects the QCOM specific additions to support Inline Crypto
- Engine (ICE).
- ICE accelerates the crypto operations and maintains the high UFS
- performance.
-
- Select this if you have ICE supported for UFS on QCOM chipset.
- If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 31adca5..8303bcc 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,6 +1,5 @@
 # UFSHCD makefile
 obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
-obj-$(CONFIG_SCSI_UFS_QCOM_ICE) += ufs-qcom-ice.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
 obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
 obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufs-qcom-ice.c b/drivers/scsi/ufs/ufs-qcom-ice.c
deleted file mode 100644
index 9202b73..000
--- a/drivers/scsi/ufs/ufs-qcom-ice.c
+++ /dev/null
@@ -1,520 +0,0 @@
-/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include "ufs-qcom-ice.h"
-#include "ufshcd.h"
-
-#define UFS_QCOM_CRYPTO_LABEL "ufs-qcom-crypto"
-/* Timeout waiting for ICE initialization, that requires TZ access */
-#define UFS_QCOM_ICE_COMPLETION_TIMEOUT_MS 500
-
-static void ufs_qcom_ice_success_cb(void *host_ctrl,
-   enum ice_event_completion evt)
-{
-   struct ufs_qcom_host *qcom_host = (struct ufs_qcom_host *)host_ctrl;
-
-   if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_DISABLED &&
-   evt == ICE_INIT_COMPLETION)
-   qcom_host->ice.state = UFS_QCOM_ICE_STATE_ACTIVE;
-else if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_SUSPENDED &&
-  evt == ICE_RESUME_COMPLETION)
-   qcom_host->ice.state = UFS_QCOM_ICE_STATE_ACTIVE;
-
-   complete(&qcom_host->ice.async_done);
-}
-
-static void ufs_qcom_ice_error_cb(void *host_ctrl, enum ice_error_code evt)
-{
-   struct ufs_qcom_host *qcom_host = (struct ufs_qcom_host *)host_ctrl;
-
-   dev_err(qcom_host->hba->dev, "%s: Error in ice operation %d",
-   __func__, evt);
-
-   if (qcom_host->ice.state == UFS_QCOM_ICE_STATE_ACTIVE)
-   qcom_host->ice.state = UFS_QCOM_ICE_STATE_DISABLED;
-
-   complete(&qcom_host->ice.async_done);
-}
-
-static struct platform_device *ufs_qcom_ice_get_pdevice(struct device *ufs_dev)
-{
-   struct device_node *node;
-   struct platform_device *ice_pdev = NULL;
-
-   node = of_parse_phandle(ufs_dev->of_node, UFS_QCOM_CRYPTO_LABEL, 0);
-
-   if (!node) {
-   dev_err(ufs_dev, "%s: ufs-qcom-crypto property not specified\n",
-   __func__);
-   goto out;
-   }
-
-   ice_pdev = qcom_ice_get_pdevice(node);
-out:
-   return ice_pdev;
-}
-
-static
-struct qcom_ice_variant_ops *ufs_qcom_ice_get_vops(struct device *ufs_dev)
-{
-   struct qcom_ice_variant_ops *ice_vops = NULL;
-   struct device_node *node;
-
-   node = of_parse_phandle(ufs_dev->of_node, UFS_QCOM_CRYPTO_LABEL, 0);
-
-   if (!node) {
-   dev_err(ufs_dev, "%s: ufs-qcom-crypto property not specified\n",
-   __func__);
-   goto out;
-   }
-
-   ice_vops = qcom_ice_get_variant_ops(node);
-
-   if (!ice_vops)
-   dev_err(ufs_dev, "%s: inv

Re: [PATCH v7 5/5] scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE) support for UFS

2015-02-02 Thread ygardi
Paul,

we have decided to revert the ICE change that support UFS.
a change already uploaded:
look for subject:

[PATCH v1] Revert "scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE)
support for UFS"

thanks,
Yaniv

> Yaniv,
>
> On Thu, 2015-01-15 at 16:32 +0200, Yaniv Gardi wrote:
>> From: Yaniv Gardi 
>>
>> In-order to enhance storage encryption performance,
>> an Inline Cryptographic Engine is introduced to UFS.
>> This patch adds in-line encryption capabilities to the UFS
>> driver.
>>
>> Signed-off-by: Yaniv Gardi 
>
> This patch became commit 8805ccd069b7 ("ufs-qcom-ice: add Inline Crypto
> Engine (ICE) support for UFS") in today's linux-next (ie,
> next-20150123). I noticed because a script I use to check linux-next
> spotted a problem with it.
>
>> ---
>>  drivers/scsi/ufs/Kconfig|  12 +
>>  drivers/scsi/ufs/Makefile   |   1 +
>>  drivers/scsi/ufs/ufs-qcom-ice.c | 520
>> 
>>  drivers/scsi/ufs/ufs-qcom-ice.h | 113 +
>>  drivers/scsi/ufs/ufs-qcom.c |  56 -
>>  drivers/scsi/ufs/ufs-qcom.h |  25 ++
>>  6 files changed, 726 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c
>>  create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.h
>>
>> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
>> index 8a1f4b3..ecf34ed 100644
>> --- a/drivers/scsi/ufs/Kconfig
>> +++ b/drivers/scsi/ufs/Kconfig
>> @@ -83,3 +83,15 @@ config SCSI_UFS_QCOM
>>
>>Select this if you have UFS controller on QCOM chipset.
>>If unsure, say N.
>> +
>> +config SCSI_UFS_QCOM_ICE
>> +bool "QCOM specific hooks to Inline Crypto Engine for UFS driver"
>> +depends on SCSI_UFS_QCOM && CRYPTO_DEV_QCOM_ICE
>
> There's currently no Kconfig symbol CRYPTO_DEV_QCOM_ICE in linux-next.
> So SCSI_UFS_QCOM_ICE can not be set and these "in-line encryption
> capabilities" can not be enabled.
>
>> +help
>> +  This selects the QCOM specific additions to support Inline Crypto
>> +  Engine (ICE).
>> +  ICE accelerates the crypto operations and maintains the high UFS
>> +  performance.
>> +
>> +  Select this if you have ICE supported for UFS on QCOM chipset.
>> +  If unsure, say N.
>> diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
>> index 8303bcc..31adca5 100644
>> --- a/drivers/scsi/ufs/Makefile
>> +++ b/drivers/scsi/ufs/Makefile
>> @@ -1,5 +1,6 @@
>>  # UFSHCD makefile
>>  obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
>> +obj-$(CONFIG_SCSI_UFS_QCOM_ICE) += ufs-qcom-ice.o
>>  obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
>>  obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
>>  obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
>> diff --git a/drivers/scsi/ufs/ufs-qcom-ice.c
>> b/drivers/scsi/ufs/ufs-qcom-ice.c
>> new file mode 100644
>> index 000..9202b73
>> --- /dev/null
>> +++ b/drivers/scsi/ufs/ufs-qcom-ice.c
>> @@ -0,0 +1,520 @@
>> +/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> This header is not included in linux-next so manually building
> ufs-qcom-ice.o isn't possible either.
>
> I assume a series to add CRYPTO_DEV_QCOM_ICE and crypto/ice.h (and
> whatever else is needed to build this) is queued somewhere. Is that
> correct?
>
>
> Paul Bolle
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] st: implement sysfs based tape statistics v2

2015-02-02 Thread Laurence Oberman
I pulled this this morning and will be testing. The prior version was
stable for me on the upstream and RHEL 6.5 kernel without exhaustive
testing.
We also just received more requests to get this into RHEL from HP /
Red Hat customers.

Kai, what are your thoughts. I realize this is a large amount of
additional code. I am not keen to create a driver just for stats as we
would have to keep the rest of the st driver changes always in sync.

Thanks
Laurence

On Mon, Jan 12, 2015 at 10:43 PM, Seymour, Shane M  wrote:
> Some small changes since the last version - this version removes two files 
> from sysfs compared to the last version (read and write block counts since 
> they're derived from the byte counts they can be calculated in user space) 
> but that's the only change. This version has been rebased to 
> 3.19.0-rc3-next-20150108.
>
> Since posting the last version an email was received by Kai and myself from 
> an AT&T employee who has a need for tape statistics to be implemented (who 
> gave permission to quote their email), I've included part of the email here:
>
> "There are over 20,000 tape devices managed by our operations group zoned to 
> tens of thousands of servers.
>
> My challenge is that I cannot provide operations a solution that gives them 
> visibility into the tape drive performance metrics when that platform is 
> linux. Our legacy platforms (Solaris,HPUX,AIX) provide facilities to use 
> iostat and sar to determine the write speed of the tape drives. We took for 
> granted that this would be available in linux and its absence has been very 
> troublesome. Because operations cannot measure tape drive performance in this 
> way they cannot easily determine when there is a tape drive performance 
> problem and whether the change improved or worsened the performance problem.
> ...
> I have followed the debate https://lkml.org/lkml/2013/3/20/696 and from a 
> service provide perspective we would expect the same maturity and 
> functionality that we have from the traditional unix platform in regards to 
> iostat/sar. This issue is important and urgent because tape drive performance 
> issues are common and I am unable to provide standards and processes to 
> identify and remediate these issues."
>
> Another HP customer has also requested the same functionality (but hasn't 
> given permission to be named), they own tape drives numbering in the 1000s 
> and also need the ability to investigate performance issues.
>
> Signed-off-by: shane.seym...@hp.com
> Tested-by: shane.seym...@hp.com
> ---
> diff -uprN a/drivers/scsi/st.c b/drivers/scsi/st.c
> --- a/drivers/scsi/st.c 2015-01-11 14:46:00.243814755 -0600
> +++ b/drivers/scsi/st.c 2015-01-12 13:54:52.549117333 -0600
> @@ -20,6 +20,7 @@
>  static const char *verstr = "20101219";
>
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -226,6 +227,20 @@ static DEFINE_SPINLOCK(st_index_lock);
>  static DEFINE_SPINLOCK(st_use_lock);
>  static DEFINE_IDR(st_index_idr);
>
> +static inline void st_stats_remove_files(struct scsi_tape *);
> +static inline void st_stats_create_files(struct scsi_tape *);
> +static ssize_t st_tape_attr_show(struct kobject *, struct attribute *, char 
> *);
> +static ssize_t st_tape_attr_store(struct kobject *, struct attribute *,
> +   const char *, size_t);
> +static void st_release_stats_kobj(struct kobject *);
> +static const struct sysfs_ops st_stats_sysfs_ops = {
> +   .show   = st_tape_attr_show,
> +   .store  = st_tape_attr_store,
> +};
> +static struct kobj_type st_stats_ktype = {
> +   .release = st_release_stats_kobj,
> +   .sysfs_ops = &st_stats_sysfs_ops,
> +};
>
>
>
>  #include "osst_detect.h"
> @@ -476,10 +491,22 @@ static void st_scsi_execute_end(struct r
> struct st_request *SRpnt = req->end_io_data;
> struct scsi_tape *STp = SRpnt->stp;
> struct bio *tmp;
> +   u64 ticks;
>
> STp->buffer->cmdstat.midlevel_result = SRpnt->result = req->errors;
> STp->buffer->cmdstat.residual = req->resid_len;
>
> +   if (STp->stats != NULL) {
> +   ticks = get_jiffies_64();
> +   STp->stats->in_flight--;
> +   ticks -= STp->stats->stamp;
> +   STp->stats->io_ticks += ticks;
> +   if (req->cmd[0] == WRITE_6)
> +   STp->stats->write_ticks += ticks;
> +   else if (req->cmd[0] == READ_6)
> +   STp->stats->read_ticks += ticks;
> +   }
> +
> tmp = SRpnt->bio;
> if (SRpnt->waiting)
> complete(SRpnt->waiting);
> @@ -496,6 +523,7 @@ static int st_scsi_execute(struct st_req
> struct rq_map_data *mdata = &SRpnt->stp->buffer->map_data;
> int err = 0;
> int write = (data_direction == DMA_TO_DEVICE);
> +   struct scsi_tape *STp = SRpnt->stp;
>
> req = blk_get_request(SRpnt->stp->device->request_queue, write,
>   GFP_KERNEL);
> @@ -516,6 +544,20 @@ static int s

Re: [PATCH] phy: qcom-ufs: export symbols needed by main drivers

2015-02-02 Thread James Bottomley
On Wed, 2015-01-28 at 17:18 +0100, Arnd Bergmann wrote:
> The qcom ufs phy support is split into three separate loadable
> modules, however none of the interfaces are exported, resulting
> in a link error:
> 
> ERROR: "ufs_qcom_phy_power_off" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_power_on" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_exit" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_generic_probe" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_init_vregulators" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_init_clks" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_calibrate" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_remove" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "get_ufs_qcom_phy" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_power_off" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_power_on" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_exit" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "ufs_qcom_phy_generic_probe" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_init_vregulators" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_init_clks" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_calibrate" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] 
> undefined!
> ERROR: "ufs_qcom_phy_remove" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "get_ufs_qcom_phy" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> 
> This exports all of the symbols that are provided by the base library
> module and used by the two driver modules.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: adaafaa393ef ("phy: qcom-ufs: add support for QUALCOMM Technologies 
> UFS PHY drivers")
> ---


Cc added for linux-scsi, since this is the origin of the problem.  How
important is bisectability in this?  It won't affect any non-embedded
user, since most don't build with UFS, so I can go either way on folding
or just applying as an extra patch.

James

> The broken patch is currently in the scsi tree, so if the phy maintainer
> thinks that my fix is correct, it should go there too.
> 
> An alternative approach would be to link all three phy-qcom-ufs source
> files into a single module.
> 
>  drivers/phy/phy-qcom-ufs.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
> index 44ee983d57fe..c8f8c2dac18c 100644
> --- a/drivers/phy/phy-qcom-ufs.c
> +++ b/drivers/phy/phy-qcom-ufs.c
> @@ -73,6 +73,7 @@ int ufs_qcom_phy_calibrate(struct ufs_qcom_phy 
> *ufs_qcom_phy,
>  out:
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_calibrate);
>  
>  struct phy *ufs_qcom_phy_generic_probe(struct platform_device *pdev,
>   struct ufs_qcom_phy *common_cfg,
> @@ -110,6 +111,7 @@ struct phy *ufs_qcom_phy_generic_probe(struct 
> platform_device *pdev,
>  out:
>   return generic_phy;
>  }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_generic_probe);
>  
>  /*
>   * This assumes the embedded phy structure inside generic_phy is of type
> @@ -121,6 +123,7 @@ struct ufs_qcom_phy *get_ufs_qcom_phy(struct phy 
> *generic_phy)
>  {
>   return (struct ufs_qcom_phy *)phy_get_drvdata(generic_phy);
>  }
> +EXPORT_SYMBOL_GPL(get_ufs_qcom_phy);
>  
>  static
>  int ufs_qcom_phy_base_init(struct platform_device *pdev,
> @@ -228,6 +231,7 @@ ufs_qcom_phy_init_clks(struct phy *generic_phy,
>  out:
>   return err;
>  }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_init_clks);
>  
>  int
>  ufs_qcom_phy_init_vregulators(struct phy *generic_phy,
> @@ -252,6 +256,7 @@ ufs_qcom_phy_init_vregulators(struct phy *generic_phy,
>  out:
>   return err;
>  }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_init_vregulators);
>  
>  static int __ufs_qcom_phy_init_vreg(struct phy *phy,
>   struct ufs_qcom_phy_vreg *vreg, const char *name, bool optional)
> @@ -443,6 +448,7 @@ out_disable_src:
>  out:
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_ref_clk);
>  
>  static
>  int ufs_qcom_phy_disable_vreg(struct phy *phy,
> @@ -485,6 +491,7 @@ void ufs_qcom_phy_disable_ref_clk(struct phy *generic_phy)
>   phy->is_ref_clk_enabled = false;
>   }
>  }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_ref_clk);
>  
>  #define UFS_REF_CLK_EN   (1 << 5)
>  
> @@ -523,16 +530,19 @@ static void ufs_qcom_phy_dev_ref_clk_ctrl(struct phy 
> *generic_phy, bool enable)
>   phy->is_dev_ref_clk_enabled = enable;
>   }
>  }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_dev_ref_clk_ctrl);
>  
>  void ufs_qcom_phy_enable_dev_ref_clk(struct phy *generic_phy)
>  {
>   ufs_qcom_phy_dev_ref_clk_ctrl(generic_phy, true);
>  }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_

Re: [PATCH] phy: qcom-ufs: export symbols needed by main drivers

2015-02-02 Thread h...@lst.de
On Mon, Feb 02, 2015 at 03:30:27PM +, James Bottomley wrote:
> Cc added for linux-scsi, since this is the origin of the problem.  How
> important is bisectability in this?  It won't affect any non-embedded
> user, since most don't build with UFS, so I can go either way on folding
> or just applying as an extra patch.

The CRYPTO_DEV_QCOM_ICE symbol was never defined in the scsi trees, and
would have needed something else from linux-next to even compile.  So I
don't think the revert is a problem at all, and I'll add it to the
scsi-for-3.20 branch ASAP.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Sergei Shtylyov

Hello.

On 02/02/2015 02:57 PM, Suman Tripathi wrote:


This patch addresses the issue with ATA_CMD_SMART pio mode
command for enumeration and device detection with ATA devices.
The X-Gene AHCI controller has an errata in which it cannot clear
the BSY bit after the PIO setup FIS. The dma state machine enters
CMFatalErrorUpdate state and locks up. It is the same issue as
in the commit 2a0bdff6b958d1b2523d2754b6cd5e0ea4053016(fix the


   You forgot a space before '('.


dma state machine lockup for the IDENTIFY DEVICE PIO mode
command).


   Actually, the summary is "ahci_xgene: fix the dma state machine lockup for 
the IDENTIFY DEVICE PIO mode command.", i.e. yours is missing a prefix.


[...]


Signed-off-by: Suman Tripathi 
Reported-by:   Mark Langsdorf 


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] IB/srp: Add 64-bit LUN support

2015-02-02 Thread Bart Van Assche
The largest LUN number that has been tested is 0xd2003fff.

Checked the following structure sizes with gdb:
* sizeof(struct srp_cmd) = 48
* sizeof(struct srp_tsk_mgmt) = 48
* sizeof(struct srp_aer_req) = 36

The ibmvscsi changes have been compile tested only (on a PPC system).

Signed-off-by: Bart Van Assche 
Cc: Sagi Grimberg 
Cc: Sebastian Parschauer 
Cc: Brian King 
Cc: Nathan Fontenot 
Cc: Tyrel Datwyler 
---
 drivers/infiniband/ulp/srp/ib_srp.c | 8 
 drivers/scsi/ibmvscsi/ibmvscsi.c| 6 +++---
 include/scsi/srp.h  | 7 ---
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
b/drivers/infiniband/ulp/srp/ib_srp.c
index 0747c05..e43cb86 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1841,7 +1841,7 @@ static void srp_process_aer_req(struct srp_rdma_ch *ch,
s32 delta = be32_to_cpu(req->req_lim_delta);
 
shost_printk(KERN_ERR, target->scsi_host, PFX
-"ignoring AER for LUN %llu\n", be64_to_cpu(req->lun));
+"ignoring AER for LUN %llu\n", scsilun_to_int(&req->lun));
 
if (srp_response_common(ch, delta, &rsp, sizeof(rsp)))
shost_printk(KERN_ERR, target->scsi_host, PFX
@@ -2033,7 +2033,7 @@ static int srp_queuecommand(struct Scsi_Host *shost, 
struct scsi_cmnd *scmnd)
memset(cmd, 0, sizeof *cmd);
 
cmd->opcode = SRP_CMD;
-   cmd->lun= cpu_to_be64((u64) scmnd->device->lun << 48);
+   int_to_scsilun(scmnd->device->lun, &cmd->lun);
cmd->tag= tag;
memcpy(cmd->cdb, scmnd->cmnd, scmnd->cmd_len);
 
@@ -2448,7 +2448,7 @@ static int srp_send_tsk_mgmt(struct srp_rdma_ch *ch, u64 
req_tag,
memset(tsk_mgmt, 0, sizeof *tsk_mgmt);
 
tsk_mgmt->opcode= SRP_TSK_MGMT;
-   tsk_mgmt->lun   = cpu_to_be64((u64) lun << 48);
+   int_to_scsilun(lun, &tsk_mgmt->lun);
tsk_mgmt->tag   = req_tag | SRP_TAG_TSK_MGMT;
tsk_mgmt->tsk_mgmt_func = func;
tsk_mgmt->task_tag  = req_tag;
@@ -3145,7 +3145,7 @@ static ssize_t srp_create_target(struct device *dev,
target_host->transportt  = ib_srp_transport_template;
target_host->max_channel = 0;
target_host->max_id  = 1;
-   target_host->max_lun = SRP_MAX_LUN;
+   target_host->max_lun = -1LL;
target_host->max_cmd_len = sizeof ((struct srp_cmd *) (void *) 0L)->cdb;
 
target = host_to_target(target_host);
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index acea5d6..6a41c36 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -1053,7 +1053,7 @@ static int ibmvscsi_queuecommand_lck(struct scsi_cmnd 
*cmnd,
memset(srp_cmd, 0x00, SRP_MAX_IU_LEN);
srp_cmd->opcode = SRP_CMD;
memcpy(srp_cmd->cdb, cmnd->cmnd, sizeof(srp_cmd->cdb));
-   srp_cmd->lun = cpu_to_be64(((u64)lun) << 48);
+   int_to_scsilun(lun, &srp_cmd->lun);
 
if (!map_data_for_srp_cmd(cmnd, evt_struct, srp_cmd, hostdata->dev)) {
if (!firmware_has_feature(FW_FEATURE_CMO))
@@ -1529,7 +1529,7 @@ static int ibmvscsi_eh_abort_handler(struct scsi_cmnd 
*cmd)
/* Set up an abort SRP command */
memset(tsk_mgmt, 0x00, sizeof(*tsk_mgmt));
tsk_mgmt->opcode = SRP_TSK_MGMT;
-   tsk_mgmt->lun = cpu_to_be64(((u64) lun) << 48);
+   int_to_scsilun(lun, &tsk_mgmt->lun);
tsk_mgmt->tsk_mgmt_func = SRP_TSK_ABORT_TASK;
tsk_mgmt->task_tag = (u64) found_evt;
 
@@ -1652,7 +1652,7 @@ static int ibmvscsi_eh_device_reset_handler(struct 
scsi_cmnd *cmd)
/* Set up a lun reset SRP command */
memset(tsk_mgmt, 0x00, sizeof(*tsk_mgmt));
tsk_mgmt->opcode = SRP_TSK_MGMT;
-   tsk_mgmt->lun = cpu_to_be64(((u64) lun) << 48);
+   int_to_scsilun(lun, &tsk_mgmt->lun);
tsk_mgmt->tsk_mgmt_func = SRP_TSK_LUN_RESET;
 
evt->sync_srp = &srp_rsp;
diff --git a/include/scsi/srp.h b/include/scsi/srp.h
index 1ae84db..5be834d 100644
--- a/include/scsi/srp.h
+++ b/include/scsi/srp.h
@@ -42,6 +42,7 @@
  */
 
 #include 
+#include 
 
 enum {
SRP_LOGIN_REQ   = 0x00,
@@ -179,7 +180,7 @@ struct srp_tsk_mgmt {
u8  reserved1[6];
u64 tag;
u8  reserved2[4];
-   __be64  lun __attribute__((packed));
+   struct scsi_lun lun;
u8  reserved3[2];
u8  tsk_mgmt_func;
u8  reserved4;
@@ -200,7 +201,7 @@ struct srp_cmd {
u8  data_in_desc_cnt;
u64 tag;
u8  reserved2[4];
-   __be64  lun __attribute__((packed));
+   struct scsi_lun lun;
u8  reserved3;
u8  task_attr;
u8  reserved4;
@@ -265,7 +266,7 @@ struct srp_aer_req {
__be32  req_lim

Re: [PATCH] phy: qcom-ufs: export symbols needed by main drivers

2015-02-02 Thread James Bottomley
On Mon, 2015-02-02 at 17:26 +0100, h...@lst.de wrote:
> On Mon, Feb 02, 2015 at 03:30:27PM +, James Bottomley wrote:
> > Cc added for linux-scsi, since this is the origin of the problem.  How
> > important is bisectability in this?  It won't affect any non-embedded
> > user, since most don't build with UFS, so I can go either way on folding
> > or just applying as an extra patch.
> 
> The CRYPTO_DEV_QCOM_ICE symbol was never defined in the scsi trees, and
> would have needed something else from linux-next to even compile.  So I
> don't think the revert is a problem at all, and I'll add it to the
> scsi-for-3.20 branch ASAP.

Actually, on the revert of 

scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE) support for UFS

Which isn't what this problem is (the exports still need adding), since
it's only in the misc tree, let's just drop the patches rather than
doing an add and revert.

James



[PATCH v3] Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Suman Tripathi
v1 changes:
 * Update the commit id as per Tejun's comments.
 * Add a bit explanation.

v2 changes:
 * Update the comments from sergei.

v3 changes:
 * More changes in comments.

Signed-off-by: Suman Tripathi 
---

Suman Tripathi (1):
  ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO
mode command.

 drivers/ata/ahci_xgene.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Suman Tripathi
This patch addresses the issue with ATA_CMD_SMART pio mode
command for enumeration and device detection with ATA devices.
The X-Gene AHCI controller has an errata in which it cannot clear
the BSY bit after the PIO setup FIS. The dma state machine enters
CMFatalErrorUpdate state and locks up. It is the same issue as
in the commit 2a0bdff6b958d1b2523d2754b6cd5e0ea4053016 (ahci-xgene:
fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode
command).

For example :  without this patch it results in READ DMA command failure
as shown below :

 [  126.700072] ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x6 frozen
 [  126.707089] ata2.00: failed command: READ DMA
 [  126.711426] ata2.00: cmd c8/00:08:00:55:57/00:00:00:00:00/e1 tag 1
dma 4096 in
 [  126.711426]  res 40/00:ff:00:00:00/00:00:00:00:00/40 Emask
0x4 (timeout)
 [  126.725956] ata2.00: status: { DRDY }

Signed-off-by: Suman Tripathi 
Reported-by:   Mark Langsdorf 
---
---
 drivers/ata/ahci_xgene.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 7f68875..506cf5f 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -211,7 +211,8 @@ static unsigned int xgene_ahci_qc_issue(struct 
ata_queued_cmd *qc)
}

if (unlikely((ctx->last_cmd[ap->port_no] == ATA_CMD_ID_ATA) ||
-   (ctx->last_cmd[ap->port_no] == ATA_CMD_PACKET)))
+   (ctx->last_cmd[ap->port_no] == ATA_CMD_PACKET) ||
+   (ctx->last_cmd[ap->port_no] == ATA_CMD_SMART)))
xgene_ahci_restart_engine(ap);

rc = ahci_qc_issue(qc);
--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Sergei Shtylyov

Hello.

On 02/02/2015 09:07 PM, Suman Tripathi wrote:


This patch addresses the issue with ATA_CMD_SMART pio mode
command for enumeration and device detection with ATA devices.
The X-Gene AHCI controller has an errata in which it cannot clear
the BSY bit after the PIO setup FIS. The dma state machine enters


   Hum, if this happens after every PIO command (PIO setup FISes are not 
specific to the command, right?), perhaps it would make more sense to record 
the *protocol* used by the last command?



CMFatalErrorUpdate state and locks up. It is the same issue as
in the commit 2a0bdff6b958d1b2523d2754b6cd5e0ea4053016 (ahci-xgene:
fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode
command).



For example :  without this patch it results in READ DMA command failure
as shown below :


[...]


Signed-off-by: Suman Tripathi 
Reported-by:   Mark Langsdorf 


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Sergei Shtylyov

On 02/02/2015 10:37 PM, Suman Tripathi wrote:

   Ugh, please avoid using HTML when posting to the lists hosted on 
vger.kernel.org -- it's configured to ignore such mails AFAIK.



This patch addresses the issue with ATA_CMD_SMART pio mode
command for enumeration and device detection with ATA devices.
The X-Gene AHCI controller has an errata in which it cannot clear
the BSY bit after the PIO setup FIS. The dma state machine enters



Hum, if this happens after every PIO command (PIO setup FISes are not
specific to the command, right?), perhaps it would make more sense to record
the *protocol* used by the last command?



No it happens for IDENTIFY DEVICE, ATA_CMD_PACKET and ATA_CMD_SMART commands .
It is actually the commands associated with a BSY bit clearing.


   I don't understand that -- BSY bit is cleared for *every* command, either 
at the end of it, or along with setting the DRQ bit for PIO data transfer.



CMFatalErrorUpdate state and locks up. It is the same issue as
in the commit 2a0bdff6b958d1b2523d2754b6cd5e__0ea4053016 (ahci-xgene:
fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode
command).



[...]



Signed-off-by: Suman Tripathi mailto:stripa...@apm.com>>
Reported-by:   Mark Langsdorf mailto:mlang...@redhat.com>>



MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command.

2015-02-02 Thread Suman Tripathi
   Ugh, please avoid using HTML when posting to the lists hosted on
vger.kernel.org -- it's configured to ignore such mails AFAIK.
Yeah forgot to set the plain text mode. Sorry for that

>>> This patch addresses the issue with ATA_CMD_SMART pio mode
>>> command for enumeration and device detection with ATA devices.
>>> The X-Gene AHCI controller has an errata in which it cannot clear
>>> the BSY bit after the PIO setup FIS. The dma state machine enters


>> Hum, if this happens after every PIO command (PIO setup FISes are not
>> specific to the command, right?), perhaps it would make more sense to record
>> the *protocol* used by the last command?


> No it happens for IDENTIFY DEVICE, ATA_CMD_PACKET and ATA_CMD_SMART commands .
> It is actually the commands associated with a BSY bit clearing.


   I don't understand that -- BSY bit is cleared for *every* command,
either at the end of it, or along with setting the DRQ bit for PIO
data transfer.
BSY bit is cleared after the end of these commands by the controller.
So due to the bug it doesn't clear it. When the DMA commands is issued
, it check for the BSY bit cleared or not and finds not cleared and
results in CMFatalErrorUpdate  and hangs.

>>> CMFatalErrorUpdate state and locks up. It is the same issue as
>>> in the commit 2a0bdff6b958d1b2523d2754b6cd5e__0ea4053016 (ahci-xgene:
>>> fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode
>>> command).


>> [...]


>>> Signed-off-by: Suman Tripathi >> >
>>> Reported-by:   Mark Langsdorf >> >
>>>

MBR, Sergei

On Tue, Feb 3, 2015 at 1:14 AM, Sergei Shtylyov
 wrote:
> On 02/02/2015 10:37 PM, Suman Tripathi wrote:
>
>Ugh, please avoid using HTML when posting to the lists hosted on
> vger.kernel.org -- it's configured to ignore such mails AFAIK.
>
 This patch addresses the issue with ATA_CMD_SMART pio mode
 command for enumeration and device detection with ATA devices.
 The X-Gene AHCI controller has an errata in which it cannot clear
 the BSY bit after the PIO setup FIS. The dma state machine enters
>
>
>>> Hum, if this happens after every PIO command (PIO setup FISes are not
>>> specific to the command, right?), perhaps it would make more sense to
>>> record
>>> the *protocol* used by the last command?
>
>
>> No it happens for IDENTIFY DEVICE, ATA_CMD_PACKET and ATA_CMD_SMART
>> commands .
>> It is actually the commands associated with a BSY bit clearing.
>
>
>I don't understand that -- BSY bit is cleared for *every* command, either
> at the end of it, or along with setting the DRQ bit for PIO data transfer.
>
 CMFatalErrorUpdate state and locks up. It is the same issue as
 in the commit 2a0bdff6b958d1b2523d2754b6cd5e__0ea4053016
 (ahci-xgene:
 fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode
 command).
>
>
>>> [...]
>
>
 Signed-off-by: Suman Tripathi >>> >
 Reported-by:   Mark Langsdorf >>> >

>
> MBR, Sergei
>



-- 
Thanks,
with regards,
Suman Tripathi
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/8] vhost/scsi: Add ANY_LAYOUT support

2015-02-02 Thread Nicholas A. Bellinger
On Mon, 2015-02-02 at 00:15 -0800, Christoph Hellwig wrote:
> Hi Nic,
> 
> Al has been rewriting the vhost code to use iov_iter primitives,
> can you please rebase it on top of that istead of using the obsolete
> infrastructure?
> 

Yep, already done with the copy_[from,to]_iter() conversion in
vhost_scsi_handle_vqal() + vhost_scsi_complete_cmd_work() respectively.

Looking at iov_iter_get_pages() now to see if it can replace the other
code, or if that should be a post merge improvement instead.

--nab



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: General protection fault in iscsi_rx_thread_pre_handler

2015-02-02 Thread Gavin Guo
Hi Nicholas,

On Sun, Feb 1, 2015 at 11:47 AM, Gavin Guo  wrote:
> Hi Nicholas,
>
> On Sat, Jan 31, 2015 at 6:53 AM, Nicholas A. Bellinger
>  wrote:
>> On Fri, 2015-01-23 at 09:30 +0800, Gavin Guo wrote:
>>> Hi Nicholas,
>>>
>>> On Fri, Jan 23, 2015 at 1:35 AM, Nicholas A. Bellinger
>>>  wrote:
>>> > On Thu, 2015-01-22 at 23:56 +0800, Gavin Guo wrote:
>>> >> Hi Nicolas,
>>> >>
>>> >> On Thu, Jan 22, 2015 at 5:50 PM, Nicholas A. Bellinger
>>> >>  wrote:
>>> >> > Hi Gavin,
>>> >> >
>>> >> > On Thu, 2015-01-22 at 06:38 +0800, Gavin Guo wrote:
>>> >> >> Hi all,
>>> >> >>
>>> >> >> The general protection fault screenshot is attached.
>>> >> >>
>>> >> >> Summary:
>>> >> >> The kernel is Ubuntu-3.13.0-39.66. I've done basic analysis and found
>>> >> >> the fault is in list_del of iscsi_del_ts_from_active_list. And it
>>> >> >> looks like deleting the iscsi_thread_set *ts two times. The point to
>>> >> >> delete including iscsi_get_ts_from_inactive_list, was also checked but
>>> >> >> still can't find the clue. Really appreciate if anyone can provide any
>>> >> >> idea on the bug.
>>> >> >>
>>> >
>>> > 
>>> >
>>> >> >
>>> >> > Thanks for your detailed analysis.
>>> >> >
>>> >> > A similar bug was reported off-list some months back by a person using
>>> >> > iser-target + RoCE export on v3.12.y code.  Just to confirm, your
>>> >> > environment is using traditional iscsi-target + TCP export, right..?
>>> >>
>>> >> I am sorry that I'm not an expert of the field and already google RoCE
>>> >> on the internet but still don't really know what RoCE is. However, I
>>> >> can provide the informations.  We used iscsiadm on the initiator side
>>> >> and lio_node and tcm_node commands to create the targets for
>>> >> connection. I think it should be normal  iscsi-target using TCP
>>> >> export.
>>> >>
>>> >
>>> > Yep, that would be traditional iscsi-target + TCP export.
>>> >
>>> >> >
>>> >> > At the time, a different set of iser-target related changes ended up
>>> >> > avoiding this issue on his particular setup, so we thought it was 
>>> >> > likely
>>> >> > a race triggered by login failures specific to iser-target code.
>>> >> >
>>> >> > There was a untested patch (included inline below) to drop the legacy
>>> >> > active_ts_list usage all-together, but IIRC he was not able to 
>>> >> > reproduce
>>> >> > further so the patch didn't get picked up for mainline.
>>> >> >
>>> >> > If your able to reliability reproduce, please try with the following
>>> >> > patch and let us know your progress.
>>> >>
>>> >> Thanks for your time reading the mail. I'll let you know the result.
>>> >
>>> > Just curious, are you able to reliability reproduce this bug in a VM..?
>>>
>>> Thanks for your caring, the machine is on the customer side, I've
>>> asked and now waiting for their response.
>>
>> Hi Gavin,
>>
>> Just curious if there has been any update on this yet..?
>>
>> --nab
>>
>
> Really thanks for your attention. I'm also currently waiting for the
> customer's reply and will send the email again to ask for the result.
> However, I think the symptom may be hard to replicate that's why the
> customer didn't reply me for a long time. Thanks for your time again.
>
> Thanks,
> Gavin

Sorry for making you wait so long. I just got the response from the
customer, they said the general protection fault happened just 2 times
in the past and cannot be reliably reproduced. And I am now waiting
for the verification test.

Thanks,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 2/4] Fix for crash when bfa_itnim is NULL

2015-02-02 Thread Anil Gurumurthy
Hi Julian,
   You are right. It makes sense to move it to the next patch. I will re-send 
the patch series.

Thanks,
Anil

-Original Message-
From: Julian Calaby [mailto:julian.cal...@gmail.com] 
Sent: 30 January 2015 06:45
To: Anil Gurumurthy
Cc: Jej B; Christoph Hellwig; linux-scsi
Subject: Re: [PATCH 2/4] Fix for crash when bfa_itnim is NULL

Hi Anil,

On Thu, Jan 29, 2015 at 7:55 PM,   wrote:
> From: Anil Gurumurthy 
>
> Signed-off-by: Sudarsana Kalluru 
> Signed-off-by: Anil Gurumurthy 
> ---
>  drivers/scsi/bfa/bfa_fcs_lport.c |2 +-
>  drivers/scsi/bfa/bfad_im.c   |   26 ++
>  2 files changed, 27 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/bfa/bfa_fcs_lport.c 
> b/drivers/scsi/bfa/bfa_fcs_lport.c
> index d823792..4631630 100644
> --- a/drivers/scsi/bfa/bfa_fcs_lport.c
> +++ b/drivers/scsi/bfa/bfa_fcs_lport.c
> @@ -2654,7 +2654,7 @@ bfa_fcs_fdmi_get_hbaattr(struct bfa_fcs_lport_fdmi_s 
> *fdmi,
>
> strncpy(hba_attr->node_sym_name.symname,
> port->port_cfg.node_sym_name.symname, BFA_SYMNAME_MAXLEN);
> -   strcpy(hba_attr->vendor_info, "BROCADE");
> +   strcpy(hba_attr->vendor_info, "QLogic");

Shouldn't this be in the next patch?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
<>

[PATCH-v3 0/9] vhost/scsi: Add ANY_LAYOUT + VERSION_1 support

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

Hi MST, Paolo, Al & Co,

Here is -v3 for adding vhost/scsi ANY_LAYOUT + VERSION_1 host feature
bit support.

It adds a new vhost_virtqueue ->handle_kick() callback to determine the
start of protection and data payloads iovecs past starting virtio-scsi
request and response headers, based upon data_direction using iov_iter
primitives.

It assumes request/CDB and response/sense_buffer headers may span more
than a single iovec using mm/iov_iter.c logic.

It also allows virtio-scsi headers + T10_PI + Data SGL payloads to span
the same iovec when pinning user-space memory via get_user_pages_fast()
code.  (Not tested yet)

Based upon Al & HCH's feedback, the patch series has been converted to
use copy_*_iter() for virtio-scsi header copy.  Also, patch #4 has been
updated to use iov_iter_npages() for sgl_count, and patch #5 updated to
use iov_iter_advance() for calculating prot_bytes offset to the start
of data_iter.

v3 changelog:
  - Convert memcpy_toiovecend -> copy_to_iter usage
  - Update vhost_scsi_mapal + friends to use iov_iter
  - Move iov_iter sanity checks into vhost_scsi_calc_sgls
  - Convert vhost_scsi_calc_sgls() to iov_iter_npages()
  - Convert to vhost_scsi_handle_vqal to copy_from_iter usage
  - Update vhost_scsi_handle_vqal comments for iov_iter usage
  - Convert prot_bytes offset to use iov_iter_advance
  - Drop max_niov usage in vhost_scsi_handle_vqal
  - Drop vhost_skip_iovec_bytes in favour of iov_iter

Note the one part that has been left unchanged is vhost_scsi_map_to_sgl()
into get_user_pages_fast(), for which existing iov_iter_get_pages() code
will need to allow for a callback to perform the associated scatterlists
setup from **pages for protection + data payloads.

It's functioning against v3.19-rc1 virtio-scsi LLD in T10_PI mode using
TYPE-1 DIF with ANY_LAYOUT -> VERSION_1 guest feature bits enabled, using
the layout following existing convention with protection/data SGL payloads
residing within seperate iovecs.

Also included in patch #9 is an over-due change to rename code in scsi.c
to line up with modern vhost_scsi naming convention.

Please review.

Thank you,

Nicholas Bellinger (9):
  vhost/scsi: Convert completion path to use copy_to_iser
  vhost/scsi: Fix incorrect early vhost_scsi_handle_vq failures
  vhost/scsi: Change vhost_scsi_map_to_sgl to accept iov ptr + len
  vhost/scsi: Add ANY_LAYOUT iov -> sgl mapping prerequisites
  vhost/scsi: Add ANY_LAYOUT vhost_virtqueue callback
  vhost/scsi: Set VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits
  vhost/scsi: Drop legacy pre virtio v1.0 !ANY_LAYOUT logic
  vhost/scsi: Drop left-over scsi_tcq.h include
  vhost/scsi: Global tcm_vhost -> vhost_scsi rename

 drivers/vhost/scsi.c | 1073 ++
 1 file changed, 549 insertions(+), 524 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH-v3 3/9] vhost/scsi: Change vhost_scsi_map_to_sgl to accept iov ptr + len

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

This patch changes vhost_scsi_map_to_sgl() parameters to accept virtio
iovec ptr + len when determing pages_nr.

This is currently done with iov_num_pages() -> PAGE_ALIGN, so allow
the same parameters as well.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 37 +++--
 1 file changed, 15 insertions(+), 22 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index e4e9f39..c3b12b3 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -222,10 +222,10 @@ static struct workqueue_struct *tcm_vhost_workqueue;
 static DEFINE_MUTEX(tcm_vhost_mutex);
 static LIST_HEAD(tcm_vhost_list);
 
-static int iov_num_pages(struct iovec *iov)
+static int iov_num_pages(void __user *iov_base, size_t iov_len)
 {
-   return (PAGE_ALIGN((unsigned long)iov->iov_base + iov->iov_len) -
-  ((unsigned long)iov->iov_base & PAGE_MASK)) >> PAGE_SHIFT;
+   return (PAGE_ALIGN((unsigned long)iov_base + iov_len) -
+  ((unsigned long)iov_base & PAGE_MASK)) >> PAGE_SHIFT;
 }
 
 static void tcm_vhost_done_inflight(struct kref *kref)
@@ -782,25 +782,18 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq, struct 
tcm_vhost_tpg *tpg,
  * Returns the number of scatterlist entries used or -errno on error.
  */
 static int
-vhost_scsi_map_to_sgl(struct tcm_vhost_cmd *tv_cmd,
+vhost_scsi_map_to_sgl(struct tcm_vhost_cmd *cmd,
+ void __user *ptr,
+ size_t len,
  struct scatterlist *sgl,
- unsigned int sgl_count,
- struct iovec *iov,
- struct page **pages,
  bool write)
 {
-   unsigned int npages = 0, pages_nr, offset, nbytes;
+   unsigned int npages = 0, offset, nbytes;
+   unsigned int pages_nr = iov_num_pages(ptr, len);
struct scatterlist *sg = sgl;
-   void __user *ptr = iov->iov_base;
-   size_t len = iov->iov_len;
+   struct page **pages = cmd->tvc_upages;
int ret, i;
 
-   pages_nr = iov_num_pages(iov);
-   if (pages_nr > sgl_count) {
-   pr_err("vhost_scsi_map_to_sgl() pages_nr: %u greater than"
-  " sgl_count: %u\n", pages_nr, sgl_count);
-   return -ENOBUFS;
-   }
if (pages_nr > TCM_VHOST_PREALLOC_UPAGES) {
pr_err("vhost_scsi_map_to_sgl() pages_nr: %u greater than"
   " preallocated TCM_VHOST_PREALLOC_UPAGES: %u\n",
@@ -845,7 +838,7 @@ vhost_scsi_map_iov_to_sgl(struct tcm_vhost_cmd *cmd,
int ret, i;
 
for (i = 0; i < niov; i++)
-   sgl_count += iov_num_pages(&iov[i]);
+   sgl_count += iov_num_pages(iov[i].iov_base, iov[i].iov_len);
 
if (sgl_count > TCM_VHOST_PREALLOC_SGLS) {
pr_err("vhost_scsi_map_iov_to_sgl() sgl_count: %u greater than"
@@ -861,8 +854,8 @@ vhost_scsi_map_iov_to_sgl(struct tcm_vhost_cmd *cmd,
pr_debug("Mapping iovec %p for %u pages\n", &iov[0], sgl_count);
 
for (i = 0; i < niov; i++) {
-   ret = vhost_scsi_map_to_sgl(cmd, sg, sgl_count, &iov[i],
-   cmd->tvc_upages, write);
+   ret = vhost_scsi_map_to_sgl(cmd, iov[i].iov_base, 
iov[i].iov_len,
+   sg, write);
if (ret < 0) {
for (i = 0; i < cmd->tvc_sgl_count; i++) {
struct page *page = sg_page(&cmd->tvc_sgl[i]);
@@ -889,7 +882,7 @@ vhost_scsi_map_iov_to_prot(struct tcm_vhost_cmd *cmd,
int ret, i;
 
for (i = 0; i < niov; i++)
-   prot_sgl_count += iov_num_pages(&iov[i]);
+   prot_sgl_count += iov_num_pages(iov[i].iov_base, 
iov[i].iov_len);
 
if (prot_sgl_count > TCM_VHOST_PREALLOC_PROT_SGLS) {
pr_err("vhost_scsi_map_iov_to_prot() sgl_count: %u greater than"
@@ -904,8 +897,8 @@ vhost_scsi_map_iov_to_prot(struct tcm_vhost_cmd *cmd,
cmd->tvc_prot_sgl_count = prot_sgl_count;
 
for (i = 0; i < niov; i++) {
-   ret = vhost_scsi_map_to_sgl(cmd, prot_sg, prot_sgl_count, 
&iov[i],
-   cmd->tvc_upages, write);
+   ret = vhost_scsi_map_to_sgl(cmd, iov[i].iov_base, 
iov[i].iov_len,
+   prot_sg, write);
if (ret < 0) {
for (i = 0; i < cmd->tvc_prot_sgl_count; i++) {
struct page *page = 
sg_page(&cmd->tvc_prot_sgl[i]);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH-v3 4/9] vhost/scsi: Add ANY_LAYOUT iov -> sgl mapping prerequisites

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

This patch adds ANY_LAYOUT prerequisites logic for accepting a set of
protection + data payloads via iov_iter.  Also includes helpers for
calcuating SGLs + invoking vhost_scsi_map_to_sgl() with a known number
of iovecs.

Required by ANY_LAYOUT processing when struct iovec may be offset into
the first outgoing virtio-scsi request header.

v2 changes:
  - Clear ->tvc_sgl_count for vhost_scsi_mapal failure
  - Make vhost_scsi_mapal + vhost_scsi_calc_sgls accept max_niov
  - Minor cleanups

v3 changes:
  - Update vhost_scsi_mapal + friends to use iov_iter
  - Move iov_iter sanity checks into vhost_scsi_calc_sgls
  - Convert vhost_scsi_calc_sgls() to iov_iter_npages()

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 93 
 1 file changed, 93 insertions(+)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index c3b12b3..7dfff15 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -914,6 +914,99 @@ vhost_scsi_map_iov_to_prot(struct tcm_vhost_cmd *cmd,
return 0;
 }
 
+static int
+vhost_scsi_calc_sgls(struct iov_iter *iter, size_t bytes, int max_sgls)
+{
+   int sgl_count = 0;
+
+   if (!iter || !iter->iov) {
+   pr_err("%s: iter->iov is NULL, but expected bytes: %zu"
+  " present\n", __func__, bytes);
+   return -EINVAL;
+   }
+
+   sgl_count = iov_iter_npages(iter, 0x);
+   if (sgl_count > max_sgls) {
+   pr_err("%s: requested sgl_count: %d exceeds pre-allocated"
+  " max_sgls: %d\n", __func__, sgl_count, max_sgls);
+   return -EINVAL;
+   }
+   return sgl_count;
+}
+
+static int
+vhost_scsi_iov_to_sgl(struct tcm_vhost_cmd *cmd, bool write,
+ struct iov_iter *iter, struct scatterlist *sg,
+ int sg_count)
+{
+   size_t off = iter->iov_offset;
+   int i, ret;
+
+   for (i = 0; i < iter->nr_segs; i++) {
+   void __user *base = iter->iov[i].iov_base + off;
+   size_t len = iter->iov[i].iov_len - off;
+
+   ret = vhost_scsi_map_to_sgl(cmd, base, len, sg, write);
+   if (ret < 0) {
+   for (i = 0; i < sg_count; i++) {
+   struct page *page = sg_page(&sg[i]);
+   if (page)
+   put_page(page);
+   }
+   return ret;
+   }
+   sg += ret;
+   off = 0;
+   }
+   return 0;
+}
+
+static int
+vhost_scsi_mapal(struct tcm_vhost_cmd *cmd,
+size_t prot_bytes, struct iov_iter *prot_iter,
+size_t data_bytes, struct iov_iter *data_iter)
+{
+   int sgl_count, ret;
+   bool write = (cmd->tvc_data_direction == DMA_FROM_DEVICE);
+
+   if (prot_bytes) {
+   sgl_count = vhost_scsi_calc_sgls(prot_iter, prot_bytes,
+TCM_VHOST_PREALLOC_PROT_SGLS);
+   if (sgl_count < 0)
+   return sgl_count;
+
+   sg_init_table(cmd->tvc_prot_sgl, sgl_count);
+   cmd->tvc_prot_sgl_count = sgl_count;
+   pr_debug("%s prot_sg %p prot_sgl_count %u\n", __func__,
+cmd->tvc_prot_sgl, cmd->tvc_prot_sgl_count);
+
+   ret = vhost_scsi_iov_to_sgl(cmd, write, prot_iter,
+   cmd->tvc_prot_sgl,
+   cmd->tvc_prot_sgl_count);
+   if (ret < 0) {
+   cmd->tvc_prot_sgl_count = 0;
+   return ret;
+   }
+   }
+   sgl_count = vhost_scsi_calc_sgls(data_iter, data_bytes,
+TCM_VHOST_PREALLOC_SGLS);
+   if (sgl_count < 0)
+   return sgl_count;
+
+   sg_init_table(cmd->tvc_sgl, sgl_count);
+   cmd->tvc_sgl_count = sgl_count;
+   pr_debug("%s data_sg %p data_sgl_count %u\n", __func__,
+ cmd->tvc_sgl, cmd->tvc_sgl_count);
+
+   ret = vhost_scsi_iov_to_sgl(cmd, write, data_iter,
+   cmd->tvc_sgl, cmd->tvc_sgl_count);
+   if (ret < 0) {
+   cmd->tvc_sgl_count = 0;
+   return ret;
+   }
+   return 0;
+}
+
 static void tcm_vhost_submission_work(struct work_struct *work)
 {
struct tcm_vhost_cmd *cmd =
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH-v3 1/9] vhost/scsi: Convert completion path to use copy_to_iser

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

Required for ANY_LAYOUT support when the incoming virtio-scsi response
header + fixed size sense buffer payload may span more than a single
iovec entry.

This changes existing code to save cmd->tvc_resp_iov instead of the
first single iovec base pointer from &vq->iov[out].

v3 changes:
  - Convert memcpy_toiovecend -> copy_to_iser usage

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 01c01cb..1ad5b0f 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -72,6 +72,8 @@ struct tcm_vhost_cmd {
int tvc_vq_desc;
/* virtio-scsi initiator task attribute */
int tvc_task_attr;
+   /* virtio-scsi response incoming iovecs */
+   int tvc_in_iovs;
/* virtio-scsi initiator data direction */
enum dma_data_direction tvc_data_direction;
/* Expected data transfer length from virtio-scsi header */
@@ -87,8 +89,8 @@ struct tcm_vhost_cmd {
struct scatterlist *tvc_sgl;
struct scatterlist *tvc_prot_sgl;
struct page **tvc_upages;
-   /* Pointer to response */
-   struct virtio_scsi_cmd_resp __user *tvc_resp;
+   /* Pointer to response header iovec */
+   struct iovec *tvc_resp_iov;
/* Pointer to vhost_scsi for our device */
struct vhost_scsi *tvc_vhost;
/* Pointer to vhost_virtqueue for the cmd */
@@ -682,6 +684,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work 
*work)
struct tcm_vhost_cmd *cmd;
struct llist_node *llnode;
struct se_cmd *se_cmd;
+   struct iov_iter iov_iter;
int ret, vq;
 
bitmap_zero(signal, VHOST_SCSI_MAX_VQ);
@@ -703,8 +706,11 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work 
*work)
 se_cmd->scsi_sense_length);
memcpy(v_rsp.sense, cmd->tvc_sense_buf,
   se_cmd->scsi_sense_length);
-   ret = copy_to_user(cmd->tvc_resp, &v_rsp, sizeof(v_rsp));
-   if (likely(ret == 0)) {
+
+   iov_iter_init(&iov_iter, WRITE, cmd->tvc_resp_iov,
+ cmd->tvc_in_iovs, sizeof(v_rsp));
+   ret = copy_to_iter(&v_rsp, sizeof(v_rsp), &iov_iter);
+   if (likely(ret == sizeof(v_rsp))) {
struct vhost_scsi_virtqueue *q;
vhost_add_used(cmd->tvc_vq, cmd->tvc_vq_desc, 0);
q = container_of(cmd->tvc_vq, struct 
vhost_scsi_virtqueue, vq);
@@ -1159,7 +1165,8 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct 
vhost_virtqueue *vq)
 
cmd->tvc_vhost = vs;
cmd->tvc_vq = vq;
-   cmd->tvc_resp = vq->iov[out].iov_base;
+   cmd->tvc_resp_iov = &vq->iov[out];
+   cmd->tvc_in_iovs = in;
 
pr_debug("vhost_scsi got command opcode: %#02x, lun: %d\n",
cmd->tvc_cdb[0], cmd->tvc_lun);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH-v3 9/9] vhost/scsi: Global tcm_vhost -> vhost_scsi rename

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

There is a large amount of code that still references the original
'tcm_vhost' naming conventions, instead of modern 'vhost_scsi'.

Go ahead and do a global rename to make the usage consistent.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 662 +--
 1 file changed, 331 insertions(+), 331 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 2b4b002..66f682c 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -51,13 +51,13 @@
 
 #include "vhost.h"
 
-#define TCM_VHOST_VERSION  "v0.1"
-#define TCM_VHOST_NAMELEN 256
-#define TCM_VHOST_MAX_CDB_SIZE 32
-#define TCM_VHOST_DEFAULT_TAGS 256
-#define TCM_VHOST_PREALLOC_SGLS 2048
-#define TCM_VHOST_PREALLOC_UPAGES 2048
-#define TCM_VHOST_PREALLOC_PROT_SGLS 512
+#define VHOST_SCSI_VERSION  "v0.1"
+#define VHOST_SCSI_NAMELEN 256
+#define VHOST_SCSI_MAX_CDB_SIZE 32
+#define VHOST_SCSI_DEFAULT_TAGS 256
+#define VHOST_SCSI_PREALLOC_SGLS 2048
+#define VHOST_SCSI_PREALLOC_UPAGES 2048
+#define VHOST_SCSI_PREALLOC_PROT_SGLS 512
 
 struct vhost_scsi_inflight {
/* Wait for the flush operation to finish */
@@ -66,7 +66,7 @@ struct vhost_scsi_inflight {
struct kref kref;
 };
 
-struct tcm_vhost_cmd {
+struct vhost_scsi_cmd {
/* Descriptor from vhost_get_vq_desc() for virt_queue segment */
int tvc_vq_desc;
/* virtio-scsi initiator task attribute */
@@ -82,7 +82,7 @@ struct tcm_vhost_cmd {
/* The number of scatterlists associated with this cmd */
u32 tvc_sgl_count;
u32 tvc_prot_sgl_count;
-   /* Saved unpacked SCSI LUN for tcm_vhost_submission_work() */
+   /* Saved unpacked SCSI LUN for vhost_scsi_submission_work() */
u32 tvc_lun;
/* Pointer to the SGL formatted memory from virtio-scsi */
struct scatterlist *tvc_sgl;
@@ -95,13 +95,13 @@ struct tcm_vhost_cmd {
/* Pointer to vhost_virtqueue for the cmd */
struct vhost_virtqueue *tvc_vq;
/* Pointer to vhost nexus memory */
-   struct tcm_vhost_nexus *tvc_nexus;
+   struct vhost_scsi_nexus *tvc_nexus;
/* The TCM I/O descriptor that is accessed via container_of() */
struct se_cmd tvc_se_cmd;
-   /* work item used for cmwq dispatch to tcm_vhost_submission_work() */
+   /* work item used for cmwq dispatch to vhost_scsi_submission_work() */
struct work_struct work;
/* Copy of the incoming SCSI command descriptor block (CDB) */
-   unsigned char tvc_cdb[TCM_VHOST_MAX_CDB_SIZE];
+   unsigned char tvc_cdb[VHOST_SCSI_MAX_CDB_SIZE];
/* Sense buffer that will be mapped into outgoing status */
unsigned char tvc_sense_buf[TRANSPORT_SENSE_BUFFER];
/* Completed commands list, serviced from vhost worker thread */
@@ -110,53 +110,53 @@ struct tcm_vhost_cmd {
struct vhost_scsi_inflight *inflight;
 };
 
-struct tcm_vhost_nexus {
+struct vhost_scsi_nexus {
/* Pointer to TCM session for I_T Nexus */
struct se_session *tvn_se_sess;
 };
 
-struct tcm_vhost_nacl {
+struct vhost_scsi_nacl {
/* Binary World Wide unique Port Name for Vhost Initiator port */
u64 iport_wwpn;
/* ASCII formatted WWPN for Sas Initiator port */
-   char iport_name[TCM_VHOST_NAMELEN];
-   /* Returned by tcm_vhost_make_nodeacl() */
+   char iport_name[VHOST_SCSI_NAMELEN];
+   /* Returned by vhost_scsi_make_nodeacl() */
struct se_node_acl se_node_acl;
 };
 
-struct tcm_vhost_tpg {
+struct vhost_scsi_tpg {
/* Vhost port target portal group tag for TCM */
u16 tport_tpgt;
/* Used to track number of TPG Port/Lun Links wrt to explict I_T Nexus 
shutdown */
int tv_tpg_port_count;
/* Used for vhost_scsi device reference to tpg_nexus, protected by 
tv_tpg_mutex */
int tv_tpg_vhost_count;
-   /* list for tcm_vhost_list */
+   /* list for vhost_scsi_list */
struct list_head tv_tpg_list;
/* Used to protect access for tpg_nexus */
struct mutex tv_tpg_mutex;
/* Pointer to the TCM VHost I_T Nexus for this TPG endpoint */
-   struct tcm_vhost_nexus *tpg_nexus;
-   /* Pointer back to tcm_vhost_tport */
-   struct tcm_vhost_tport *tport;
-   /* Returned by tcm_vhost_make_tpg() */
+   struct vhost_scsi_nexus *tpg_nexus;
+   /* Pointer back to vhost_scsi_tport */
+   struct vhost_scsi_tport *tport;
+   /* Returned by vhost_scsi_make_tpg() */
struct se_portal_group se_tpg;
/* Pointer back to vhost_scsi, protected by tv_tpg_mutex */
struct vhost_scsi *vhost_scsi;
 };
 
-struct tcm_vhost_tport {
+struct vhost_scsi_tport {
/* SCSI protocol the tport is providing */
u8 tport_proto_id;
/* Binary World Wide unique Port Name for Vhost Target port */
u64 tport_wwpn;
/* ASCII formatted WWPN for Vhos

[PATCH-v3 6/9] vhost/scsi: Set VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

Signal support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits
required for virtio-scsi 1.0 spec layout requirements.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index e1fe003..c25fdd7 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -173,7 +173,9 @@ enum {
 /* Note: can't set VIRTIO_F_VERSION_1 yet, since that implies ANY_LAYOUT. */
 enum {
VHOST_SCSI_FEATURES = VHOST_FEATURES | (1ULL << VIRTIO_SCSI_F_HOTPLUG) |
-  (1ULL << VIRTIO_SCSI_F_T10_PI)
+  (1ULL << VIRTIO_SCSI_F_T10_PI) |
+  (1ULL << VIRTIO_F_ANY_LAYOUT) |
+  (1ULL << VIRTIO_F_VERSION_1)
 };
 
 #define VHOST_SCSI_MAX_TARGET  256
@@ -1626,7 +1628,10 @@ static void vhost_scsi_handle_kick(struct vhost_work 
*work)
poll.work);
struct vhost_scsi *vs = container_of(vq->dev, struct vhost_scsi, dev);
 
-   vhost_scsi_handle_vq(vs, vq);
+   if (vhost_has_feature(vq, VIRTIO_F_ANY_LAYOUT))
+   vhost_scsi_handle_vqal(vs, vq);
+   else
+   vhost_scsi_handle_vq(vs, vq);
 }
 
 static void vhost_scsi_flush_vq(struct vhost_scsi *vs, int index)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH-v3 5/9] vhost/scsi: Add ANY_LAYOUT vhost_virtqueue callback

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

This patch adds ANY_LAYOUT support with a new vqs[].vq.handle_kick()
callback in vhost_scsi_handle_vqal().

It calculates data_direction + exp_data_len for the new tcm_vhost_cmd
descriptor by walking both outgoing + incoming iovecs using iov_iter,
assuming the layout of outgoing request header + T10_PI + Data payload
comes first.

It also uses copy_from_iter() to copy leading virtio-scsi request header
that may or may not include SCSI CDB, that returns a re-calculated iovec
to start of T10_PI or Data SGL memory.

v2 changes:
  - Fix up vhost_scsi_handle_vqal comments
  - Minor vhost_scsi_handle_vqal simplifications
  - Add missing minimum virtio-scsi response buffer size check
  - Fix pi_bytes* error message typo
  - Convert to use vhost_skip_iovec_bytes() common code
  - Add max_niov sanity checks vs. out + in offset into vq

v3 changes:
  - Convert to copy_from_iter usage
  - Update vhost_scsi_handle_vqal comments for iov_iter usage
  - Convert prot_bytes offset to use iov_iter_advance
  - Drop max_niov usage in vhost_scsi_handle_vqal
  - Drop vhost_skip_iovec_bytes in favour of iov_iter

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 260 +++
 1 file changed, 260 insertions(+)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 7dfff15..e1fe003 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1062,6 +1062,266 @@ vhost_scsi_send_bad_target(struct vhost_scsi *vs,
 }
 
 static void
+vhost_scsi_handle_vqal(struct vhost_scsi *vs, struct vhost_virtqueue *vq)
+{
+   struct tcm_vhost_tpg **vs_tpg, *tpg;
+   struct virtio_scsi_cmd_req v_req;
+   struct virtio_scsi_cmd_req_pi v_req_pi;
+   struct tcm_vhost_cmd *cmd;
+   struct iov_iter out_iter, in_iter, prot_iter, data_iter;
+   u64 tag;
+   u32 exp_data_len, data_direction;
+   unsigned out, in, i;
+   int head, ret, prot_bytes;
+   size_t req_size, rsp_size = sizeof(struct virtio_scsi_cmd_resp);
+   size_t out_size, in_size;
+   u16 lun;
+   u8 *target, *lunp, task_attr;
+   bool t10_pi = vhost_has_feature(vq, VIRTIO_SCSI_F_T10_PI);
+   void *req, *cdb;
+
+   mutex_lock(&vq->mutex);
+   /*
+* We can handle the vq only after the endpoint is setup by calling the
+* VHOST_SCSI_SET_ENDPOINT ioctl.
+*/
+   vs_tpg = vq->private_data;
+   if (!vs_tpg)
+   goto out;
+
+   vhost_disable_notify(&vs->dev, vq);
+
+   for (;;) {
+   head = vhost_get_vq_desc(vq, vq->iov,
+ARRAY_SIZE(vq->iov), &out, &in,
+NULL, NULL);
+   pr_debug("vhost_get_vq_desc: head: %d, out: %u in: %u\n",
+head, out, in);
+   /* On error, stop handling until the next kick. */
+   if (unlikely(head < 0))
+   break;
+   /* Nothing new?  Wait for eventfd to tell us they refilled. */
+   if (head == vq->num) {
+   if (unlikely(vhost_enable_notify(&vs->dev, vq))) {
+   vhost_disable_notify(&vs->dev, vq);
+   continue;
+   }
+   break;
+   }
+   /*
+* Check for a sane response buffer so we can report early
+* errors back to the guest.
+*/
+   if (unlikely(vq->iov[out].iov_len < rsp_size)) {
+   vq_err(vq, "Expecting at least virtio_scsi_cmd_resp"
+   " size, got %zu bytes\n", vq->iov[out].iov_len);
+   break;
+   }
+   /*
+* Setup pointers and values based upon different virtio-scsi
+* request header if T10_PI is enabled in KVM guest.
+*/
+   if (t10_pi) {
+   req = &v_req_pi;
+   req_size = sizeof(v_req_pi);
+   lunp = &v_req_pi.lun[0];
+   target = &v_req_pi.lun[1];
+   } else {
+   req = &v_req;
+   req_size = sizeof(v_req);
+   lunp = &v_req.lun[0];
+   target = &v_req.lun[1];
+   }
+   /*
+* Determine data_direction for ANY_LAYOUT by calculating the
+* total outgoing iovec sizes / incoming iovec sizes vs.
+* virtio-scsi request / response headers respectively.
+*
+* FIXME: Not correct for BIDI operation
+*/
+   out_size = in_size = 0;
+   for (i = 0; i < out; i++)
+   out_size += vq->iov[i].iov_len;
+   for (i = out; i < out + in; i++)
+   

[PATCH-v3 2/9] vhost/scsi: Fix incorrect early vhost_scsi_handle_vq failures

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

This patch fixes vhost_scsi_handle_vq() failure cases that result in BUG_ON()
getting triggered when vhost_scsi_free_cmd() is called, and ->tvc_se_cmd has
not been initialized by target_submit_cmd_map_sgls().

It changes tcm_vhost_release_cmd() to use tcm_vhost_cmd->tvc_nexus for obtaining
se_session pointer reference.  Also, avoid calling put_page() on NULL sg->page
entries in vhost_scsi_map_to_sgl() failure path.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 52 +---
 1 file changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 1ad5b0f..e4e9f39 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -462,7 +462,7 @@ static void tcm_vhost_release_cmd(struct se_cmd *se_cmd)
 {
struct tcm_vhost_cmd *tv_cmd = container_of(se_cmd,
struct tcm_vhost_cmd, tvc_se_cmd);
-   struct se_session *se_sess = se_cmd->se_sess;
+   struct se_session *se_sess = tv_cmd->tvc_nexus->tvn_se_sess;
int i;
 
if (tv_cmd->tvc_sgl_count) {
@@ -864,9 +864,11 @@ vhost_scsi_map_iov_to_sgl(struct tcm_vhost_cmd *cmd,
ret = vhost_scsi_map_to_sgl(cmd, sg, sgl_count, &iov[i],
cmd->tvc_upages, write);
if (ret < 0) {
-   for (i = 0; i < cmd->tvc_sgl_count; i++)
-   put_page(sg_page(&cmd->tvc_sgl[i]));
-
+   for (i = 0; i < cmd->tvc_sgl_count; i++) {
+   struct page *page = sg_page(&cmd->tvc_sgl[i]);
+   if (page)
+   put_page(page);
+   }
cmd->tvc_sgl_count = 0;
return ret;
}
@@ -905,9 +907,11 @@ vhost_scsi_map_iov_to_prot(struct tcm_vhost_cmd *cmd,
ret = vhost_scsi_map_to_sgl(cmd, prot_sg, prot_sgl_count, 
&iov[i],
cmd->tvc_upages, write);
if (ret < 0) {
-   for (i = 0; i < cmd->tvc_prot_sgl_count; i++)
-   put_page(sg_page(&cmd->tvc_prot_sgl[i]));
-
+   for (i = 0; i < cmd->tvc_prot_sgl_count; i++) {
+   struct page *page = 
sg_page(&cmd->tvc_prot_sgl[i]);
+   if (page)
+   put_page(page);
+   }
cmd->tvc_prot_sgl_count = 0;
return ret;
}
@@ -1065,12 +1069,14 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct 
vhost_virtqueue *vq)
if (unlikely(vq->iov[0].iov_len < req_size)) {
pr_err("Expecting virtio-scsi header: %zu, got %zu\n",
   req_size, vq->iov[0].iov_len);
-   break;
+   vhost_scsi_send_bad_target(vs, vq, head, out);
+   continue;
}
ret = memcpy_fromiovecend(req, &vq->iov[0], 0, req_size);
if (unlikely(ret)) {
vq_err(vq, "Faulted on virtio_scsi_cmd_req\n");
-   break;
+   vhost_scsi_send_bad_target(vs, vq, head, out);
+   continue;
}
 
/* virtio-scsi spec requires byte 0 of the lun to be 1 */
@@ -1101,14 +1107,16 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct 
vhost_virtqueue *vq)
if (data_direction != DMA_TO_DEVICE) {
vq_err(vq, "Received non zero 
do_pi_niov"
", but wrong data_direction\n");
-   goto err_cmd;
+   vhost_scsi_send_bad_target(vs, vq, 
head, out);
+   continue;
}
prot_bytes = vhost32_to_cpu(vq, 
v_req_pi.pi_bytesout);
} else if (v_req_pi.pi_bytesin) {
if (data_direction != DMA_FROM_DEVICE) {
vq_err(vq, "Received non zero 
di_pi_niov"
", but wrong data_direction\n");
-   goto err_cmd;
+   vhost_scsi_send_bad_target(vs, vq, 
head, out);
+   continue;
}
prot_bytes = vhost32_to_cpu(vq, 
v_req_pi.pi_bytesin);
}
@@ -1148,7 +1156,8 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct 
vhost_virtqueue *vq)
  

[PATCH-v3 8/9] vhost/scsi: Drop left-over scsi_tcq.h include

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

With the recent removal of MSG_*_TAG defines in commit 68d81f40,
vhost-scsi is now using TCM_*_TAG and doesn't depend upon host
side scsi_tcq.h definitions anymore.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 9af93d0..2b4b002 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -38,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH-v3 7/9] vhost/scsi: Drop legacy pre virtio v1.0 !ANY_LAYOUT logic

2015-02-02 Thread Nicholas A. Bellinger
From: Nicholas Bellinger 

With the new ANY_LAYOUT logic in place for vhost_scsi_handle_vqal(),
there is no longer a reason to keep around the legacy code with
!ANY_LAYOUT assumptions.

Go ahead and drop the pre virtio 1.0 logic in vhost_scsi_handle_vq()
and associated helpers.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Signed-off-by: Nicholas Bellinger 
---
 drivers/vhost/scsi.c | 340 +--
 1 file changed, 1 insertion(+), 339 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index c25fdd7..9af93d0 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -830,93 +830,6 @@ out:
 }
 
 static int
-vhost_scsi_map_iov_to_sgl(struct tcm_vhost_cmd *cmd,
- struct iovec *iov,
- int niov,
- bool write)
-{
-   struct scatterlist *sg = cmd->tvc_sgl;
-   unsigned int sgl_count = 0;
-   int ret, i;
-
-   for (i = 0; i < niov; i++)
-   sgl_count += iov_num_pages(iov[i].iov_base, iov[i].iov_len);
-
-   if (sgl_count > TCM_VHOST_PREALLOC_SGLS) {
-   pr_err("vhost_scsi_map_iov_to_sgl() sgl_count: %u greater than"
-   " preallocated TCM_VHOST_PREALLOC_SGLS: %u\n",
-   sgl_count, TCM_VHOST_PREALLOC_SGLS);
-   return -ENOBUFS;
-   }
-
-   pr_debug("%s sg %p sgl_count %u\n", __func__, sg, sgl_count);
-   sg_init_table(sg, sgl_count);
-   cmd->tvc_sgl_count = sgl_count;
-
-   pr_debug("Mapping iovec %p for %u pages\n", &iov[0], sgl_count);
-
-   for (i = 0; i < niov; i++) {
-   ret = vhost_scsi_map_to_sgl(cmd, iov[i].iov_base, 
iov[i].iov_len,
-   sg, write);
-   if (ret < 0) {
-   for (i = 0; i < cmd->tvc_sgl_count; i++) {
-   struct page *page = sg_page(&cmd->tvc_sgl[i]);
-   if (page)
-   put_page(page);
-   }
-   cmd->tvc_sgl_count = 0;
-   return ret;
-   }
-   sg += ret;
-   sgl_count -= ret;
-   }
-   return 0;
-}
-
-static int
-vhost_scsi_map_iov_to_prot(struct tcm_vhost_cmd *cmd,
-  struct iovec *iov,
-  int niov,
-  bool write)
-{
-   struct scatterlist *prot_sg = cmd->tvc_prot_sgl;
-   unsigned int prot_sgl_count = 0;
-   int ret, i;
-
-   for (i = 0; i < niov; i++)
-   prot_sgl_count += iov_num_pages(iov[i].iov_base, 
iov[i].iov_len);
-
-   if (prot_sgl_count > TCM_VHOST_PREALLOC_PROT_SGLS) {
-   pr_err("vhost_scsi_map_iov_to_prot() sgl_count: %u greater than"
-   " preallocated TCM_VHOST_PREALLOC_PROT_SGLS: %u\n",
-   prot_sgl_count, TCM_VHOST_PREALLOC_PROT_SGLS);
-   return -ENOBUFS;
-   }
-
-   pr_debug("%s prot_sg %p prot_sgl_count %u\n", __func__,
-prot_sg, prot_sgl_count);
-   sg_init_table(prot_sg, prot_sgl_count);
-   cmd->tvc_prot_sgl_count = prot_sgl_count;
-
-   for (i = 0; i < niov; i++) {
-   ret = vhost_scsi_map_to_sgl(cmd, iov[i].iov_base, 
iov[i].iov_len,
-   prot_sg, write);
-   if (ret < 0) {
-   for (i = 0; i < cmd->tvc_prot_sgl_count; i++) {
-   struct page *page = 
sg_page(&cmd->tvc_prot_sgl[i]);
-   if (page)
-   put_page(page);
-   }
-   cmd->tvc_prot_sgl_count = 0;
-   return ret;
-   }
-   prot_sg += ret;
-   prot_sgl_count -= ret;
-   }
-   return 0;
-}
-
-static int
 vhost_scsi_calc_sgls(struct iov_iter *iter, size_t bytes, int max_sgls)
 {
int sgl_count = 0;
@@ -1323,254 +1236,6 @@ out:
mutex_unlock(&vq->mutex);
 }
 
-static void
-vhost_scsi_handle_vq(struct vhost_scsi *vs, struct vhost_virtqueue *vq)
-{
-   struct tcm_vhost_tpg **vs_tpg;
-   struct virtio_scsi_cmd_req v_req;
-   struct virtio_scsi_cmd_req_pi v_req_pi;
-   struct tcm_vhost_tpg *tpg;
-   struct tcm_vhost_cmd *cmd;
-   u64 tag;
-   u32 exp_data_len, data_first, data_num, data_direction, prot_first;
-   unsigned out, in, i;
-   int head, ret, data_niov, prot_niov, prot_bytes;
-   size_t req_size;
-   u16 lun;
-   u8 *target, *lunp, task_attr;
-   bool hdr_pi;
-   void *req, *cdb;
-
-   mutex_lock(&vq->mutex);
-   /*
-* We can handle the vq only after the endpoint is setup by calling the
-* VHOST_SCSI_SET_ENDPOINT ioctl.
-*/
-   vs_tpg = vq->private_data;
-   if (!vs_tpg)
-   goto out;
-
-