Re: [PATCH v2] virtio-scsi: Fix the race condition in virtscsi_handle_event
On Tue, Jan 06, 2015 at 03:33:36PM +0800, Fam Zheng wrote:
There is a race condition in virtscsi_handle_event, when many device
hotplug/unplug events flush in quickly.
The scsi_remove_device in virtscsi_handle_transport_reset may trigger
the BUG_ON in scsi_target_reap, because the state is altered behind it,
probably by scsi_scan_host of another event. I'm able to reproduce it by
repeatedly plugging and unplugging a scsi disk with the same lun number.
To make is safe, a single thread workqueue local to the module is added
which runs the scan work. With this change, the panic goes away.
Signed-off-by: Fam Zheng f...@redhat.com
---
v2: Use a single threaded workqueue instead of mutex to serialize work
(Venkatesh)
---
drivers/scsi/virtio_scsi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c52bb5d..71b0091 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -120,6 +120,8 @@ struct virtio_scsi {
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
+static struct workqueue_struct *virtscsi_scan_wq;
+
Don't add two empty lines please.
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
{
@@ -404,7 +406,7 @@ static void virtscsi_complete_event(struct virtio_scsi
*vscsi, void *buf)
struct virtio_scsi_event_node *event_node = buf;
if (!vscsi-stop_events)
- queue_work(system_freezable_wq, event_node-work);
+ queue_work(virtscsi_scan_wq, event_node-work);
}
static void virtscsi_event_done(struct virtqueue *vq)
@@ -1119,6 +1121,12 @@ static int __init init(void)
pr_err(mempool_create() for virtscsi_cmd_pool failed\n);
goto error;
}
+ virtscsi_scan_wq = create_singlethread_workqueue(virtscsi-scan);
+ if (!virtscsi_scan_wq) {
+ pr_err(create_singlethread_workqueue() for virtscsi_scan_wq
failed\n);
+ goto error;
+ }
+
ret = register_virtio_driver(virtio_scsi_driver);
if (ret 0)
goto error;
@@ -1126,6 +1134,9 @@ static int __init init(void)
return 0;
error:
+ if (virtscsi_scan_wq) {
+ destroy_workqueue(virtscsi_scan_wq);
+ }
if (virtscsi_cmd_pool) {
mempool_destroy(virtscsi_cmd_pool);
virtscsi_cmd_pool = NULL;
@@ -1142,6 +1153,7 @@ static void __exit fini(void)
unregister_virtio_driver(virtio_scsi_driver);
mempool_destroy(virtscsi_cmd_pool);
kmem_cache_destroy(virtscsi_cmd_cache);
+ destroy_workqueue(virtscsi_scan_wq);
Please destroy in reverse order of initialization:
between unregister_virtio_driver and mempool_destroy.
}
module_init(init);
module_exit(fini);
--
1.9.3
--
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: [SCSI] pmcraid: PMC-Sierra MaxRAID driver to support 6Gb/s SAS RAID controller
(Sorry, this code is really old, and normally I wouldn't report it but
I'm making a tutorial).
Hello Anil Ravindranath,
The patch 89a368104150: [SCSI] pmcraid: PMC-Sierra MaxRAID driver to
support 6Gb/s SAS RAID controller from Aug 25, 2009, leads to the
following static checker warning:
drivers/scsi/pmcraid.c:3860 pmcraid_ioctl_passthrough()
error: potential NULL dereference 'cmd-scsi_cmd'.
drivers/scsi/pmcraid.c
3764 cmd-scsi_cmd = NULL;
We set this to NULL here.
3765 ioarcb = (cmd-ioa_cb-ioarcb);
3766
3767 /* Copy the user-provided IOARCB stuff field by field */
3768 ioarcb-resource_handle = buffer-ioarcb.resource_handle;
3769 ioarcb-data_transfer_length =
buffer-ioarcb.data_transfer_length;
3770 ioarcb-cmd_timeout = buffer-ioarcb.cmd_timeout;
3771 ioarcb-request_type = buffer-ioarcb.request_type;
3772 ioarcb-request_flags0 = buffer-ioarcb.request_flags0;
3773 ioarcb-request_flags1 = buffer-ioarcb.request_flags1;
3774 memcpy(ioarcb-cdb, buffer-ioarcb.cdb, PMCRAID_MAX_CDB_LEN);
3775
3776 if (buffer-ioarcb.add_cmd_param_length) {
3777 ioarcb-add_cmd_param_length =
3778 buffer-ioarcb.add_cmd_param_length;
3779 ioarcb-add_cmd_param_offset =
3780 buffer-ioarcb.add_cmd_param_offset;
3781 memcpy(ioarcb-add_data.u.add_cmd_params,
3782 buffer-ioarcb.add_data.u.add_cmd_params,
3783 buffer-ioarcb.add_cmd_param_length);
3784 }
3785
3786 /* set hrrq number where the IOA should respond to. Note that
all cmds
3787 * generated internally uses hrrq_id 0, exception to this is
the cmd
3788 * block of scsi_cmd which is re-used (e.g. cancel/abort),
which uses
3789 * hrrq_id assigned here in queuecommand
3790 */
3791 ioarcb-hrrq_id = atomic_add_return(1,
(pinstance-last_message_id)) %
3792pinstance-num_hrrq;
3793
[ snip ]
3857 cmd-ioa_cb-ioarcb.cdb[0]);
3858
3859 spin_lock_irqsave(pinstance-host-host_lock,
lock_flags);
3860 cancel_cmd = pmcraid_abort_cmd(cmd);
^^
This will Oops because cmd-scsi_cmd is NULL.
3861 spin_unlock_irqrestore(pinstance-host-host_lock,
lock_flags);
3862
3863 if (cancel_cmd) {
regards,
dan carpenter
--
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 0/2] Add the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver.
This patch set implements the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver. Signed-off-by: Suman Tripathi stripa...@apm.com --- Suman Tripathi (2): ahci_xgene: Implement the xgene_ahci_poll_reg_val to support PMP. ahci_xgene: Implement the workaround to support PMP enumeration and discovery. drivers/ata/ahci_xgene.c | 189 +-- 1 file changed, 182 insertions(+), 7 deletions(-) -- 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 2/2] ahci_xgene: Implement the workaround to support PMP enumeration and discovery.
Due to H/W errata, the controller is unable to save the PMP
field fetched from command header before sending the H2D FIS.
When the device returns the PMP port field in the D2H FIS, there is
a mismatch and results in command completion failure. The workaround
is to write the pmp value to PxFBS.DEV field before issuing any command
to PMP.
Signed-off-by: Suman Tripathi stripa...@apm.com
---
drivers/ata/ahci_xgene.c | 133 +--
1 file changed, 128 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index afa9c03..7f68875 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -85,6 +85,7 @@ struct xgene_ahci_context {
struct ahci_host_priv *hpriv;
struct device *dev;
u8 last_cmd[MAX_AHCI_CHN_PERCTR]; /* tracking the last command issued*/
+ u32 class[MAX_AHCI_CHN_PERCTR]; /* tracking the class of device */
void __iomem *csr_core; /* Core CSR address of IP */
void __iomem *csr_diag; /* Diag CSR address of IP */
void __iomem *csr_axi; /* AXI CSR address of IP */
@@ -177,11 +178,17 @@ static int xgene_ahci_restart_engine(struct ata_port *ap)
* xgene_ahci_qc_issue - Issue commands to the device
* @qc: Command to issue
*
- * Due to Hardware errata for IDENTIFY DEVICE command and PACKET
- * command of ATAPI protocol set, the controller cannot clear the BSY bit
- * after receiving the PIO setup FIS. This results in the DMA state machine
- * going into the CMFatalErrorUpdate state and locks up. By restarting the
- * DMA engine, it removes the controller out of lock up state.
+ * Due to Hardware errata for IDENTIFY DEVICE command, the controller cannot
+ * clear the BSY bit after receiving the PIO setup FIS. This results in the dma
+ * state machine goes into the CMFatalErrorUpdate state and locks up. By
+ * restarting the dma engine, it removes the controller out of lock up state.
+ *
+ * Due to H/W errata, the controller is unable to save the PMP
+ * field fetched from command header before sending the H2D FIS.
+ * When the device returns the PMP port field in the D2H FIS, there is
+ * a mismatch and results in command completion failure. The
+ * workaround is to write the pmp value to PxFBS.DEV field before issuing
+ * any command to PMP.
*/
static unsigned int xgene_ahci_qc_issue(struct ata_queued_cmd *qc)
{
@@ -189,6 +196,19 @@ static unsigned int xgene_ahci_qc_issue(struct
ata_queued_cmd *qc)
struct ahci_host_priv *hpriv = ap-host-private_data;
struct xgene_ahci_context *ctx = hpriv-plat_data;
int rc = 0;
+ u32 port_fbs;
+ void *port_mmio = ahci_port_base(ap);
+
+ /*
+* Write the pmp value to PxFBS.DEV
+* for case of Port Mulitplier.
+*/
+ if (ctx-class[ap-port_no] == ATA_DEV_PMP) {
+ port_fbs = readl(port_mmio + PORT_FBS);
+ port_fbs = ~PORT_FBS_DEV_MASK;
+ port_fbs |= qc-dev-link-pmp PORT_FBS_DEV_OFFSET;
+ writel(port_fbs, port_mmio + PORT_FBS);
+ }
if (unlikely((ctx-last_cmd[ap-port_no] == ATA_CMD_ID_ATA) ||
(ctx-last_cmd[ap-port_no] == ATA_CMD_PACKET)))
@@ -417,12 +437,115 @@ static void xgene_ahci_host_stop(struct ata_host *host)
ahci_platform_disable_resources(hpriv);
}
+/**
+ * xgene_ahci_pmp_softreset - Issue the softreset to the drives connected
+ *to Port Multiplier.
+ * @link: link to reset
+ * @class: Return value to indicate class of device
+ * @deadline: deadline jiffies for the operation
+ *
+ * Due to H/W errata, the controller is unable to save the PMP
+ * field fetched from command header before sending the H2D FIS.
+ * When the device returns the PMP port field in the D2H FIS, there is
+ * a mismatch and results in command completion failure. The workaround
+ * is to write the pmp value to PxFBS.DEV field before issuing any command
+ * to PMP.
+ */
+static int xgene_ahci_pmp_softreset(struct ata_link *link, unsigned int *class,
+ unsigned long deadline)
+{
+ int pmp = sata_srst_pmp(link);
+ struct ata_port *ap = link-ap;
+ u32 rc;
+ void *port_mmio = ahci_port_base(ap);
+ u32 port_fbs;
+
+ /*
+* Set PxFBS.DEV field with pmp
+* value.
+*/
+ port_fbs = readl(port_mmio + PORT_FBS);
+ port_fbs = ~PORT_FBS_DEV_MASK;
+ port_fbs |= pmp PORT_FBS_DEV_OFFSET;
+ writel(port_fbs, port_mmio + PORT_FBS);
+
+ rc = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
+
+ return rc;
+}
+
+/**
+ * xgene_ahci_softreset - Issue the softreset to the drive.
+ * @link: link to reset
+ * @class: Return value to indicate class of device
+ * @deadline: deadline jiffies for the operation
+ *
+ * Due to H/W errata, the controller is unable to save the PMP
+ * field fetched from command header before sending
[PATCH v1 1/2] ahci_xgene: Implement the xgene_ahci_poll_reg_val to support PMP.
This patch implements the function xgene_ahci_poll_reg_val
to poll PxCI for multiple IDENTIFY DEVICE commands to finish before
restarting the DMA engine.
Signed-off-by: Suman Tripathi stripa...@apm.com
---
drivers/ata/ahci_xgene.c | 56 ++--
1 file changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index cbcd208..afa9c03 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -105,17 +105,69 @@ static int xgene_ahci_init_memram(struct
xgene_ahci_context *ctx)
}
/**
+ * xgene_ahci_poll_reg_val- Poll a register on a specific value.
+ * @ap : ATA port of interest.
+ * @reg : Register of interest.
+ * @val : Value to be attained.
+ * @interval : waiting interval for polling.
+ * @timeout : timeout for achieving the value.
+ */
+static int xgene_ahci_poll_reg_val(struct ata_port *ap,
+ void __iomem *reg, unsigned
+ int val, unsigned long interval,
+ unsigned long timeout)
+{
+ unsigned long deadline;
+ unsigned int tmp;
+
+ tmp = ioread32(reg);
+ deadline = ata_deadline(jiffies, timeout);
+
+ while (tmp != val time_before(jiffies, deadline)) {
+ ata_msleep(ap, interval);
+ tmp = ioread32(reg);
+ }
+
+ return tmp;
+}
+
+/**
* xgene_ahci_restart_engine - Restart the dma engine.
* @ap : ATA port of interest
*
- * Restarts the dma engine inside the controller.
+ * Waits for completion of multiple commands and restarts
+ * the DMA engine inside the controller.
*/
static int xgene_ahci_restart_engine(struct ata_port *ap)
{
struct ahci_host_priv *hpriv = ap-host-private_data;
+ struct ahci_port_priv *pp = ap-private_data;
+ void __iomem *port_mmio = ahci_port_base(ap);
+ u32 fbs;
+
+ /*
+* In case of PMP multiple IDENTIFY DEVICE commands can be
+* issued inside PxCI. So need to poll PxCI for the
+* completion of outstanding IDENTIFY DEVICE commands before
+* we restart the DMA engine.
+*/
+ if (xgene_ahci_poll_reg_val(ap, port_mmio +
+ PORT_CMD_ISSUE, 0x0, 1, 100))
+ return -EBUSY;
ahci_stop_engine(ap);
ahci_start_fis_rx(ap);
+
+ /*
+* Enable the PxFBS.FBS_EN bit as it
+* gets cleared due to stopping the engine.
+*/
+ if (pp-fbs_supported) {
+ fbs = readl(port_mmio + PORT_FBS);
+ writel(fbs | PORT_FBS_EN, port_mmio + PORT_FBS);
+ fbs = readl(port_mmio + PORT_FBS);
+ }
+
hpriv-start_engine(ap);
return 0;
@@ -374,7 +426,7 @@ static struct ata_port_operations xgene_ahci_ops = {
};
static const struct ata_port_info xgene_ahci_port_info = {
- .flags = AHCI_FLAG_COMMON,
+ .flags = AHCI_FLAG_COMMON | ATA_FLAG_PMP,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
.port_ops = xgene_ahci_ops,
--
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 v2] virtio-scsi: Fix the race condition in virtscsi_handle_event
On Mon, Jan 5, 2015 at 11:33 PM, Fam Zheng f...@redhat.com wrote:
There is a race condition in virtscsi_handle_event, when many device
hotplug/unplug events flush in quickly.
The scsi_remove_device in virtscsi_handle_transport_reset may trigger
the BUG_ON in scsi_target_reap, because the state is altered behind it,
probably by scsi_scan_host of another event. I'm able to reproduce it by
repeatedly plugging and unplugging a scsi disk with the same lun number.
To make is safe, a single thread workqueue local to the module is added
which runs the scan work. With this change, the panic goes away.
Signed-off-by: Fam Zheng f...@redhat.com
---
v2: Use a single threaded workqueue instead of mutex to serialize work
(Venkatesh)
---
drivers/scsi/virtio_scsi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c52bb5d..71b0091 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -120,6 +120,8 @@ struct virtio_scsi {
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
+static struct workqueue_struct *virtscsi_scan_wq;
+
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
{
@@ -404,7 +406,7 @@ static void virtscsi_complete_event(struct virtio_scsi
*vscsi, void *buf)
struct virtio_scsi_event_node *event_node = buf;
if (!vscsi-stop_events)
- queue_work(system_freezable_wq, event_node-work);
+ queue_work(virtscsi_scan_wq, event_node-work);
}
static void virtscsi_event_done(struct virtqueue *vq)
@@ -1119,6 +1121,12 @@ static int __init init(void)
pr_err(mempool_create() for virtscsi_cmd_pool failed\n);
goto error;
}
+ virtscsi_scan_wq = create_singlethread_workqueue(virtscsi-scan);
+ if (!virtscsi_scan_wq) {
+ pr_err(create_singlethread_workqueue() for virtscsi_scan_wq
failed\n);
+ goto error;
+ }
+
ret = register_virtio_driver(virtio_scsi_driver);
if (ret 0)
goto error;
@@ -1126,6 +1134,9 @@ static int __init init(void)
return 0;
error:
+ if (virtscsi_scan_wq) {
+ destroy_workqueue(virtscsi_scan_wq);
+ }
if (virtscsi_cmd_pool) {
mempool_destroy(virtscsi_cmd_pool);
virtscsi_cmd_pool = NULL;
@@ -1142,6 +1153,7 @@ static void __exit fini(void)
unregister_virtio_driver(virtio_scsi_driver);
mempool_destroy(virtscsi_cmd_pool);
kmem_cache_destroy(virtscsi_cmd_cache);
+ destroy_workqueue(virtscsi_scan_wq);
}
module_init(init);
module_exit(fini);
--
1.9.3
Reviewed-by: Venkatesh Srinivas venkate...@google.com
-- vs;
--
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/2] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_PACKET PIO mode command.
Hi On Tue, Dec 16, 2014 at 10:19:35PM +0530, Suman Tripathi wrote: This patch addresses the issue with ATA_CMD_PACKET pio mode command for enumeration and device detection with ATAPI devices.It is the same issue as in patch www.spinics.net/lists/linux-ide/msg49092.html Signed-off-by: Suman Tripathi stripa...@apm.com Applied 1-2 to libata/for-3.18-fixes w/ Sergei's suggested edits. The patch is applied to libata/for-3.19-fixes not libata/for-3.18-fixes ?? On Mon, Jan 5, 2015 at 7:29 PM, Tejun Heo t...@kernel.org wrote: On Tue, Dec 16, 2014 at 10:19:35PM +0530, Suman Tripathi wrote: This patch addresses the issue with ATA_CMD_PACKET pio mode command for enumeration and device detection with ATAPI devices.It is the same issue as in patch www.spinics.net/lists/linux-ide/msg49092.html Signed-off-by: Suman Tripathi stripa...@apm.com Applied 1-2 to libata/for-3.18-fixes w/ Sergei's suggested edits. Thanks. -- tejun -- Thanks, with regards, Suman Tripathi CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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/2] ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_PACKET PIO mode command.
On Tue, Jan 06, 2015 at 01:51:15PM +0530, Suman Tripathi wrote: Hi On Tue, Dec 16, 2014 at 10:19:35PM +0530, Suman Tripathi wrote: This patch addresses the issue with ATA_CMD_PACKET pio mode command for enumeration and device detection with ATAPI devices.It is the same issue as in patch www.spinics.net/lists/linux-ide/msg49092.html Signed-off-by: Suman Tripathi stripa...@apm.com Applied 1-2 to libata/for-3.18-fixes w/ Sergei's suggested edits. The patch is applied to libata/for-3.19-fixes not libata/for-3.18-fixes ?? Yeap, brainfart. libata/for-3.19-fixes is the right one. Thanks. -- tejun -- 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 0/2] Add the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver.
On Tue, Jan 06, 2015 at 03:32:14PM +0530, Suman Tripathi wrote: This patch set implements the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver. Hmm... still doesn't apply to for-3.20 after pulling in for-3.19-fixes. git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-3.20 What am I doing wrong? Thanks. -- tejun -- 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] virtio-scsi: Fix the race condition in virtscsi_handle_event
On Tue, 01/06 11:35, Michael S. Tsirkin wrote:
On Tue, Jan 06, 2015 at 03:33:36PM +0800, Fam Zheng wrote:
There is a race condition in virtscsi_handle_event, when many device
hotplug/unplug events flush in quickly.
The scsi_remove_device in virtscsi_handle_transport_reset may trigger
the BUG_ON in scsi_target_reap, because the state is altered behind it,
probably by scsi_scan_host of another event. I'm able to reproduce it by
repeatedly plugging and unplugging a scsi disk with the same lun number.
To make is safe, a single thread workqueue local to the module is added
which runs the scan work. With this change, the panic goes away.
Signed-off-by: Fam Zheng f...@redhat.com
---
v2: Use a single threaded workqueue instead of mutex to serialize work
(Venkatesh)
---
drivers/scsi/virtio_scsi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c52bb5d..71b0091 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -120,6 +120,8 @@ struct virtio_scsi {
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
+static struct workqueue_struct *virtscsi_scan_wq;
+
Don't add two empty lines please.
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device
*vdev)
{
@@ -404,7 +406,7 @@ static void virtscsi_complete_event(struct virtio_scsi
*vscsi, void *buf)
struct virtio_scsi_event_node *event_node = buf;
if (!vscsi-stop_events)
- queue_work(system_freezable_wq, event_node-work);
+ queue_work(virtscsi_scan_wq, event_node-work);
}
static void virtscsi_event_done(struct virtqueue *vq)
@@ -1119,6 +1121,12 @@ static int __init init(void)
pr_err(mempool_create() for virtscsi_cmd_pool failed\n);
goto error;
}
+ virtscsi_scan_wq = create_singlethread_workqueue(virtscsi-scan);
+ if (!virtscsi_scan_wq) {
+ pr_err(create_singlethread_workqueue() for virtscsi_scan_wq
failed\n);
+ goto error;
+ }
+
ret = register_virtio_driver(virtio_scsi_driver);
if (ret 0)
goto error;
@@ -1126,6 +1134,9 @@ static int __init init(void)
return 0;
error:
+ if (virtscsi_scan_wq) {
+ destroy_workqueue(virtscsi_scan_wq);
+ }
if (virtscsi_cmd_pool) {
mempool_destroy(virtscsi_cmd_pool);
virtscsi_cmd_pool = NULL;
@@ -1142,6 +1153,7 @@ static void __exit fini(void)
unregister_virtio_driver(virtio_scsi_driver);
mempool_destroy(virtscsi_cmd_pool);
kmem_cache_destroy(virtscsi_cmd_cache);
+ destroy_workqueue(virtscsi_scan_wq);
Please destroy in reverse order of initialization:
between unregister_virtio_driver and mempool_destroy.
OK, will fix this. Thanks.
Fam
}
module_init(init);
module_exit(fini);
--
1.9.3
--
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] virtio-scsi: Fix the race condition in virtscsi_handle_event
There is a race condition in virtscsi_handle_event, when many device
hotplug/unplug events flush in quickly.
The scsi_remove_device in virtscsi_handle_transport_reset may trigger
the BUG_ON in scsi_target_reap, because the state is altered behind it,
probably by scsi_scan_host of another event. I'm able to reproduce it by
repeatedly plugging and unplugging a scsi disk with the same lun number.
To fix this, a single thread workqueue (local to the module) is added,
which makes the scan work serialized. With this change, the panic goes
away.
Signed-off-by: Fam Zheng f...@redhat.com
---
v3: Fix spacing and destroy order. (MST)
---
drivers/scsi/virtio_scsi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c52bb5d..144bb73 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -120,6 +120,7 @@ struct virtio_scsi {
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
+static struct workqueue_struct *virtscsi_scan_wq;
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
{
@@ -404,7 +405,7 @@ static void virtscsi_complete_event(struct virtio_scsi
*vscsi, void *buf)
struct virtio_scsi_event_node *event_node = buf;
if (!vscsi-stop_events)
- queue_work(system_freezable_wq, event_node-work);
+ queue_work(virtscsi_scan_wq, event_node-work);
}
static void virtscsi_event_done(struct virtqueue *vq)
@@ -1119,6 +1120,13 @@ static int __init init(void)
pr_err(mempool_create() for virtscsi_cmd_pool failed\n);
goto error;
}
+
+ virtscsi_scan_wq = create_singlethread_workqueue(virtscsi-scan);
+ if (!virtscsi_scan_wq) {
+ pr_err(create_singlethread_workqueue() for virtscsi_scan_wq
failed\n);
+ goto error;
+ }
+
ret = register_virtio_driver(virtio_scsi_driver);
if (ret 0)
goto error;
@@ -1126,6 +1134,9 @@ static int __init init(void)
return 0;
error:
+ if (virtscsi_scan_wq) {
+ destroy_workqueue(virtscsi_scan_wq);
+ }
if (virtscsi_cmd_pool) {
mempool_destroy(virtscsi_cmd_pool);
virtscsi_cmd_pool = NULL;
@@ -1140,6 +1151,7 @@ error:
static void __exit fini(void)
{
unregister_virtio_driver(virtio_scsi_driver);
+ destroy_workqueue(virtscsi_scan_wq);
mempool_destroy(virtscsi_cmd_pool);
kmem_cache_destroy(virtscsi_cmd_cache);
}
--
1.9.3
--
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 07/22] [SCSI] mpt2sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081
For any SCSI command, if the driver receives IOC status = SCSI_IOC_TERMINATED
and log info = 0x32010081
then that command will be completed with DID_RESET host status.
The definition of this log info value is Virtual IO has failed and has to be
retried.
Firmware will provide this log info value with IOC Status
SCSI_IOC_TERMINATED, whenever a drive (with is a part of a volume)
is pulled and pushed back within some minimal delay. With this log info
value, firmware informs the driver to retry the failed IO command
infinite times, so to provide some time for the firmware to discover
the reinserted drive successfully instated of just retrying failed
command for five times( doesn't giving enough time for firmware to
complete the drive discovery) and failing the IO permanently even
though drive came back successfully.
Signed-off-by: Sreekanth Reddy sreekanth.re...@avagotech.com
---
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 38acb91..c6bb136 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -4574,6 +4574,10 @@ _scsih_io_done(struct MPT2SAS_ADAPTER *ioc, u16 smid, u8
msix_index, u32 reply)
scmd-result = DID_TRANSPORT_DISRUPTED 16;
goto out;
}
+ if (log_info == 0x32010081) {
+ scmd-result = DID_RESET 16;
+ break;
+ }
scmd-result = DID_SOFT_ERROR 16;
break;
case MPI2_IOCSTATUS_SCSI_TASK_TERMINATED:
--
2.0.2
--
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 0/2] Add the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver.
On Tue, Jan 06, 2015 at 07:10:31PM +0530, Suman Tripathi wrote: Hi , For more info here is the git log output before applying the patch. git log commit b84b25cb0900b99b28c742dd33101be779f58259 Merge: 0628ee7 36aae28 Author: Tejun Heo t...@kernel.org Date: Tue Jan 6 07:48:24 2015 -0500 Merge branch 'for-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/g Pull to receive the following two ahci_xgene fixes for the planned xgene PMP support patches. 5c0b8e0de76a8 (ahci_xgene: Fix the endianess issue in APM X-Gene SoC AHCI 1102407bb714d (ahci_xgene: Fix the DMA state machine lockup for the ATA_CM Signed-off-by: Tejun Heo t...@kernel.org commit 36aae28e3df4127e296f2680d65cb6310ce61021 Author: Andy Shevchenko andriy.shevche...@linux.intel.com Date: Fri Dec 12 17:16:31 2014 +0200 libata: export ata_get_cmd_descript() The driver sata_dwc_460ex is using this symbol. To build it as a module we have to have the symbol exported. This patch adds Broken pipe Ah, this was me being stupid. I was using the old patches. Sorry about that. Applied to libata/for-3.20. Thanks. -- tejun -- 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 0/2] Add the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver.
Hi , On Tue, Jan 06, 2015 at 03:32:14PM +0530, Suman Tripathi wrote: This patch set implements the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver. Hmm... still doesn't apply to for-3.20 after pulling in for-3.19-fixes. git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-3.20 What am I doing wrong? I just again cloned git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git switched to remotes/origin/for-3.20 git apply 0001-ahci_xgene-Implement-the-xgene_ahci_poll_reg_val-to-.patch git apply 0002-ahci_xgene-Implement-the-workaround-to-support-PMP-e.patch Even tried with patch -p1 0001-ahci_xgene-Implement-the-xgene_ahci_poll_reg_val-to-.patch patch -p1 0002-ahci_xgene-Implement-the-workaround-to-support-PMP-e.patch Both are working fine. Not sure what's wrong with your environment. On Tue, Jan 6, 2015 at 6:22 PM, Tejun Heo t...@kernel.org wrote: On Tue, Jan 06, 2015 at 03:32:14PM +0530, Suman Tripathi wrote: This patch set implements the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver. Hmm... still doesn't apply to for-3.20 after pulling in for-3.19-fixes. git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-3.20 What am I doing wrong? Thanks. -- tejun -- Thanks, with regards, Suman Tripathi CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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 0/2] Add the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver.
Hi , For more info here is the git log output before applying the patch. git log commit b84b25cb0900b99b28c742dd33101be779f58259 Merge: 0628ee7 36aae28 Author: Tejun Heo t...@kernel.org Date: Tue Jan 6 07:48:24 2015 -0500 Merge branch 'for-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/g Pull to receive the following two ahci_xgene fixes for the planned xgene PMP support patches. 5c0b8e0de76a8 (ahci_xgene: Fix the endianess issue in APM X-Gene SoC AHCI 1102407bb714d (ahci_xgene: Fix the DMA state machine lockup for the ATA_CM Signed-off-by: Tejun Heo t...@kernel.org commit 36aae28e3df4127e296f2680d65cb6310ce61021 Author: Andy Shevchenko andriy.shevche...@linux.intel.com Date: Fri Dec 12 17:16:31 2014 +0200 libata: export ata_get_cmd_descript() The driver sata_dwc_460ex is using this symbol. To build it as a module we have to have the symbol exported. This patch adds Broken pipe On Tue, Jan 6, 2015 at 7:06 PM, Suman Tripathi stripa...@apm.com wrote: Hi , On Tue, Jan 06, 2015 at 03:32:14PM +0530, Suman Tripathi wrote: This patch set implements the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver. Hmm... still doesn't apply to for-3.20 after pulling in for-3.19-fixes. git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-3.20 What am I doing wrong? I just again cloned git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git switched to remotes/origin/for-3.20 git apply 0001-ahci_xgene-Implement-the-xgene_ahci_poll_reg_val-to-.patch git apply 0002-ahci_xgene-Implement-the-workaround-to-support-PMP-e.patch Even tried with patch -p1 0001-ahci_xgene-Implement-the-xgene_ahci_poll_reg_val-to-.patch patch -p1 0002-ahci_xgene-Implement-the-workaround-to-support-PMP-e.patch Both are working fine. Not sure what's wrong with your environment. On Tue, Jan 6, 2015 at 6:22 PM, Tejun Heo t...@kernel.org wrote: On Tue, Jan 06, 2015 at 03:32:14PM +0530, Suman Tripathi wrote: This patch set implements the PMP support for APM X-Gene SoC AHCI SATA Host Controller driver. Hmm... still doesn't apply to for-3.20 after pulling in for-3.19-fixes. git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-3.20 What am I doing wrong? Thanks. -- tejun -- Thanks, with regards, Suman Tripathi -- Thanks, with regards, Suman Tripathi CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- 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
[Bug 90601] panic on write to 3ware raid array
https://bugzilla.kernel.org/show_bug.cgi?id=90601 --- Comment #5 from mer...@liao.homelinux.org --- Created attachment 162641 -- https://bugzilla.kernel.org/attachment.cgi?id=162641action=edit syslog before crash -- You are receiving this mail because: You are the assignee for the bug. -- 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] virtio-scsi: Fix the race condition in virtscsi_handle_event
On Tue, Jan 06, 2015 at 09:25:05PM +0800, Fam Zheng wrote:
There is a race condition in virtscsi_handle_event, when many device
hotplug/unplug events flush in quickly.
The scsi_remove_device in virtscsi_handle_transport_reset may trigger
the BUG_ON in scsi_target_reap, because the state is altered behind it,
probably by scsi_scan_host of another event. I'm able to reproduce it by
repeatedly plugging and unplugging a scsi disk with the same lun number.
To fix this, a single thread workqueue (local to the module) is added,
which makes the scan work serialized.
All wqs are serialized:
Note that the flag WQ_NON_REENTRANT no longer exists as all workqueues
are now non-reentrant - any work item is guaranteed to be executed by
at most one worker system-wide at any given time.
With this change, the panic goes
away.
I think the commit log is confusing.
serialization can not be an issue.
At a guess, what happens is two events are processed out of order,
so unplug bypasses another event, causing use after free errors.
With this in mind, your patch will indeed fix the issue, but
a better fix would be to call alloc_ordered_workqueue.
Signed-off-by: Fam Zheng f...@redhat.com
---
v3: Fix spacing and destroy order. (MST)
---
drivers/scsi/virtio_scsi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c52bb5d..144bb73 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -120,6 +120,7 @@ struct virtio_scsi {
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
+static struct workqueue_struct *virtscsi_scan_wq;
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
{
@@ -404,7 +405,7 @@ static void virtscsi_complete_event(struct virtio_scsi
*vscsi, void *buf)
struct virtio_scsi_event_node *event_node = buf;
if (!vscsi-stop_events)
- queue_work(system_freezable_wq, event_node-work);
+ queue_work(virtscsi_scan_wq, event_node-work);
This means wq isn't freezable anymore.
}
static void virtscsi_event_done(struct virtqueue *vq)
@@ -1119,6 +1120,13 @@ static int __init init(void)
pr_err(mempool_create() for virtscsi_cmd_pool failed\n);
goto error;
}
+
+ virtscsi_scan_wq = create_singlethread_workqueue(virtscsi-scan);
+ if (!virtscsi_scan_wq) {
+ pr_err(create_singlethread_workqueue() for virtscsi_scan_wq
failed\n);
+ goto error;
+ }
+
Documentation/workqueue.txt says:
alloc_workqueue() allocates a wq. The original create_*workqueue()
functions are deprecated and scheduled for removal. alloc_workqueue()
takes three arguments - @name, @flags and @max_active.
ret = register_virtio_driver(virtio_scsi_driver);
if (ret 0)
goto error;
@@ -1126,6 +1134,9 @@ static int __init init(void)
return 0;
error:
+ if (virtscsi_scan_wq) {
+ destroy_workqueue(virtscsi_scan_wq);
+ }
Single line, shouldn't use {} here.
if (virtscsi_cmd_pool) {
mempool_destroy(virtscsi_cmd_pool);
virtscsi_cmd_pool = NULL;
@@ -1140,6 +1151,7 @@ error:
static void __exit fini(void)
{
unregister_virtio_driver(virtio_scsi_driver);
+ destroy_workqueue(virtscsi_scan_wq);
mempool_destroy(virtscsi_cmd_pool);
kmem_cache_destroy(virtscsi_cmd_cache);
}
--
1.9.3
--
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
[Bug 90601] panic on write to 3ware raid array
https://bugzilla.kernel.org/show_bug.cgi?id=90601 --- Comment #4 from mer...@liao.homelinux.org --- Hi Kashyap, 1. I enabled CONFIG_DMA_API_DEBUG , strangely enough after enabling it I couldn't even boot into the system anymore because it would crash when trying to access the root partition (after the kernel image was loaded). I think the problem was the initial xfs_repair that is done on bootup. So I took the same kernel and copied it to a USB device and booted from that on the same host into a system that also resides on the USB disk. Then I mounted /dev/sda (which is the first device on the raid controller which is the root partition). Then I tried to reproduce the panic with the simple dd that was used before without success. I then compiled the kernel sources with -j25 on the mounted root partition 2 times without any problems. Then I chrooted onto that partition and did the same and could finally reproduce the crash. I am not sure if that backtrace is more useful though. I have also attached the /var/log/messages but of course that crash wasn't saved in it. I also added my kernel config. -- You are receiving this mail because: You are the assignee for the bug. -- 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
[Bug 90601] panic on write to 3ware raid array
https://bugzilla.kernel.org/show_bug.cgi?id=90601 --- Comment #6 from mer...@liao.homelinux.org --- Created attachment 162651 -- https://bugzilla.kernel.org/attachment.cgi?id=162651action=edit backtrace with CONFIG_DMA_API_DEBUG enabled -- You are receiving this mail because: You are the assignee for the bug. -- 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
[target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?
tree: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git nvme_of head: 40d8c11927282d59855d645b35798edd97828da5 commit: 40d8c11927282d59855d645b35798edd97828da5 [3/3] nvme_of: Initial skeleton commit reproduce: # apt-get install sparse git checkout 40d8c11927282d59855d645b35798edd97828da5 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by ) drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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 target] nvme_of: nvme_of_fabric_configfs can be static
drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static? Signed-off-by: Fengguang Wu fengguang...@intel.com --- nvme_of_configfs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/nvme_of/nvme_of_configfs.c b/drivers/target/nvme_of/nvme_of_configfs.c index c34603c..43a3abc1 100644 --- a/drivers/target/nvme_of/nvme_of_configfs.c +++ b/drivers/target/nvme_of/nvme_of_configfs.c @@ -22,7 +22,7 @@ #include nvme_of_fabric.h /* Local pointer to allocated TCM configfs fabric module */ -struct target_fabric_configfs *nvme_of_fabric_configfs; +static struct target_fabric_configfs *nvme_of_fabric_configfs; static struct se_node_acl *nvme_of_make_nodeacl( struct se_portal_group *se_tpg, -- 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] vhost-scsi: Add missing virtio-scsi - TCM attribute conversion
On Tue, Jan 06, 2015 at 08:18:05PM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
While looking at hch's recent conversion to drop the MSG_*_TAG
definitions, I noticed a long standing bug in vhost-scsi where
the VIRTIO_SCSI_S_* attribute definitions where incorrectly
being passed directly into target_submit_cmd_map_sgls().
This patch adds the missing virtio-scsi to TCM/SAM task attribute
conversion.
Cc: Christoph Hellwig h...@lst.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
Cc stable as well?
---
drivers/vhost/scsi.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 01c01cb..d695b16 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -911,6 +911,23 @@ vhost_scsi_map_iov_to_prot(struct tcm_vhost_cmd *cmd,
return 0;
}
+static int vhost_scsi_to_tcm_attr(int attr)
+{
+ switch (attr) {
+ case VIRTIO_SCSI_S_SIMPLE:
+ return TCM_SIMPLE_TAG;
+ case VIRTIO_SCSI_S_ORDERED:
+ return TCM_ORDERED_TAG;
+ case VIRTIO_SCSI_S_HEAD:
+ return TCM_HEAD_TAG;
+ case VIRTIO_SCSI_S_ACA:
+ return TCM_ACA_TAG;
+ default:
+ break;
+ }
+ return TCM_SIMPLE_TAG;
+}
+
static void tcm_vhost_submission_work(struct work_struct *work)
{
struct tcm_vhost_cmd *cmd =
@@ -936,9 +953,10 @@ static void tcm_vhost_submission_work(struct work_struct
*work)
rc = target_submit_cmd_map_sgls(se_cmd, tv_nexus-tvn_se_sess,
cmd-tvc_cdb, cmd-tvc_sense_buf[0],
cmd-tvc_lun, cmd-tvc_exp_data_len,
- cmd-tvc_task_attr, cmd-tvc_data_direction,
- TARGET_SCF_ACK_KREF, sg_ptr, cmd-tvc_sgl_count,
- NULL, 0, sg_prot_ptr, cmd-tvc_prot_sgl_count);
+ vhost_scsi_to_tcm_attr(cmd-tvc_task_attr),
+ cmd-tvc_data_direction, TARGET_SCF_ACK_KREF,
+ sg_ptr, cmd-tvc_sgl_count, NULL, 0, sg_prot_ptr,
+ cmd-tvc_prot_sgl_count);
if (rc 0) {
transport_send_check_condition_and_sense(se_cmd,
TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, 0);
--
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] vhost-scsi: Add missing virtio-scsi - TCM attribute conversion
On Tue, 2015-01-06 at 23:07 +0200, Michael S. Tsirkin wrote: On Tue, Jan 06, 2015 at 08:18:05PM +, Nicholas A. Bellinger wrote: From: Nicholas Bellinger n...@linux-iscsi.org While looking at hch's recent conversion to drop the MSG_*_TAG definitions, I noticed a long standing bug in vhost-scsi where the VIRTIO_SCSI_S_* attribute definitions where incorrectly being passed directly into target_submit_cmd_map_sgls(). This patch adds the missing virtio-scsi to TCM/SAM task attribute conversion. Cc: Christoph Hellwig h...@lst.de Cc: Michael S. Tsirkin m...@redhat.com Cc: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org Cc stable as well? That makes sense here, but anything v3.19-rc will need to use the old MSG_*_TAG defines. Will fix up that once Greg-KH complains about the compile failure(s). --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: block: remove artifical max_hw_sectors cap
On Tue, 2015-01-06 at 14:39 -0800, Nicholas A. Bellinger wrote: On Tue, 2014-12-23 at 09:28 +0100, Christoph Hellwig wrote: On Mon, Dec 22, 2014 at 11:31:53AM +0100, Stefan Priebe - Profihost AG wrote: Hi, since the below patch i've some problems with iscsi. The LIO based iscsi Server is full of messages like this: SCSI OP 2ah with too big sectors 8344 exceeds fabric_max_sectors: 8192 And the client says: Buffer I/O error on device sdd, logical block 38861907 lost page write due to I/O error on sdd May be some code fixes for iscsi client is missing? No, the problem seems that the the target is enforcing a size limit without communicating it through the block limits EVPD page. Nic, can you fix LIO to expose the proper max xfer size? The fabric_max_sectors=8192 value is already being exposed by target in block limits EVPD as MAXIMUM TRANSFER LENGTH. I'm guessing that since the host side support was not added until June 2014 in commit bcdb247c by MKP, Stefan is likely using an earlier initiator that is not honoring this value. However, this same issue has been reported elsewhere [1] with an MSFT FC host sending I/Os of 8 MB that also doesn't appear to honor block limits MAXIMUM TRANSFER LENGTH either. So that said, I think it's about time to go ahead and drop the arbitrary limitation of fabric_max_sectors, and simply enforce a sane limit (eg: not UINT_MAX) for hw_max_sectors. The only limitations for backends that I'm aware of is the FILEIO FD_MAX_BYTES limit for the number of iovecs per vfs_[writev,readv] call, and for IBLOCK what queue_max_hw_sectors() reports for raw block make_request() based drivers that aren't able to ... split large I/O requests into smaller ones. I'll put together a patch soon to drop the fabric_max_sectors stuff, and use the existing hw_max_sectors to enforce any backend specific I/O size limitations. --nab [1] http://www.spinics.net/lists/target-devel/msg08024.html -- To unsubscribe from this list: send the line unsubscribe target-devel 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: T10-PI: Getting failed tag info
Christoph == Christoph Hellwig h...@infradead.org writes: Christoph But those extensions require new structures to pass in the PI Christoph info anyway.. Yep. But I still don't see why that warrants having a parallel error passing infrastructure in the kernel to handle data integrity errors. What does that buy us? I agree with not leaking any of the new errors to unsuspecting applications and only passing them out if the caller has explicitly enabled DIX. -- Martin K. Petersen Oracle Linux Engineering -- 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 06/22] [SCSI] mpt2sas, mpt3sas: Removing uppper boundary restriction for the module parameter max_sgl_entries
Sreekanth == Sreekanth Reddy sreekanth.re...@avagotech.com writes: Sreekanth I though to warn the user that the module parameter Sreekanth max_sgl_entries value what they provided is greater than the Sreekanth kernel defined SCSI_MAX_SG_SEGMENTS, whether if this module Sreekanth parameter value is greater than or less than the Sreekanth SCSI_MAX_SG_CHAIN_SEGMENTS. Also I thought, user may confuse Sreekanth if see observes SCSI_MAX_SG_CHAIN_SEGMENTS value instead of Sreekanth max_sgl_entries value in the warning message. I would just prefer to see the value that is in effect. I know what I provided as override value. At the very least print a warning if you subsequently clamp the value to MAX_SG_CHAIN_SEGMENTS. Requested number of segments %u is bigger than kernel max %u. -- Martin K. Petersen Oracle Linux Engineering -- 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 6/8] megaraid_sas : Reserve commands for IOCTLs and internal DCMDs
Sumit == sumit.sax...@avagotech.com writes: Sumit 1)For fusion adapters, limited reserved frames for non SCSI Sumit commands to 8(3 for parallel IOCTLs + 5 for driver's internal Sumit DCMDs). Earlier reserved commands for non SCSI IO frames was set Sumit to 32, so with this implementation, increased per controller Sumit can_queue. Behavior of MFI controllers will remain unchanged. This whole reserved commands business seems a bit brittle to me. But I don't have any particular objections to the code. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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 8/8] megaraid_sas : Driver version update
Sumit == sumit.sax...@avagotech.com writes: Sumit Update megaraid_sas driver version. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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: [LSF/MM ATTEND] discuss blk-mq related to DM-multipath and status of XCOPY
Mike == Mike Snitzer snit...@redhat.com writes: Mike Another topic we need to come to terms with is the state of XCOPY Mike (whether the initial approach needs further work, etc) -- Mikulas Mike Patocka reworked aspects of Martin's initial approach but it Mike hasn't progressed upstream: Yeah, I'd like to get that sorted out too. It got stuck on running out of request flags and that requires some block layer surgery. I'll try to get that piece done right away for 3.20 so we can get xcopy into 3.21. -- Martin K. Petersen Oracle Linux Engineering -- 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: [dm-devel] [LSF/MM ATTEND] discuss blk-mq related to DM-multipath and status of XCOPY
Hannes == Hannes Reinecke h...@suse.de writes: Hannes Yep. That definitely needs to be discussed. Especially we'd Hannes need to discuss how to handle exceptions, seeing that XCOPY Hannes might fail basically at any time. Like any SCSI command :) -- Martin K. Petersen Oracle Linux Engineering -- 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/8] megaraid_sas : Endianness related bug fixes and code optimization
Sumit == sumit.sax...@avagotech.com writes: Sumit This patch addresses below issues- 1) Few endianness bug fixes. Sumit 2) Break the iteration after (MAX_LOGICAL_DRIVES_EXT - 1)), Sumit instead of MAX_LOGICAL_DRIVES_EXT. 3) Optimization in MFI INIT Sumit frame before firing. 4) MFI IO frame should be 256bytes Sumit aligned. Code is optimized to reduce the size of frame for fusion Sumit adapters and make the MFI frame size calculation a bit Sumit transparent and readable. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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 3/8] megaraid_sas : Fix the problem of non-existing VD exposed to host
Sumit == sumit.sax...@avagotech.com writes: Sumit For legacy firmware(64 VD firmware), invalidates LD(by setting LD Sumit value to 0xff) in LdTgtIdtoLd[] array for device index beyond Sumit 127, so that invalid LD(0xff) value should be returned beyond Sumit device index beyond 127. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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 5/8] megaraid_sas : Complete outstanding IOCTLs before killing adapter
Sumit == sumit.sax...@avagotech.com writes: Sumit Driver calls megasas_complete_cmd() to call wake_up() for each Sumit MFI frame that was issued through the ioctl() interface prior to Sumit the kill adapter. This ensures userspace ioctl() system calls Sumit issued just before a kill adapter don't get stuck in wait state Sumit and IOCTLs are returned to application. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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 7/8] megaraid_sas : Remove redundant code of memset load_balance_info to zero
Sumit == sumit.sax...@avagotech.com writes: Sumit struct fusion_context *fusion is already memset to '0', so remove Sumit redundant code of meset fusion-load_balance_info to '0'. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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] virtio-scsi: Fix the race condition in virtscsi_handle_event
On Tue, 01/06 16:54, Michael S. Tsirkin wrote:
On Tue, Jan 06, 2015 at 09:25:05PM +0800, Fam Zheng wrote:
There is a race condition in virtscsi_handle_event, when many device
hotplug/unplug events flush in quickly.
The scsi_remove_device in virtscsi_handle_transport_reset may trigger
the BUG_ON in scsi_target_reap, because the state is altered behind it,
probably by scsi_scan_host of another event. I'm able to reproduce it by
repeatedly plugging and unplugging a scsi disk with the same lun number.
To fix this, a single thread workqueue (local to the module) is added,
which makes the scan work serialized.
All wqs are serialized:
Note that the flag WQ_NON_REENTRANT no longer exists as all workqueues
are now non-reentrant - any work item is guaranteed to be executed by
at most one worker system-wide at any given time.
With this change, the panic goes
away.
I think the commit log is confusing.
serialization can not be an issue.
At a guess, what happens is two events are processed out of order,
so unplug bypasses another event, causing use after free errors.
It's not just order, it's race. A wq item is only serialized to itself - that's
what non-reentrant means here. But when there are two events, there are *two*
wq items, which do run concurrently by system_freezable_wq.
With this in mind, your patch will indeed fix the issue, but
a better fix would be to call alloc_ordered_workqueue.
alloc_ordered_workqueue does fix it, but still by serializing all the wq items.
By definition, create_singlethread_workqueue only adds a WQ_MEM_RECLAIM flag,
which is not related to the question. They are the same other than that.
Signed-off-by: Fam Zheng f...@redhat.com
---
v3: Fix spacing and destroy order. (MST)
---
drivers/scsi/virtio_scsi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c52bb5d..144bb73 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -120,6 +120,7 @@ struct virtio_scsi {
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
+static struct workqueue_struct *virtscsi_scan_wq;
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device
*vdev)
{
@@ -404,7 +405,7 @@ static void virtscsi_complete_event(struct virtio_scsi
*vscsi, void *buf)
struct virtio_scsi_event_node *event_node = buf;
if (!vscsi-stop_events)
- queue_work(system_freezable_wq, event_node-work);
+ queue_work(virtscsi_scan_wq, event_node-work);
This means wq isn't freezable anymore.
Maybe add WQ_FREEZABLE back to the flags then. I'll see.
}
static void virtscsi_event_done(struct virtqueue *vq)
@@ -1119,6 +1120,13 @@ static int __init init(void)
pr_err(mempool_create() for virtscsi_cmd_pool failed\n);
goto error;
}
+
+ virtscsi_scan_wq = create_singlethread_workqueue(virtscsi-scan);
+ if (!virtscsi_scan_wq) {
+ pr_err(create_singlethread_workqueue() for virtscsi_scan_wq
failed\n);
+ goto error;
+ }
+
Documentation/workqueue.txt says:
alloc_workqueue() allocates a wq. The original create_*workqueue()
functions are deprecated and scheduled for removal. alloc_workqueue()
takes three arguments - @name, @flags and @max_active.
OK, let's use alloc_ordered_workqueue.
ret = register_virtio_driver(virtio_scsi_driver);
if (ret 0)
goto error;
@@ -1126,6 +1134,9 @@ static int __init init(void)
return 0;
error:
+ if (virtscsi_scan_wq) {
+ destroy_workqueue(virtscsi_scan_wq);
+ }
Single line, shouldn't use {} here.
OK.
Fam
if (virtscsi_cmd_pool) {
mempool_destroy(virtscsi_cmd_pool);
virtscsi_cmd_pool = NULL;
@@ -1140,6 +1151,7 @@ error:
static void __exit fini(void)
{
unregister_virtio_driver(virtio_scsi_driver);
+ destroy_workqueue(virtscsi_scan_wq);
mempool_destroy(virtscsi_cmd_pool);
kmem_cache_destroy(virtscsi_cmd_cache);
}
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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 07/22] [SCSI] mpt2sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081
Sreekanth == Sreekanth Reddy sreekanth.re...@avagotech.com writes: Sreekanth For any SCSI command, if the driver receives IOC status = Sreekanth SCSI_IOC_TERMINATED and log info = 0x32010081 then that Sreekanth command will be completed with DID_RESET host status. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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 4/8] megaraid_sas : Disable interrupt_mask before enabling hardware interrupts
Sumit == sumit.sax...@avagotech.com writes: Sumit Update driver mask_interrupts before enable/disable hardware Sumit interrupt in order to avoid missing interrupts because of Sumit mask_interrupts still set to 1 and hardware interrupts are Sumit enabled. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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/8] megaraid_sas : Support for secure JBOD
Sumit == sumit.sax...@avagotech.com writes: Sumit This patch will add support for Secure Encrypting Drives(SED) in Sumit JBOD mode. below are the key points- 1) If Firmware supports SED Sumit JBOD, all non Read Write commands to JBODs will be sent via Sumit Firmware path and Read write commands to JBOD will be sent via Sumit fastpath. 2) If firmware does not support SED JBOD, driver will Sumit fall back to old design .i.e send all JBOD IOs via fastpath. Reviewed-by: Martin K. Petersen martin.peter...@oracle.com -- Martin K. Petersen Oracle Linux Engineering -- 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/2] target: Drop left-over fabric_max_sectors attribute
From: Nicholas Bellinger n...@linux-iscsi.org
Now that fabric_max_sectors is no longer used to enforce the maximum
I/O size, go ahead and drop it's left-over usage in target-core and
associated backend drivers.
Cc: Christoph Hellwig h...@lst.de
Cc: Roland Dreier rol...@purestorage.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/target/target_core_device.c | 46 ---
drivers/target/target_core_file.c | 1 -
drivers/target/target_core_iblock.c | 1 -
drivers/target/target_core_rd.c | 1 -
drivers/target/target_core_user.c | 1 -
include/target/target_core_backend.h | 1 -
include/target/target_core_backend_configfs.h | 2 --
include/target/target_core_base.h | 3 --
8 files changed, 56 deletions(-)
diff --git a/drivers/target/target_core_device.c
b/drivers/target/target_core_device.c
index ee4b89f..58f49ff 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -1103,51 +1103,6 @@ int se_dev_set_queue_depth(struct se_device *dev, u32
queue_depth)
}
EXPORT_SYMBOL(se_dev_set_queue_depth);
-int se_dev_set_fabric_max_sectors(struct se_device *dev, u32
fabric_max_sectors)
-{
- int block_size = dev-dev_attrib.block_size;
-
- if (dev-export_count) {
- pr_err(dev[%p]: Unable to change SE Device
-fabric_max_sectors while export_count is %d\n,
- dev, dev-export_count);
- return -EINVAL;
- }
- if (!fabric_max_sectors) {
- pr_err(dev[%p]: Illegal ZERO value for
-fabric_max_sectors\n, dev);
- return -EINVAL;
- }
- if (fabric_max_sectors DA_STATUS_MAX_SECTORS_MIN) {
- pr_err(dev[%p]: Passed fabric_max_sectors: %u less than
-DA_STATUS_MAX_SECTORS_MIN: %u\n, dev,
fabric_max_sectors,
- DA_STATUS_MAX_SECTORS_MIN);
- return -EINVAL;
- }
- if (fabric_max_sectors DA_STATUS_MAX_SECTORS_MAX) {
- pr_err(dev[%p]: Passed fabric_max_sectors: %u
-greater than DA_STATUS_MAX_SECTORS_MAX:
-%u\n, dev, fabric_max_sectors,
- DA_STATUS_MAX_SECTORS_MAX);
- return -EINVAL;
- }
- /*
-* Align max_sectors down to PAGE_SIZE to follow
transport_allocate_data_tasks()
-*/
- if (!block_size) {
- block_size = 512;
- pr_warn(Defaulting to 512 for zero block_size\n);
- }
- fabric_max_sectors = se_dev_align_max_sectors(fabric_max_sectors,
- block_size);
-
- dev-dev_attrib.fabric_max_sectors = fabric_max_sectors;
- pr_debug(dev[%p]: SE Device max_sectors changed to %u\n,
- dev, fabric_max_sectors);
- return 0;
-}
-EXPORT_SYMBOL(se_dev_set_fabric_max_sectors);
-
int se_dev_set_optimal_sectors(struct se_device *dev, u32 optimal_sectors)
{
if (dev-export_count) {
@@ -1553,7 +1508,6 @@ struct se_device *target_alloc_device(struct se_hba *hba,
const char *name)
dev-dev_attrib.unmap_granularity_alignment =
DA_UNMAP_GRANULARITY_ALIGNMENT_DEFAULT;
dev-dev_attrib.max_write_same_len = DA_MAX_WRITE_SAME_LEN;
- dev-dev_attrib.fabric_max_sectors = DA_FABRIC_MAX_SECTORS;
xcopy_lun = dev-xcopy_lun;
xcopy_lun-lun_se_dev = dev;
diff --git a/drivers/target/target_core_file.c
b/drivers/target/target_core_file.c
index c2aea09..8f11dcf 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -959,7 +959,6 @@ static struct configfs_attribute
*fileio_backend_dev_attrs[] = {
fileio_dev_attrib_hw_block_size.attr,
fileio_dev_attrib_block_size.attr,
fileio_dev_attrib_hw_max_sectors.attr,
- fileio_dev_attrib_fabric_max_sectors.attr,
fileio_dev_attrib_optimal_sectors.attr,
fileio_dev_attrib_hw_queue_depth.attr,
fileio_dev_attrib_queue_depth.attr,
diff --git a/drivers/target/target_core_iblock.c
b/drivers/target/target_core_iblock.c
index 5795cd8..78346b8 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -883,7 +883,6 @@ static struct configfs_attribute
*iblock_backend_dev_attrs[] = {
iblock_dev_attrib_hw_block_size.attr,
iblock_dev_attrib_block_size.attr,
iblock_dev_attrib_hw_max_sectors.attr,
- iblock_dev_attrib_fabric_max_sectors.attr,
iblock_dev_attrib_optimal_sectors.attr,
iblock_dev_attrib_hw_queue_depth.attr,
iblock_dev_attrib_queue_depth.attr,
diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c
index 60ebd17..98e83ac 100644
--- a/drivers/target/target_core_rd.c
+++
[PATCH 1/2] target: Don't arbitrary limit I/O size to fabric_max_sectors
From: Nicholas Bellinger n...@linux-iscsi.org
This patch avoids the arbitrary limiting of I/O size to fabric_max_sectors,
which currently has a hardcoded max of 8192 (4 MB for 512 byte sector
devices).
This is problematic because Linux initiators have only recently started
to honor block limits MAXIMUM TRANSFER LENGTH, and other non-Linux based
initiators (eg: Fibre Channel) can also generate I/Os larger than 4 MB.
Currently when this happens, the following message will appear on the
target resulting in I/Os being returned with non recoverable status:
SCSI OP 28h with too big sectors 16384 exceeds fabric_max_sectors: 8192
Instead, use the existing hw_max_sectors value to determine the maximum
sized I/O the backend is capable of supporting. Also, change IBLOCK
backend driver to set hw_max_sectors based on queue_max_hw_sectors(),
instead of UINT_MAX.
Reported-by: Lance Gropper lance.grop...@qosserver.com
Reported-by: Stefan Priebe s.pri...@profihost.ag
Cc: Christoph Hellwig h...@lst.de
Cc: Roland Dreier rol...@purestorage.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/target/target_core_device.c | 8
drivers/target/target_core_iblock.c | 2 +-
drivers/target/target_core_sbc.c| 7 ---
drivers/target/target_core_spc.c| 5 +
4 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/target/target_core_device.c
b/drivers/target/target_core_device.c
index 7653cfb..ee4b89f 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -1156,10 +1156,10 @@ int se_dev_set_optimal_sectors(struct se_device *dev,
u32 optimal_sectors)
dev, dev-export_count);
return -EINVAL;
}
- if (optimal_sectors dev-dev_attrib.fabric_max_sectors) {
+ if (optimal_sectors dev-dev_attrib.hw_max_sectors) {
pr_err(dev[%p]: Passed optimal_sectors %u cannot be
-greater than fabric_max_sectors: %u\n, dev,
- optimal_sectors, dev-dev_attrib.fabric_max_sectors);
+greater than hw_max_sectors: %u\n, dev,
+ optimal_sectors, dev-dev_attrib.hw_max_sectors);
return -EINVAL;
}
@@ -1554,7 +1554,6 @@ struct se_device *target_alloc_device(struct se_hba *hba,
const char *name)
DA_UNMAP_GRANULARITY_ALIGNMENT_DEFAULT;
dev-dev_attrib.max_write_same_len = DA_MAX_WRITE_SAME_LEN;
dev-dev_attrib.fabric_max_sectors = DA_FABRIC_MAX_SECTORS;
- dev-dev_attrib.optimal_sectors = DA_FABRIC_MAX_SECTORS;
xcopy_lun = dev-xcopy_lun;
xcopy_lun-lun_se_dev = dev;
@@ -1595,6 +1594,7 @@ int target_configure_device(struct se_device *dev)
dev-dev_attrib.hw_max_sectors =
se_dev_align_max_sectors(dev-dev_attrib.hw_max_sectors,
dev-dev_attrib.hw_block_size);
+ dev-dev_attrib.optimal_sectors = dev-dev_attrib.hw_max_sectors;
dev-dev_index = scsi_get_new_index(SCSI_DEVICE_INDEX);
dev-creation_time = get_jiffies_64();
diff --git a/drivers/target/target_core_iblock.c
b/drivers/target/target_core_iblock.c
index 3efff94..5795cd8 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -124,7 +124,7 @@ static int iblock_configure_device(struct se_device *dev)
q = bdev_get_queue(bd);
dev-dev_attrib.hw_block_size = bdev_logical_block_size(bd);
- dev-dev_attrib.hw_max_sectors = UINT_MAX;
+ dev-dev_attrib.hw_max_sectors = queue_max_hw_sectors(q);
dev-dev_attrib.hw_queue_depth = q-nr_requests;
/*
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 11bea19..9fe70ed 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -954,13 +954,6 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
if (cmd-se_cmd_flags SCF_SCSI_DATA_CDB) {
unsigned long long end_lba;
- if (sectors dev-dev_attrib.fabric_max_sectors) {
- printk_ratelimited(KERN_ERR SCSI OP %02xh with too
-big sectors %u exceeds fabric_max_sectors:
-%u\n, cdb[0], sectors,
- dev-dev_attrib.fabric_max_sectors);
- return TCM_INVALID_CDB_FIELD;
- }
if (sectors dev-dev_attrib.hw_max_sectors) {
printk_ratelimited(KERN_ERR SCSI OP %02xh with too
big sectors %u exceeds backend
hw_max_sectors:
diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index 1307600..4c71657 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -505,7 +505,6 @@ static sense_reason_t
spc_emulate_evpd_b0(struct se_cmd *cmd, unsigned char *buf)
Re: RFC: should we deprecate unmaintained isa-only drivers?
On Tuesday 30 December 2014 17:06:16 Christoph Hellwig wrote: We've got a few very old, isa-only SCSI HBA drivers in the tree. Of those only one (aha152x) sas significant maintaince since the dawn of git, all others only saw global / automatic updates. 4 of those are fairly trivial wrappers aroudn the NCR538 core, so I don't mind keeping them: - dtc - g_NCR5380 - pas16 - t128 but I'd love to know if anyone is actually using the other drivers: - wd7000 - aha1542 - in2000 - NCR53c406 - sym53c416 - u14-34f - ultrastor note that the last two even drive the same hardware. There is significant cruft in all these, so dropping them would help further maintainance of the SCSI midlayer. I think I have a AHA-1542B ISA card so I can fix the aha1542 driver. -- Ondrej Zary -- 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: [target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?
On Wed, 2015-01-07 at 03:35 +0800, kbuild test robot wrote: tree: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git nvme_of head: 40d8c11927282d59855d645b35798edd97828da5 commit: 40d8c11927282d59855d645b35798edd97828da5 [3/3] nvme_of: Initial skeleton commit reproduce: # apt-get install sparse git checkout 40d8c11927282d59855d645b35798edd97828da5 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by ) drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static? Please review and possibly fold the followup patch. Fixed. Thanks Fengguang! --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
[PATCH] scsi_debug: check for bigger value first
Even for signed types we have to check for bigger positive value first.
Otherwise it will be never happened.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/scsi/scsi_debug.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 8bcf6ad..a34df1d 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -4850,10 +4850,10 @@ static int __init scsi_debug_init(void)
/* play around with geometry, don't waste too much on track 0 */
sdebug_heads = 8;
sdebug_sectors_per = 32;
- if (scsi_debug_dev_size_mb = 16)
- sdebug_heads = 32;
- else if (scsi_debug_dev_size_mb = 256)
+ if (scsi_debug_dev_size_mb = 256)
sdebug_heads = 64;
+ else if (scsi_debug_dev_size_mb = 16)
+ sdebug_heads = 32;
sdebug_cylinders_per = (unsigned long)sdebug_capacity /
(sdebug_sectors_per * sdebug_heads);
if (sdebug_cylinders_per = 1024) {
--
1.8.3.101.g727a46b
--
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: remove artifical max_hw_sectors cap
On Tue, 2014-12-23 at 09:28 +0100, Christoph Hellwig wrote: On Mon, Dec 22, 2014 at 11:31:53AM +0100, Stefan Priebe - Profihost AG wrote: Hi, since the below patch i've some problems with iscsi. The LIO based iscsi Server is full of messages like this: SCSI OP 2ah with too big sectors 8344 exceeds fabric_max_sectors: 8192 And the client says: Buffer I/O error on device sdd, logical block 38861907 lost page write due to I/O error on sdd May be some code fixes for iscsi client is missing? No, the problem seems that the the target is enforcing a size limit without communicating it through the block limits EVPD page. Nic, can you fix LIO to expose the proper max xfer size? The fabric_max_sectors=8192 value is already being exposed by target in block limits EVPD as MAXIMUM TRANSFER LENGTH. I'm guessing that since the host side support was not added until June 2014 in commit bcdb247c by MKP, Stefan is likely using an earlier initiator that is not honoring this value. However, this same issue has been reported elsewhere [1] with an MSFT FC host sending I/Os of 8 MB that also doesn't appear to honor block limits MAXIMUM TRANSFER LENGTH either. So that said, I think it's about time to go ahead and drop the arbitrary limitation of fabric_max_sectors, and simply enforce a sane limit (eg: not UINT_MAX) for hw_max_sectors. The only limitations for backends that I'm aware of is the FILEIO FD_MAX_BYTES limit for the number of iovecs per vfs_[writev,readv] call, and for IBLOCK what queue_max_hw_sectors() reports for raw block make_request() based drivers that aren't able to I'll put together a patch soon to drop the fabric_max_sectors stuff, and use the existing hw_max_sectors to enforce any backend specific I/O size limitations. --nab [1] http://www.spinics.net/lists/target-devel/msg08024.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] Allow EA reservation holders to read from device.
On 01/06/2015 01:23 PM, Nicholas A. Bellinger wrote:
Hi Lee,
Apologies for the delayed response, just catching up from the holidays.
No worries.
Comments below.
On Mon, 2015-01-05 at 10:49 -0800, Lee Duncan wrote:
From: Lee Duncan ldun...@suse.com
For PGR reservation type Exclusive Access, allow all
registrants to read from the device.
Signed-off-by: Lee Duncan ldun...@suse.com
Cc: Nicholas Bellinger n...@linux-iscsi.org
---
drivers/target/target_core_pr.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/target/target_core_pr.c
b/drivers/target/target_core_pr.c
index 85564998500a..cb762b174c08 100644
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -551,6 +551,18 @@ static int core_scsi3_pr_seq_non_holder(
return 0;
}
+ } else if (we registered_nexus) {
+ /*
+* Reads are allowed for Write Exclusive locks
+* from all registrants.
+*/
+ if (cmd-data_direction == DMA_FROM_DEVICE) {
+ pr_debug(Allowing READ CDB: 0x%02x for %s
+reservation\n, cdb[0],
+ core_scsi3_pr_dump_type(pr_reg_type));
+
+ return 0;
+ }
}
pr_debug(%s Conflict for %sregistered nexus %s CDB: 0x%2x
for %s reservation\n, transport_dump_cmd_direction(cmd),
I'm confused as to why this is necessary..
Doesn't the conditional check directly above this one ensure that
all_reg=true registered_nexus=true implicitly allow READ CDBs to be
processed..?
No, the section right above it handles All Registrants or Registrants
Only reservations, but not normal reservations.
In other words, if using sg_persist to create the registration, the
problem occurs for type 1, i.e. regular old write exclusive.
And the section above it is allowing reads and writes, and we only want
to allow READs for the non-reservation holders in this case.
How is this new check for PR_TYPE_WRITE_EXCLUSIVE_ALLREG reservation any
different..?
Er, I believe they are totally different. That patch was about allowing
re-registration. This one is about allowing non-reservation-holding
registrants to read from the device when the reservation is of type
Write Exclusive. Can we agree that this should be allowed?
--nab
--
Lee Duncan
SUSE Labs
--
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
[Bug 90601] panic on write to 3ware raid array
https://bugzilla.kernel.org/show_bug.cgi?id=90601 --- Comment #7 from mer...@liao.homelinux.org --- Created attachment 162661 -- https://bugzilla.kernel.org/attachment.cgi?id=162661action=edit kernel config -- You are receiving this mail because: You are the assignee for the bug. -- 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] MAINTAINERS: Update maintainer list for qla4xxx
From: Nilesh Javali nilesh.jav...@qlogic.com Signed-off-by: Nilesh Javali nilesh.jav...@qlogic.com --- MAINTAINERS |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ddb9ac8..f6dee56 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7737,8 +7737,7 @@ F:Documentation/scsi/LICENSE.qla2xxx F: drivers/scsi/qla2xxx/ QLOGIC QLA4XXX iSCSI DRIVER -M: Vikas Chaudhary vikas.chaudh...@qlogic.com -M: iscsi-dri...@qlogic.com +M: qlogic-storage-upstr...@qlogic.com L: linux-scsi@vger.kernel.org S: Supported F: Documentation/scsi/LICENSE.qla4xxx -- 1.5.6 -- 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: [PATCHv3 00/10] scsi logging update: the real thing
On 01/05/2015 05:59 PM, Christoph Hellwig wrote: Can you send an updated version against the scsi-for-3.20 tree so that we can get this series in early for the 3.20 cycle? I'm about to prepare it. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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: Backport of a fix for HPSA (Disabling a disabled device problem during kdump) driver
On 01/05/2015 07:41 PM, Masoud Sharbiani wrote: Dear stable maintainers, Can you please backport commitid 132aa220b45d60e9b20def1e9d8be9422eed9616 (hpsa: refine the pci enable/disable handling) to 3.10 stable (and earlier, if applicable)? Please do not apply this patch isolated from his friend, the 859c75aba20264d87dd026bab0d0ca3bff385955 hpsa: add missing pci_set_master in kdump path needs to be applied together with the 132aa220b45d60e9b20def1e9d8be9422eed9616 . In addition to that, after the original issue goes away you may notice sometimes an unhandled irq 16 message, to fix this a patch is posted here http://www.spinics.net/lists/linux-scsi/msg80316.html This patch still awaits a maintainers review though. Probably the best idea is to wait until the issue is solved completely. Tomas I've tried the 3.10, and it applies cleanly there. Not sure about earlier versions. Many Thanks, Masoud Sharbiani Twitter Inc. -- 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
