[PATCH RESEND] mpt3sas: Fix for block device of raid exists even after deleting raid disk

[Sreekanth Reddy]

While merging mpt3sas & mpt2sas code, we posted below patch for WarpDrive
support,

mpt3sas: Ported WarpDrive product SSS6200 support
commit id is 7786ab6aff

In this patch and in the below hunk, we have added is_warpdrive
check condition on the wrong line
---
 scsih_target_alloc(struct scsi_target *starget)
sas_target_priv_data->handle = raid_device->handle;
sas_target_priv_data->sas_address = raid_device->wwid;
sas_target_priv_data->flags |= MPT_TARGET_FLAGS_VOLUME;
-   raid_device->starget = starget;
+   sas_target_priv_data->raid_device = raid_device;
+   if (ioc->is_warpdrive)
+   raid_device->starget = starget;
}
spin_unlock_irqrestore(>raid_device_lock, flags);
return 0;
--

Actually that check should be for below line
 sas_target_priv_data->raid_device = raid_device;

Due to above hunk, we are not initializing raid_device's starget for raid 
volumes,
and so during raid disk deletion driver is not calling scsi_remove_target() API 
as
driver observes starget field of raid_device's structure as NULL.

Signed-off-by: Sreekanth Reddy 
Cc: 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 981be7b..618c9df8 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -1279,9 +1279,9 @@ scsih_target_alloc(struct scsi_target *starget)
sas_target_priv_data->handle = raid_device->handle;
sas_target_priv_data->sas_address = raid_device->wwid;
sas_target_priv_data->flags |= MPT_TARGET_FLAGS_VOLUME;
-   sas_target_priv_data->raid_device = raid_device;
if (ioc->is_warpdrive)
-   raid_device->starget = starget;
+   sas_target_priv_data->raid_device = raid_device;
+   raid_device->starget = starget;
}
spin_unlock_irqrestore(>raid_device_lock, flags);
return 0;
-- 
2.4.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 v1 2/4] scsi: ufshcd: release resources if probe fails

[Subhash Jadavani]

If ufshcd pltfrm/pci driver's probe fails for some reason then ensure that
scsi host is released to avoid memory leak but managed memory allocations
(via devm_* calls) need not to be freed explicitly on probe failure as
memory allocated with these functions is automatically freed on driver
detach.

Reviewed-by: Sahitya Tummala 
Signed-off-by: Subhash Jadavani 
---
 drivers/scsi/ufs/ufshcd-pci.c| 2 ++
 drivers/scsi/ufs/ufshcd-pltfrm.c | 5 +
 drivers/scsi/ufs/ufshcd.c| 3 ---
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
index d15eaa4..52b546f 100644
--- a/drivers/scsi/ufs/ufshcd-pci.c
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -104,6 +104,7 @@ static void ufshcd_pci_remove(struct pci_dev *pdev)
pm_runtime_forbid(>dev);
pm_runtime_get_noresume(>dev);
ufshcd_remove(hba);
+   ufshcd_dealloc_host(hba);
 }
 
 /**
@@ -147,6 +148,7 @@ static void ufshcd_pci_remove(struct pci_dev *pdev)
err = ufshcd_init(hba, mmio_base, pdev->irq);
if (err) {
dev_err(>dev, "Initialization failed\n");
+   ufshcd_dealloc_host(hba);
return err;
}
 
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index db53f38..a72a4ba 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -163,7 +163,7 @@ static int ufshcd_populate_vreg(struct device *dev, const 
char *name,
if (ret) {
dev_err(dev, "%s: unable to find %s err %d\n",
__func__, prop_name, ret);
-   goto out_free;
+   goto out;
}
 
vreg->min_uA = 0;
@@ -185,9 +185,6 @@ static int ufshcd_populate_vreg(struct device *dev, const 
char *name,
 
goto out;
 
-out_free:
-   devm_kfree(dev, vreg);
-   vreg = NULL;
 out:
if (!ret)
*out_vreg = vreg;
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5c931d1..6c0082e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6253,8 +6253,6 @@ void ufshcd_remove(struct ufs_hba *hba)
ufshcd_disable_intr(hba, hba->intr_mask);
ufshcd_hba_stop(hba, true);
 
-   scsi_host_put(hba->host);
-
ufshcd_exit_clk_gating(hba);
if (ufshcd_is_clkscaling_enabled(hba))
devfreq_remove_device(hba->devfreq);
@@ -6616,7 +6614,6 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
ufshcd_exit_clk_gating(hba);
 out_disable:
hba->is_irq_enabled = false;
-   scsi_host_put(host);
ufshcd_hba_exit(hba);
 out_error:
return err;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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 4/4] scsi: ufs: change device rails hpm mode ramp up sequence

[Subhash Jadavani]

When we are resuming the UFS device rails in HPM mode, we are first
powering on the VCC rail while VCCQ and VCCQ2 rails still being in LPM
mode. Some UFS devices may take VCC on event as hint that host wants
UFS device to be resumed and may start drawing more power from the
VCCQ/VCCQ2 rails (while they are still in LPM mode) causing voltage drop
on these rails. This change fixes this issue by bringing VCCQ & VCCQ2 rails
out of LPM before powering on VCC rail.

Reviewed-by: Venkat Gopalakrishnan 
Signed-off-by: Subhash Jadavani 
---
 drivers/scsi/ufs/ufshcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 9ed96ae..8cf5d8f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5819,7 +5819,6 @@ static int ufshcd_vreg_set_hpm(struct ufs_hba *hba)
!hba->dev_info.is_lu_power_on_wp) {
ret = ufshcd_setup_vreg(hba, true);
} else if (!ufshcd_is_ufs_dev_active(hba)) {
-   ret = ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, true);
if (!ret && !ufshcd_is_link_active(hba)) {
ret = ufshcd_config_vreg_hpm(hba, hba->vreg_info.vccq);
if (ret)
@@ -5828,6 +5827,7 @@ static int ufshcd_vreg_set_hpm(struct ufs_hba *hba)
if (ret)
goto vccq_lpm;
}
+   ret = ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, true);
}
goto out;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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 3/4] scsi: ufs: suspend clock scaling at the start of suspend

[Subhash Jadavani]

Currently clock scaling is suspended only after the host and device
are put in low power mode but we should avoid clock scaling running
after UFS link is put in low power mode (hibern8). This change
suspends clock scaling before putting host/device in low power mode.

Reviewed-by: Sahitya Tummala 
Signed-off-by: Subhash Jadavani 
---
 drivers/scsi/ufs/ufshcd.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6c0082e..9ed96ae 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5892,6 +5892,8 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
ufshcd_hold(hba, false);
hba->clk_gating.is_suspended = true;
 
+   ufshcd_suspend_clkscaling(hba);
+
if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
req_link_state == UIC_LINK_ACTIVE_STATE) {
goto disable_clks;
@@ -5899,12 +5901,12 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
 
if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
(req_link_state == hba->uic_link_state))
-   goto out;
+   goto enable_gating;
 
/* UFS device & link must be active before we enter in this function */
if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
ret = -EINVAL;
-   goto out;
+   goto enable_gating;
}
 
if (ufshcd_is_runtime_pm(pm_op)) {
@@ -5941,13 +5943,6 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
 
 disable_clks:
/*
-* The clock scaling needs access to controller registers. Hence, Wait
-* for pending clock scaling work to be done before clocks are
-* turned off.
-*/
-   ufshcd_suspend_clkscaling(hba);
-
-   /*
 * Call vendor specific suspend callback. As these callbacks may access
 * vendor specific host controller register space call them before the
 * host clocks are ON.
@@ -5983,6 +5978,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
ufshcd_disable_auto_bkops(hba);
 enable_gating:
+   ufshcd_resume_clkscaling(hba);
hba->clk_gating.is_suspended = false;
ufshcd_release(hba);
 out:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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 1/4] scsi: ufs: fix race between clock gating and devfreq scaling work

[Subhash Jadavani]

UFS devfreq clock scaling work may require clocks to be ON if it need to
execute some UFS commands hence it may request for clock hold before
issuing the command. But if UFS clock gating work is already running in
parallel, ungate work would end up waiting for the clock gating work to
finish and as clock gating work would also wait for the clock scaling work
to finish, we would enter in deadlock state. Here is the call trace during
this deadlock state:

Workqueue: devfreq_wq devfreq_monitor
__switch_to
__schedule
schedule
schedule_timeout
wait_for_common
wait_for_completion
flush_work
ufshcd_hold
ufshcd_send_uic_cmd
ufshcd_dme_get_attr
ufs_qcom_set_dme_vs_core_clk_ctrl_clear_div
ufs_qcom_clk_scale_notify
ufshcd_scale_clks
ufshcd_devfreq_target
update_devfreq
devfreq_monitor
process_one_work
worker_thread
kthread
ret_from_fork

Workqueue: events ufshcd_gate_work
__switch_to
__schedule
schedule
schedule_preempt_disabled
__mutex_lock_slowpath
mutex_lock
devfreq_monitor_suspend
devfreq_simple_ondemand_handler
devfreq_suspend_device
ufshcd_gate_work
process_one_work
worker_thread
kthread
ret_from_fork

Workqueue: events ufshcd_ungate_work
__switch_to
__schedule
schedule
schedule_timeout
wait_for_common
wait_for_completion
flush_work
__cancel_work_timer
cancel_delayed_work_sync
ufshcd_ungate_work
process_one_work
worker_thread
kthread
ret_from_fork

This change fixes this deadlock by doing this in devfreq work (devfreq_wq):
Try cancelling clock gating work. If we are able to cancel gating work
or it wasn't scheduled, hold the clock reference count until scaling is
in progress. If gate work is already running in parallel, let's skip
the frequecy scaling at this time and it will be retried once next scaling
window expires.

Reviewed-by: Sahitya Tummala 
Signed-off-by: Subhash Jadavani 
---
 drivers/scsi/ufs/ufshcd.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 304adce..5c931d1 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6379,15 +6379,47 @@ static int ufshcd_devfreq_target(struct device *dev,
 {
int err = 0;
struct ufs_hba *hba = dev_get_drvdata(dev);
+   bool release_clk_hold = false;
+   unsigned long irq_flags;
 
if (!ufshcd_is_clkscaling_enabled(hba))
return -EINVAL;
 
+   spin_lock_irqsave(hba->host->host_lock, irq_flags);
+   if (ufshcd_eh_in_progress(hba)) {
+   spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
+   return 0;
+   }
+
+   if (ufshcd_is_clkgating_allowed(hba) &&
+   (hba->clk_gating.state != CLKS_ON)) {
+   if (cancel_delayed_work(>clk_gating.gate_work)) {
+   /* hold the vote until the scaling work is completed */
+   hba->clk_gating.active_reqs++;
+   release_clk_hold = true;
+   hba->clk_gating.state = CLKS_ON;
+   } else {
+   /*
+* Clock gating work seems to be running in parallel
+* hence skip scaling work to avoid deadlock between
+* current scaling work and gating work.
+*/
+   spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
+   return 0;
+   }
+   }
+   spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
+
if (*freq == UINT_MAX)
err = ufshcd_scale_clks(hba, true);
else if (*freq == 0)
err = ufshcd_scale_clks(hba, false);
 
+   spin_lock_irqsave(hba->host->host_lock, irq_flags);
+   if (release_clk_hold)
+   __ufshcd_release(hba);
+   spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
+
return err;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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 121531] Adaptec 7805H SAS HBA (pm80xx): hangs when writing >80MB at once

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=121531

--- Comment #22 from Chloé Desoutter  ---
(In reply to Chloé Desoutter from comment #20)
> Currently testing w/ PM8001_MPI_QUEUE = 256.
> 
> Prospective patch attached.

I confirm that after 36 hours of intensive workload, I see no visible
performance loss on a PM8001 and that there's been no data error since then.

-- 
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

"hpsa: Change SAS transport devices to bus 0." commit breaks hpacucli on old controller firmware

[Jack Suter]

Hi there,

Commit "hpsa: Change SAS transport devices to bus 0."
(09371d623c9c3dc6ed7f53ec8ab01d25f0c6c697) breaks the hpacucli utility
for some HP Smart Array controllers with old firmware.

Specifically, I have a P410 connected to an HP DL180 G6 running firmware
version 1.66. Yes, the firmware is old, but it works. On the 4.4 series
kernels and earlier, hpacucli works with no trouble. On 4.5 and later,
the hpsa driver reports errors  in the kernel log, and hpacucli reports
"Error: No controllers detected."

Oct 27 15:50:30 hostname kernel: [   32.189495] hpsa :06:00.0: scsi
0:0:0:0: added RAID  HP   P410 controller
SSDSmartPathCap- En- Exp=1
Oct 27 15:50:30 hostname kernel: [   32.190054] hpsa :06:00.0:
addition failed -19, device not added.

Reverting the above commit resolves both the hpsa errors and the
hpacucli error when tested with kernel 4.7.9.

In addition to this troublesome server, I have a handful of servers with
P410 controllers and firmware versions ranging from 3.52 to 6.60. All of
them work with the 09371d62 commit in place, which leads me to believe
it is just this old 1.66 firmware that is incompatible. 

While a firmware upgrade seems like the simple solution, I think this
should be considered a bug/regression due to it breaking functionality
that previously worked. It appears others may have run into this issue
too:
http://superuser.com/questions/1093124/coreos-hp410-raid1-device-not-added-19

Some dmesg output (grep -e hpsa -e sg) is below from both a 4.4.2 kernel
(working) and 4.5.7 kernel (broken). Note the change in SCSI address
from 0:3:0:0 to 0:0:0:0.

Please let me know if you need me to do any testing to help resolve
this.

Jack Suter

Kernel 4.4.2
Oct 27 15:28:07 hostname kernel: [1.461160] hpsa :06:00.0: can't
disable ASPM; OS doesn't have ASPM control
Oct 27 15:28:07 hostname kernel: [1.461632] hpsa :06:00.0: MSI-X
capable controller
Oct 27 15:28:07 hostname kernel: [1.463363] hpsa :06:00.0:
Logical aborts not supported
Oct 27 15:28:07 hostname kernel: [1.463619] hpsa :06:00.0: HP
SSD Smart Path aborts not supported
Oct 27 15:28:07 hostname kernel: [1.495824] scsi host0: hpsa
Oct 27 15:28:07 hostname kernel: [1.558535] hpsa :06:00.0: scsi
0:0:0:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.558992] hpsa :06:00.0: scsi
0:0:1:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.559441] hpsa :06:00.0: scsi
0:0:2:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.559890] hpsa :06:00.0: scsi
0:0:3:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.560338] hpsa :06:00.0: scsi
0:0:4:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.560786] hpsa :06:00.0: scsi
0:0:5:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.561234] hpsa :06:00.0: scsi
0:0:6:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.561681] hpsa :06:00.0: scsi
0:0:7:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.562131] hpsa :06:00.0: scsi
0:0:8:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.562579] hpsa :06:00.0: scsi
0:0:9:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.563027] hpsa :06:00.0: scsi
0:0:10:0: masked Direct-Access ATA  WDC WD2002FAEX-0 PHYS DRV
SSDSmartPathCap- En- Exp=0
Oct 27 15:28:07 hostname kernel: [1.563476] hpsa :06:00.0: scsi
0:1:0:0: added Direct-Access HP   LOGICAL VOLUME   RAID-0
SSDSmartPathCap- En- Exp=1
Oct 27 15:28:07 hostname kernel: [1.563925] hpsa :06:00.0: scsi
0:1:0:1: added Direct-Access HP   LOGICAL VOLUME   RAID-0
SSDSmartPathCap- En- Exp=1
Oct 27 15:28:07 hostname kernel: [1.564372] hpsa :06:00.0: scsi
0:1:0:2: added Direct-Access HP   LOGICAL VOLUME   RAID-0
SSDSmartPathCap- En- Exp=1
Oct 27 15:28:07 hostname kernel: [1.564820] hpsa :06:00.0: scsi
0:1:0:3: added Direct-Access HP   LOGICAL VOLUME   RAID-0
SSDSmartPathCap- En- Exp=1
Oct 27 15:28:07 hostname kernel: [1.565267] hpsa :06:00.0: scsi
0:1:0:4: added Direct-Access HP   LOGICAL VOLUME   RAID-0
SSDSmartPathCap- En- Exp=1
Oct 27 15:28:07 hostname kernel: [1.565715] hpsa :06:00.0: scsi
0:1:0:5: added Direct-Access HP 

Re: [PATCH 05/12] blk-mq: Introduce blk_mq_quiesce_queue()

[Bart Van Assche]

On 10/26/2016 10:52 PM, Hannes Reinecke wrote:

Hmm. Can't say I like having to have two RCU structure for the same
purpose, but I guess that can't be helped.


Hello Hannes,

There are two RCU structures because of BLK_MQ_F_BLOCKING. Today only 
the nbd driver sets that flag. If the nbd driver would be modified such 
that it doesn't set that flag then the BLK_MQ_F_BLOCKING flag and also 
queue_rq_srcu could be eliminated from the blk-mq core.


Bart.
--
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] Avoid that SCSI device removal through sysfs triggers a deadlock

[Bart Van Assche]

On 10/27/2016 02:36 AM, Sagi Grimberg wrote:

The solution I prefer is to modify the SCSI scanning code such that
the scan_mutex is only held while performing the actual LUN scanning
and while ensuring that no SCSI device has been created yet for a
certain LUN number but not while the Linux device and its sysfs
attributes are created. Since that approach would require extensive
changes in the SCSI scanning code, another approach has been chosen,
namely to make self-removal asynchronous. This patch avoids that
self-removal triggers the following deadlock:


Is this a real deadlock? or just a lockdep complaint?

Wouldn't making scsi_remove_device() taking single depth
mutex_lock_nested suffice here?


Hello Sagi,

It's a real deadlock, and I can trigger it relatively easy by deleting a 
SCSI device that is managed by the dm-multipath driver.


Bart.
--
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/4] hpsa: correct lockup detector pci_disable_device

[Christoph Hellwig]

> - pci_disable_device(h->pdev);
> + if (pci_is_enabled(h->pdev))
> + pci_disable_device(h->pdev);
>   fail_all_outstanding_cmds(h);

Humm.  How can this even happen when the device isn't enabled?
--
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: A question regarding "multiple SGL"

[Steve Wise]

> > Hi Robert,
> 
> Hey Robert, Christoph,
> 
> > please explain your use cases that isn't handled.  The one and only
> > reason to set MSDBD to 1 is to make the code a lot simpler given that
> > there is no real use case for supporting more.
> >
> > RDMA uses memory registrations to register large and possibly
> > discontiguous data regions for a single rkey, aka single SGL descriptor
> > in NVMe terms.  There would be two reasons to support multiple SGL
> > descriptors:  a) to support a larger I/O size than supported by a single
> > MR, or b) to support a data region format not mappable by a single
> > MR.
> >
> > iSER only supports a single rkey (or stag in IETF terminology) and has
> > been doing fine on a) and mostly fine on b).   There are a few possible
> > data layouts not supported by the traditional IB/iWarp FR WRs, but the
> > limit is in fact exactly the same as imposed by the NVMe PRPs used for
> > PCIe NVMe devices, so the Linux block layer has support to not generate
> > them.  Also with modern Mellanox IB/RoCE hardware we can actually
> > register completely arbitrary SGLs.  iSER supports using this registration
> > mode already with a trivial code addition, but for NVMe we didn't have a
> > pressing need yet.
> 
> Good explanation :)
> 
> The IO transfer size is a bit more pressing on some devices (e.g.
> cxgb3/4) where the number of pages per-MR can be indeed lower than
> a reasonable transfer size (Steve can correct me if I'm wrong).
>

Currently, cxgb4 support 128KB REG_MR operations on a host with 4K page size,
via a max mr page list depth of 32.  Soon it will be bumped up from 32 to 128
and life will be better...

 
> However, if there is a real demand for this we'll happily accept
> patches :)
> 
> Just a note, having this feature in-place can bring unexpected behavior
> depending on how we implement it:
> - If we can use multiple MRs per IO (for multiple SGLs) we can either
> prepare for the worst-case and allocate enough MRs to satisfy the
> various IO patterns. This will be much heavier in terms of resource
> allocation and can limit the scalability of the host driver.
> - Or we can implement a shared MR pool with a reasonable number of MRs.
> In this case each IO can consume one or more MRs on the expense of
> other IOs. In this case we may need to requeue the IO later when we
> have enough available MRs to satisfy the IO. This can yield some
> unexpected performance gaps for some workloads.
> 

I would like to see the storage protocols deal with lack of resources for the
worst case.  This allows much smaller resource usage for both MRs, and SQ
resources, at the expense of adding flow control logic to deal with lack of
available MR and/or SQ slots to process the next IO.  I think it can be
implemented efficiently such that when in flow-control mode, the code is driving
new IO submissions off of SQ completions which will free up SQ slots and most
likely MRs from the QP's MR pool.

Steve.


--
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] Avoid that SCSI device removal through sysfs triggers a deadlock

[Bart Van Assche]

On 10/27/2016 02:46 AM, Johannes Thumshirn wrote:

On Wed, Oct 26, 2016 at 11:44:51AM -0700, Bart Van Assche wrote:

+static void scsi_remove_device_async(struct scsi_device *sdev)
+{
+   if (scsi_device_get(sdev) < 0)


Nit: the < 0 could be dropped, scsi_device_get returns either -ENXIO or
0. But no reason to respin.

Anyways,
Reviewed-by: Johannes Thumshirn 


Hello Johannes,

Thanks for the review. But I'd like to clarify that I added the "< 0" on 
purpose. Some *_get*() functions in the Linux kernel return 0 upon 
failure (e.g. kref_get_unless_zero()) and others a negative value (e.g. 
scsi_device_get()). The "< 0" part avoids that someone who reads this 
code has to look up what return value convention scsi_device_get() uses.


Bart.

--
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] Avoid that SCSI device removal through sysfs triggers a deadlock

[Sagi Grimberg]

Hey Bart,


The solution I prefer is to modify the SCSI scanning code such that
the scan_mutex is only held while performing the actual LUN scanning
and while ensuring that no SCSI device has been created yet for a
certain LUN number but not while the Linux device and its sysfs
attributes are created. Since that approach would require extensive
changes in the SCSI scanning code, another approach has been chosen,
namely to make self-removal asynchronous. This patch avoids that
self-removal triggers the following deadlock:


Is this a real deadlock? or just a lockdep complaint?

Wouldn't making scsi_remove_device() taking single depth
mutex_lock_nested suffice here?
--
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

[GIT PULL] SCSI fixes for 4.9-rc2

[James Bottomley]

Two small fixes: one is a fatal section mismatch (reference to init
after it's discarded) and the other two are iscsi locking fixes.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Arnd Bergmann (1):
  scsi: NCR5380: no longer mark irq probing as __init

Jitendra Bhivare (2):
  scsi: be2iscsi: Replace _bh with _irqsave/irqrestore
  scsi: libiscsi: Fix locking in __iscsi_conn_send_pdu

And the diffstat:

 drivers/scsi/NCR5380.c  |  6 +++---
 drivers/scsi/be2iscsi/be_main.c | 37 +++--
 drivers/scsi/libiscsi.c |  4 ++--
 3 files changed, 28 insertions(+), 19 deletions(-)

With full diff below.

James

---

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index db27390..790babc 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -353,7 +353,7 @@ static void NCR5380_print_phase(struct Scsi_Host *instance)
 #endif
 
 
-static int probe_irq __initdata;
+static int probe_irq;
 
 /**
  * probe_intr  -   helper for IRQ autoprobe
@@ -365,7 +365,7 @@ static int probe_irq __initdata;
  * used by the IRQ probe code.
  */
 
-static irqreturn_t __init probe_intr(int irq, void *dev_id)
+static irqreturn_t probe_intr(int irq, void *dev_id)
 {
probe_irq = irq;
return IRQ_HANDLED;
@@ -380,7 +380,7 @@ static irqreturn_t __init probe_intr(int irq, void *dev_id)
  * and then looking to see what interrupt actually turned up.
  */
 
-static int __init __maybe_unused NCR5380_probe_irq(struct Scsi_Host *instance,
+static int __maybe_unused NCR5380_probe_irq(struct Scsi_Host *instance,
int possible)
 {
struct NCR5380_hostdata *hostdata = shost_priv(instance);
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 68138a6..d9239c2 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -900,8 +900,9 @@ void hwi_ring_cq_db(struct beiscsi_hba *phba,
 static struct sgl_handle *alloc_io_sgl_handle(struct beiscsi_hba *phba)
 {
struct sgl_handle *psgl_handle;
+   unsigned long flags;
 
-   spin_lock_bh(>io_sgl_lock);
+   spin_lock_irqsave(>io_sgl_lock, flags);
if (phba->io_sgl_hndl_avbl) {
beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_IO,
"BM_%d : In alloc_io_sgl_handle,"
@@ -919,14 +920,16 @@ static struct sgl_handle *alloc_io_sgl_handle(struct 
beiscsi_hba *phba)
phba->io_sgl_alloc_index++;
} else
psgl_handle = NULL;
-   spin_unlock_bh(>io_sgl_lock);
+   spin_unlock_irqrestore(>io_sgl_lock, flags);
return psgl_handle;
 }
 
 static void
 free_io_sgl_handle(struct beiscsi_hba *phba, struct sgl_handle *psgl_handle)
 {
-   spin_lock_bh(>io_sgl_lock);
+   unsigned long flags;
+
+   spin_lock_irqsave(>io_sgl_lock, flags);
beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_IO,
"BM_%d : In free_,io_sgl_free_index=%d\n",
phba->io_sgl_free_index);
@@ -941,7 +944,7 @@ free_io_sgl_handle(struct beiscsi_hba *phba, struct 
sgl_handle *psgl_handle)
 "value there=%p\n", phba->io_sgl_free_index,
 phba->io_sgl_hndl_base
 [phba->io_sgl_free_index]);
-spin_unlock_bh(>io_sgl_lock);
+spin_unlock_irqrestore(>io_sgl_lock, flags);
return;
}
phba->io_sgl_hndl_base[phba->io_sgl_free_index] = psgl_handle;
@@ -950,7 +953,7 @@ free_io_sgl_handle(struct beiscsi_hba *phba, struct 
sgl_handle *psgl_handle)
phba->io_sgl_free_index = 0;
else
phba->io_sgl_free_index++;
-   spin_unlock_bh(>io_sgl_lock);
+   spin_unlock_irqrestore(>io_sgl_lock, flags);
 }
 
 static inline struct wrb_handle *
@@ -958,15 +961,16 @@ beiscsi_get_wrb_handle(struct hwi_wrb_context 
*pwrb_context,
   unsigned int wrbs_per_cxn)
 {
struct wrb_handle *pwrb_handle;
+   unsigned long flags;
 
-   spin_lock_bh(_context->wrb_lock);
+   spin_lock_irqsave(_context->wrb_lock, flags);
pwrb_handle = pwrb_context->pwrb_handle_base[pwrb_context->alloc_index];
pwrb_context->wrb_handles_available--;
if (pwrb_context->alloc_index == (wrbs_per_cxn - 1))
pwrb_context->alloc_index = 0;
else
pwrb_context->alloc_index++;
-   spin_unlock_bh(_context->wrb_lock);
+   spin_unlock_irqrestore(_context->wrb_lock, flags);
 
if (pwrb_handle)
memset(pwrb_handle->pwrb, 0, sizeof(*pwrb_handle->pwrb));
@@ -1001,14 +1005,16 @@ beiscsi_put_wrb_handle(struct hwi_wrb_context 
*pwrb_context,
   struct wrb_handle *pwrb_handle,
   unsigned int wrbs_per_cxn)
 {
-   

Re: [PATCH 4/4] hpsa: bump driver version

[Hannes Reinecke]

On 10/27/2016 12:22 AM, Don Brace wrote:
> Reviewed-by: Scott Benesh 
> Reviewed-by: Scott Teel 
> Signed-off-by: Don Brace 
> ---
>  drivers/scsi/hpsa.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 810c300..0b6eb5a 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -60,7 +60,7 @@
>   * HPSA_DRIVER_VERSION must be 3 byte values (0-255) separated by '.'
>   * with an optional trailing '-' followed by a byte value (0-255).
>   */
> -#define HPSA_DRIVER_VERSION "3.4.16-0"
> +#define HPSA_DRIVER_VERSION "3.4.16-145"
>  #define DRIVER_NAME "HP HPSA Driver (v " HPSA_DRIVER_VERSION ")"
>  #define HPSA "hpsa"
>  
> 
> --
> 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
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 05/12] blk-mq: Introduce blk_mq_quiesce_queue()

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig 
--
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 05/12] blk-mq: Introduce blk_mq_quiesce_queue()

[Ming Lei]

On Thu, Oct 27, 2016 at 8:42 PM, Christoph Hellwig  wrote:
> On Wed, Oct 26, 2016 at 08:05:14PM -0700, Bart Van Assche wrote:
>> I'll leave it to Jens to decide whether I should repost the patch series
>> with this change integrated or whether to realize this change with a
>> follow-up patch.
>
> I would prefer to get the series in now.  I think we should eventually
> the stop queues call, the quience call and even the cancellation of
> the requeues into a single function, but it's not as urgent.  I think
> this series actually is Linux 4.9 material.

Yeah, that is fine to cleanup in follow-up patch.

Reviewed-by: Ming Lei 

Thanks
Ming Lei
--
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] Avoid that SCSI device removal through sysfs triggers a deadlock

[Johannes Thumshirn]

Hi Bart,

On Wed, Oct 26, 2016 at 11:44:51AM -0700, Bart Van Assche wrote:
> The solution I prefer is to modify the SCSI scanning code such that
> the scan_mutex is only held while performing the actual LUN scanning
> and while ensuring that no SCSI device has been created yet for a
> certain LUN number but not while the Linux device and its sysfs
> attributes are created. Since that approach would require extensive
> changes in the SCSI scanning code, another approach has been chosen,
> namely to make self-removal asynchronous. This patch avoids that
> self-removal triggers the following deadlock:

I'm not sure I like yet another asynchronity in the scsi code, but your
reason is very much understandable and I agree that this is the faster way.

[...]

> 
> References: http://www.spinics.net/lists/linux-scsi/msg86551.html
> Signed-off-by: Bart Van Assche 
> Cc: Hannes Reinecke 
> Cc: Johannes Thumshirn 
> Cc: Sagi Grimberg 
> Cc: 
> ---

[...]

>  
> +static void scsi_remove_device_async(struct scsi_device *sdev)
> +{
> + if (scsi_device_get(sdev) < 0)

Nit: the < 0 could be dropped, scsi_device_get returns either -ENXIO or
0. But no reason to respin.

Anyways,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 03/12] blk-mq: Introduce blk_mq_queue_stopped()

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:52:05PM -0700, Bart Van Assche wrote:
> The function blk_queue_stopped() allows to test whether or not a
> traditional request queue has been stopped. Introduce a helper
> function that allows block drivers to query easily whether or not
> one or more hardware contexts of a blk-mq queue have been stopped.
> 
> Signed-off-by: Bart Van Assche 
> Reviewed-by: Hannes Reinecke 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 08/12] dm: Fix a race condition related to stopping and starting queues

[Mike Snitzer]

On Wed, Oct 26 2016 at  6:54pm -0400,
Bart Van Assche  wrote:

> Ensure that all ongoing dm_mq_queue_rq() and dm_mq_requeue_request()
> calls have stopped before setting the "queue stopped" flag. This
> allows to remove the "queue stopped" test from dm_mq_queue_rq() and
> dm_mq_requeue_request(). This patch fixes a race condition because
> dm_mq_queue_rq() is called without holding the queue lock and hence
> BLK_MQ_S_STOPPED can be set at any time while dm_mq_queue_rq() is
> in progress. This patch prevents that the following hang occurs
> sporadically when using dm-mq:
> 
> INFO: task systemd-udevd:10111 blocked for more than 480 seconds.
> Call Trace:
>  [] schedule+0x37/0x90
>  [] schedule_timeout+0x27f/0x470
>  [] io_schedule_timeout+0x9f/0x110
>  [] bit_wait_io+0x16/0x60
>  [] __wait_on_bit_lock+0x49/0xa0
>  [] __lock_page+0xb9/0xc0
>  [] truncate_inode_pages_range+0x3e0/0x760
>  [] truncate_inode_pages+0x10/0x20
>  [] kill_bdev+0x30/0x40
>  [] __blkdev_put+0x71/0x360
>  [] blkdev_put+0x49/0x170
>  [] blkdev_close+0x20/0x30
>  [] __fput+0xe8/0x1f0
>  [] fput+0x9/0x10
>  [] task_work_run+0x83/0xb0
>  [] do_exit+0x3ee/0xc40
>  [] do_group_exit+0x4b/0xc0
>  [] get_signal+0x2ca/0x940
>  [] do_signal+0x23/0x660
>  [] exit_to_usermode_loop+0x73/0xb0
>  [] syscall_return_slowpath+0xb0/0xc0
>  [] entry_SYSCALL_64_fastpath+0xa6/0xa8
> 
> Signed-off-by: Bart Van Assche 
> Reviewed-by: Hannes Reinecke 
> Reviewed-by: Johannes Thumshirn 
> Reviewed-by: Christoph Hellwig 
> Cc: Mike Snitzer 

Acked-by: Mike Snitzer 
--
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/4] hpsa: correct lockup detector pci_disable_device

[Johannes Thumshirn]

On Thu, Oct 27, 2016 at 11:01:41AM +0200, Hannes Reinecke wrote:
> On 10/27/2016 12:21 AM, Don Brace wrote:
> > need to check if the device is already disabled first
> > 
> > Reviewed-by: Scott Benesh 
> > Reviewed-by: Scott Teel 
> > Signed-off-by: Don Brace 
> > ---
> >  drivers/scsi/hpsa.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> > index d007ec1..798fb20 100644
> > --- a/drivers/scsi/hpsa.c
> > +++ b/drivers/scsi/hpsa.c
> > @@ -8456,7 +8456,8 @@ static void controller_lockup_detected(struct 
> > ctlr_info *h)
> > spin_unlock_irqrestore(>lock, flags);
> > dev_warn(>pdev->dev, "Controller lockup detected: 0x%08x after %d\n",
> > lockup_detected, h->heartbeat_sample_interval / HZ);
> > -   pci_disable_device(h->pdev);
> > +   if (pci_is_enabled(h->pdev))
> > +   pci_disable_device(h->pdev);
> > fail_all_outstanding_cmds(h);
> >  }
> >  
> > 
> Meh.
> Why is pci_disable_device() not checking for it?

It does:
1607 void pci_disable_device(struct pci_dev *dev)
1608 {
[...]
1615 dev_WARN_ONCE(>dev, atomic_read(>enable_cnt) <= 0,
1616   "disabling already-disabled device");
[...]
1624 }
1625 EXPORT_SYMBOL(pci_disable_device);

Which is the motivation behind this patch I think.

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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] mpt3sas: Fix for block device of raid exists even after deleting raid disk

[Sreekanth Reddy]

While merging mpt3sas & mpt2sas code, we posted below patch for WarpDrive
support,

mpt3sas: Ported WarpDrive product SSS6200 support
commit id is 7786ab6aff

In this patch and in the below hunk, we have added is_warpdrive
check condition on the wrong line
---
 scsih_target_alloc(struct scsi_target *starget)
sas_target_priv_data->handle = raid_device->handle;
sas_target_priv_data->sas_address = raid_device->wwid;
sas_target_priv_data->flags |= MPT_TARGET_FLAGS_VOLUME;
-   raid_device->starget = starget;
+   sas_target_priv_data->raid_device = raid_device;
+   if (ioc->is_warpdrive)
+   raid_device->starget = starget;
}
spin_unlock_irqrestore(>raid_device_lock, flags);
return 0;
--

Actually that check should be for below line
 sas_target_priv_data->raid_device = raid_device;

Due to above hunk, we are not initializing raid_device's starget for raid 
volumes,
and so during raid disk deletion driver is not calling scsi_remove_target() API 
as
driver observes starget field of raid_device's structure as NULL.

Signed-off-by: Sreekanth Reddy 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 981be7b..618c9df8 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -1279,9 +1279,9 @@ scsih_target_alloc(struct scsi_target *starget)
sas_target_priv_data->handle = raid_device->handle;
sas_target_priv_data->sas_address = raid_device->wwid;
sas_target_priv_data->flags |= MPT_TARGET_FLAGS_VOLUME;
-   sas_target_priv_data->raid_device = raid_device;
if (ioc->is_warpdrive)
-   raid_device->starget = starget;
+   sas_target_priv_data->raid_device = raid_device;
+   raid_device->starget = starget;
}
spin_unlock_irqrestore(>raid_device_lock, flags);
return 0;
-- 
2.4.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: [PATCH 01/12] blk-mq: Do not invoke .queue_rq() for a stopped queue

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:50:44PM -0700, Bart Van Assche wrote:
> The meaning of the BLK_MQ_S_STOPPED flag is "do not call
> .queue_rq()". Hence modify blk_mq_make_request() such that requests
> are queued instead of issued if a queue has been stopped.
> 
> Reported-by: Ming Lei 
> Signed-off-by: Bart Van Assche 
> Reviewed-by: Christoph Hellwig 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 04/12] blk-mq: Move more code into blk_mq_direct_issue_request()

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:52:35PM -0700, Bart Van Assche wrote:
> Move the "hctx stopped" test and the insert request calls into
> blk_mq_direct_issue_request(). Rename that function into
> blk_mq_try_issue_directly() to reflect its new semantics. Pass
> the hctx pointer to that function instead of looking it up a
> second time. These changes avoid that code has to be duplicated
> in the next patch.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Christoph Hellwig 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 02/12] blk-mq: Introduce blk_mq_hctx_stopped()

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:51:33PM -0700, Bart Van Assche wrote:
> Multiple functions test the BLK_MQ_S_STOPPED bit so introduce
> a helper function that performs this test.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Christoph Hellwig 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 04/12] blk-mq: Move more code into blk_mq_direct_issue_request()

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:52:35PM -0700, Bart Van Assche wrote:
> Move the "hctx stopped" test and the insert request calls into
> blk_mq_direct_issue_request(). Rename that function into
> blk_mq_try_issue_directly() to reflect its new semantics. Pass
> the hctx pointer to that function instead of looking it up a
> second time. These changes avoid that code has to be duplicated
> in the next patch.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Christoph Hellwig 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 11/12] nvme: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

[Sagi Grimberg]

Looks good,

Reviewed-by: Sagi Grimberg 
--
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 01/12] blk-mq: Do not invoke .queue_rq() for a stopped queue

[Sagi Grimberg]

Reviewed-by: Sagi Grimberg 
--
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 05/12] blk-mq: Introduce blk_mq_quiesce_queue()

[Christoph Hellwig]

On Wed, Oct 26, 2016 at 08:05:14PM -0700, Bart Van Assche wrote:
> I'll leave it to Jens to decide whether I should repost the patch series 
> with this change integrated or whether to realize this change with a 
> follow-up patch.

I would prefer to get the series in now.  I think we should eventually
the stop queues call, the quience call and even the cancellation of
the requeues into a single function, but it's not as urgent.  I think
this series actually is Linux 4.9 material.
--
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: A question regarding "multiple SGL"

[Sagi Grimberg]

Hi Robert,


Hey Robert, Christoph,


please explain your use cases that isn't handled.  The one and only
reason to set MSDBD to 1 is to make the code a lot simpler given that
there is no real use case for supporting more.

RDMA uses memory registrations to register large and possibly
discontiguous data regions for a single rkey, aka single SGL descriptor
in NVMe terms.  There would be two reasons to support multiple SGL
descriptors:  a) to support a larger I/O size than supported by a single
MR, or b) to support a data region format not mappable by a single
MR.

iSER only supports a single rkey (or stag in IETF terminology) and has
been doing fine on a) and mostly fine on b).   There are a few possible
data layouts not supported by the traditional IB/iWarp FR WRs, but the
limit is in fact exactly the same as imposed by the NVMe PRPs used for
PCIe NVMe devices, so the Linux block layer has support to not generate
them.  Also with modern Mellanox IB/RoCE hardware we can actually
register completely arbitrary SGLs.  iSER supports using this registration
mode already with a trivial code addition, but for NVMe we didn't have a
pressing need yet.


Good explanation :)

The IO transfer size is a bit more pressing on some devices (e.g.
cxgb3/4) where the number of pages per-MR can be indeed lower than
a reasonable transfer size (Steve can correct me if I'm wrong).

However, if there is a real demand for this we'll happily accept
patches :)

Just a note, having this feature in-place can bring unexpected behavior
depending on how we implement it:
- If we can use multiple MRs per IO (for multiple SGLs) we can either
prepare for the worst-case and allocate enough MRs to satisfy the
various IO patterns. This will be much heavier in terms of resource
allocation and can limit the scalability of the host driver.
- Or we can implement a shared MR pool with a reasonable number of MRs.
In this case each IO can consume one or more MRs on the expense of
other IOs. In this case we may need to requeue the IO later when we
have enough available MRs to satisfy the IO. This can yield some
unexpected performance gaps for some workloads.

Cheers,
Sagi.
--
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 02/12] blk-mq: Introduce blk_mq_hctx_stopped()

[Sagi Grimberg]

Looks fine,

Reviewed-by: Sagi Grimberg 
--
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/12] blk-mq: Add a kick_requeue_list argument to blk_mq_requeue_request()

[Christoph Hellwig]

On Wed, Oct 26, 2016 at 03:53:39PM -0700, Bart Van Assche wrote:
> Most blk_mq_requeue_request() and blk_mq_add_to_requeue_list() calls
> are followed by kicking the requeue list. Hence add an argument to
> these two functions that allows to kick the requeue list. This was
> proposed by Christoph Hellwig.

Looks good,

Reviewed-by: Christoph Hellwig 
--
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 04/12] blk-mq: Move more code into blk_mq_direct_issue_request()

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig 
--
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/4] hpsa: remove coalescing settings for ioaccel2

[Hannes Reinecke]

On 10/27/2016 12:21 AM, Don Brace wrote:
> - Setting coalescing has a significant negative
>   impact on low queue-depth performance.
> - Does not help high queue-depth performance.
> 
> Reviewed-by: Scott Benesh 
> Reviewed-by: Scott Teel 
> Reviewed-by: Kevin Barnett 
> Signed-off-by: Don Brace 
> ---
>  drivers/scsi/hpsa.c |8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 9fb739c..810c300 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -9277,13 +9277,9 @@ static int hpsa_enter_performant_mode(struct ctlr_info 
> *h, u32 trans_support)
>   access = SA5_ioaccel_mode1_access;
>   writel(10, >cfgtable->HostWrite.CoalIntDelay);
>   writel(4, >cfgtable->HostWrite.CoalIntCount);
> - } else {
> - if (trans_support & CFGTBL_Trans_io_accel2) {
> + } else
> + if (trans_support & CFGTBL_Trans_io_accel2)
>   access = SA5_ioaccel_mode2_access;
> - writel(10, >cfgtable->HostWrite.CoalIntDelay);
> - writel(4, >cfgtable->HostWrite.CoalIntCount);
> - }
> - }
>   writel(CFGTBL_ChangeReq, h->vaddr + SA5_DOORBELL);
>   if (hpsa_wait_for_mode_change_ack(h)) {
>   dev_err(>pdev->dev,
> 
> --
> 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
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 09/12] SRP transport: Move queuecommand() wait code to SCSI core

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:55:00PM -0700, Bart Van Assche wrote:
> Additionally, rename srp_wait_for_queuecommand() into
> scsi_wait_for_queuecommand() and add a comment about the
> queuecommand() call from scsi_send_eh_cmnd().
> 
> Signed-off-by: Bart Van Assche 
> Reviewed-by: Christoph Hellwig 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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/12] blk-mq: Add a kick_requeue_list argument to blk_mq_requeue_request()

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:53:39PM -0700, Bart Van Assche wrote:
> Most blk_mq_requeue_request() and blk_mq_add_to_requeue_list() calls
> are followed by kicking the requeue list. Hence add an argument to
> these two functions that allows to kick the requeue list. This was
> proposed by Christoph Hellwig.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Christoph Hellwig 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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/12] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

[Mike Snitzer]

On Wed, Oct 26 2016 at  6:54pm -0400,
Bart Van Assche  wrote:

> Instead of manipulating both QUEUE_FLAG_STOPPED and BLK_MQ_S_STOPPED
> in the dm start and stop queue functions, only manipulate the latter
> flag. Change blk_queue_stopped() tests into blk_mq_queue_stopped().
> 
> Signed-off-by: Bart Van Assche 
> Reviewed-by: Christoph Hellwig 
> Cc: Mike Snitzer 

Acked-by: Mike Snitzer 
--
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 10/12] SRP transport, scsi-mq: Wait for .queue_rq() if necessary

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:55:34PM -0700, Bart Van Assche wrote:
> Ensure that if scsi-mq is enabled that scsi_wait_for_queuecommand()
> waits until ongoing shost->hostt->queuecommand() calls have finished.
> 
> Signed-off-by: Bart Van Assche 
> Reviewed-by: Christoph Hellwig 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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/12] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

[Johannes Thumshirn]

On Wed, Oct 26, 2016 at 03:54:07PM -0700, Bart Van Assche wrote:
> Instead of manipulating both QUEUE_FLAG_STOPPED and BLK_MQ_S_STOPPED
> in the dm start and stop queue functions, only manipulate the latter
> flag. Change blk_queue_stopped() tests into blk_mq_queue_stopped().
> 
> Signed-off-by: Bart Van Assche 
> Reviewed-by: Christoph Hellwig 

Looks good,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 04/12] blk-mq: Move more code into blk_mq_direct_issue_request()

[Sagi Grimberg]

Looks good,

Reviewed-by: Sagi Grimberg 
--
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 10/12] SRP transport, scsi-mq: Wait for .queue_rq() if necessary

[Sagi Grimberg]

Thanks for moving it,

Reviewed-by: Sagi Grimberg 
--
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 09/12] SRP transport: Move queuecommand() wait code to SCSI core

[Sagi Grimberg]

Reviewed-by: Sagi Grimberg 
--
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 85751] iSCSI initiator lockup during logout

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=85751

Jaden  changed:

   What|Removed |Added

 CC||jaden1...@gmail.com

--- Comment #4 from Jaden  ---
I also encountered the similar issue, but not in logout stage. If the links are
down could also meet this issue occasionally. Below are my reproduce steps:

1.while :; do dd if=/dev/sdc of=/dev/null bs=1K count=1 iflag=direct; done
2.kill -SIGSTOP `pidof iscsid`
3.iptables -A OUTPUT -p tcp --dport 3260 -j DROP

I think it is cause by a status conflict between the waitting for lost IO
request and iscsi device remove procedure. Any new thoughs?

-- 
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 02/12] blk-mq: Introduce blk_mq_hctx_stopped()

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 
--
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 05/11] mpt3sas: Bump driver version as "14.100.00.00"

[Hannes Reinecke]

On 10/26/2016 10:04 AM, Suganath Prabu S wrote:
> Signed-off-by: Chaitra P B 
> Signed-off-by: Sathya Prakash 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index e923c91..6f03a86 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -73,8 +73,8 @@
>  #define MPT3SAS_DRIVER_NAME  "mpt3sas"
>  #define MPT3SAS_AUTHOR "Avago Technologies 
> "
>  #define MPT3SAS_DESCRIPTION  "LSI MPT Fusion SAS 3.0 Device Driver"
> -#define MPT3SAS_DRIVER_VERSION   "13.100.00.00"
> -#define MPT3SAS_MAJOR_VERSION13
> +#define MPT3SAS_DRIVER_VERSION   "14.100.00.00"
> +#define MPT3SAS_MAJOR_VERSION14
>  #define MPT3SAS_MINOR_VERSION100
>  #define MPT3SAS_BUILD_VERSION0
>  #define MPT3SAS_RELEASE_VERSION  00
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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] hpsa: add generate controller NMI on lockup

[Hannes Reinecke]

On 10/27/2016 12:21 AM, Don Brace wrote:
> Tell the controller to NMI when the controller deadlocks.
> 
> Reviewed-by: Scott Benesh 
> Reviewed-by: Scott Teel 
> Reviewed-by: Kevin Barnett 
> Signed-off-by: Don Brace 
> ---
>  drivers/scsi/hpsa.c |6 ++
>  drivers/scsi/hpsa_cmd.h |1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 798fb20..9fb739c 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -8451,6 +8451,12 @@ static void controller_lockup_detected(struct 
> ctlr_info *h)
>   "lockup detected after %d but scratchpad register is 
> zero\n",
>   h->heartbeat_sample_interval / HZ);
>   lockup_detected = 0x;
> + } else if (lockup_detected == 0x) {
> + /*
> +  * Ring controller NMI doorbell
> +  */
> + dev_warn(>pdev->dev, "Telling controller to do an NMI\n");
> + writel(DOORBELL_GENERATE_NMI, h->vaddr + SA5_DOORBELL);
>   }
>   set_lockup_detected_for_all_cpus(h, lockup_detected);
>   spin_unlock_irqrestore(>lock, flags);
> diff --git a/drivers/scsi/hpsa_cmd.h b/drivers/scsi/hpsa_cmd.h
> index a584cdf..d186f80 100644
> --- a/drivers/scsi/hpsa_cmd.h
> +++ b/drivers/scsi/hpsa_cmd.h
> @@ -142,6 +142,7 @@
>  #define DOORBELL_CTLR_RESET  0x0004l
>  #define DOORBELL_CTLR_RESET2 0x0020l
>  #define DOORBELL_CLEAR_EVENTS0x0040l
> +#define DOORBELL_GENERATE_NMI0x0080l
>  
>  #define CFGTBL_Trans_Simple 0x0002l
>  #define CFGTBL_Trans_Performant 0x0004l
> 
Care to elaborate a bit more here?
'Generating NMI' tends to ring some alarm bells, so I'd rather know
where the NMI is actually generated, and if is could reflect back to the
system ...

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 11/11] mpt3sas: Bump driver version as "14.101.00.00"

[Hannes Reinecke]

On 10/26/2016 10:04 AM, Suganath Prabu S wrote:
> Signed-off-by: Chaitra P B 
> Signed-off-by: Sathya Prakash 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 5d9ae15..8de0eda 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -73,9 +73,9 @@
>  #define MPT3SAS_DRIVER_NAME  "mpt3sas"
>  #define MPT3SAS_AUTHOR "Avago Technologies 
> "
>  #define MPT3SAS_DESCRIPTION  "LSI MPT Fusion SAS 3.0 Device Driver"
> -#define MPT3SAS_DRIVER_VERSION   "14.100.00.00"
> +#define MPT3SAS_DRIVER_VERSION   "14.101.00.00"
>  #define MPT3SAS_MAJOR_VERSION14
> -#define MPT3SAS_MINOR_VERSION100
> +#define MPT3SAS_MINOR_VERSION101
>  #define MPT3SAS_BUILD_VERSION0
>  #define MPT3SAS_RELEASE_VERSION  00
>  
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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/4] hpsa: correct lockup detector pci_disable_device

[Hannes Reinecke]

On 10/27/2016 12:21 AM, Don Brace wrote:
> need to check if the device is already disabled first
> 
> Reviewed-by: Scott Benesh 
> Reviewed-by: Scott Teel 
> Signed-off-by: Don Brace 
> ---
>  drivers/scsi/hpsa.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index d007ec1..798fb20 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -8456,7 +8456,8 @@ static void controller_lockup_detected(struct ctlr_info 
> *h)
>   spin_unlock_irqrestore(>lock, flags);
>   dev_warn(>pdev->dev, "Controller lockup detected: 0x%08x after %d\n",
>   lockup_detected, h->heartbeat_sample_interval / HZ);
> - pci_disable_device(h->pdev);
> + if (pci_is_enabled(h->pdev))
> + pci_disable_device(h->pdev);
>   fail_all_outstanding_cmds(h);
>  }
>  
> 
Meh.
Why is pci_disable_device() not checking for it?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 1/2] scsi: Handle Unit Attention when issuing SCSI command

[Hannes Reinecke]

On 10/26/2016 07:38 PM, Brian King wrote:
> On 10/26/2016 11:15 AM, Bart Van Assche wrote:
>> On Wed, 2016-10-26 at 08:52 -0700, James Bottomley wrote:
>>> On Wed, 2016-10-26 at 08:42 -0700, Bart Van Assche wrote:
 Can you elaborate on this? Since the sense buffer is available in 
 scsi_io_completion() and since that function already calls 
 scsi_command_normalize_sense() this function seems like a good 
 candidate to me to add retry logic for REQ_TYPE_BLOCK_PC requests.
>>>
>>> UAs are used to signal AENs to userspace control processes that use
>>> BLOCK_PC, like CD changers, burners and scanners.  If we eat UAs
>>> inside scsi_io_completion(), we could potentially break any userspace
>>> control system that relies on AENs.
>>
>> Ignoring the SCSI error handler, the call sequence for reporting UAs to
>> user space is as follows: scsi_softirq_done() ->
>> scsi_decide_disposition() -> scsi_check_sense() -> scsi_report_sense().
>> This means that scsi_report_sense() is called before
>> scsi_io_completion() is called. I think this means that what
>> scsi_io_completion() decides cannot affect UA reporting to user space?
> 
> I think what would break if we just started eating UAs in scsi_io_completion
> for BLOCK_PC is applications that are building BLOCK_PC requests and then
> checking the sense data in the completed command for a UA. I think this is 
> what
> James was referring to. If we wanted to collapse some of this retry logic,
> it seems like we might need a way to differentiate between different types of 
> BLOCK_PC
> requests. A new cmd_flag on struct request, or more generally, a way for scsi
> or any user of struct request to pass driver specific data along with the 
> request.
> This is something I've wanted for ipr, which I've sort of worked around 
> currently.
> 
I'm fully with you here.

BLOCK_PC is currently used indiscriminately for all non-filesystem
commands, ie for commands where the raw cdb is passed in via req->special.

As such, is has a dual meaning:
- A pre-filled CDB
- do not evaluate the sense code

If we could split this up in having one flag for a pre-filled CDB and
another one for evaluating sense code we should be able to resolve this
situation.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 03/11] mpt3sas: Implement device_remove_in_progress check in IOCTL path

[Hannes Reinecke]

On 10/26/2016 10:04 AM, Suganath Prabu S wrote:
> When device missing event arrives, device_remove_in_progress bit will be
> set and hence driver has to stop sending IOCTL commands.Now the check has
> been added in IOCTL path to test device_remove_in_progress bit is set, if
> so then IOCTL will be failed printing failure message.
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Sathya Prakash 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.c  | 19 +++
>  drivers/scsi/mpt3sas/mpt3sas_base.h  |  5 
>  drivers/scsi/mpt3sas/mpt3sas_ctl.c   | 46 
> ++--
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 24 ++-
>  4 files changed, 86 insertions(+), 8 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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/12] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

[Hannes Reinecke]

On 10/27/2016 12:54 AM, Bart Van Assche wrote:
> Instead of manipulating both QUEUE_FLAG_STOPPED and BLK_MQ_S_STOPPED
> in the dm start and stop queue functions, only manipulate the latter
> flag. Change blk_queue_stopped() tests into blk_mq_queue_stopped().
> 
> Signed-off-by: Bart Van Assche 
> Reviewed-by: Christoph Hellwig 
> Cc: Mike Snitzer 
> ---
>  drivers/md/dm-rq.c | 18 ++
>  1 file changed, 2 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> index fbd37b4..d47a504 100644
> --- a/drivers/md/dm-rq.c
> +++ b/drivers/md/dm-rq.c
> @@ -75,12 +75,6 @@ static void dm_old_start_queue(struct request_queue *q)
>  
>  static void dm_mq_start_queue(struct request_queue *q)
>  {
> - unsigned long flags;
> -
> - spin_lock_irqsave(q->queue_lock, flags);
> - queue_flag_clear(QUEUE_FLAG_STOPPED, q);
> - spin_unlock_irqrestore(q->queue_lock, flags);
> -
>   blk_mq_start_stopped_hw_queues(q, true);
>   blk_mq_kick_requeue_list(q);
>  }
> @@ -105,16 +99,8 @@ static void dm_old_stop_queue(struct request_queue *q)
>  
>  static void dm_mq_stop_queue(struct request_queue *q)
>  {
> - unsigned long flags;
> -
> - spin_lock_irqsave(q->queue_lock, flags);
> - if (blk_queue_stopped(q)) {
> - spin_unlock_irqrestore(q->queue_lock, flags);
> + if (blk_mq_queue_stopped(q))
>   return;
> - }
> -
> - queue_flag_set(QUEUE_FLAG_STOPPED, q);
> - spin_unlock_irqrestore(q->queue_lock, flags);
>  
>   /* Avoid that requeuing could restart the queue. */
>   blk_mq_cancel_requeue_work(q);
> @@ -341,7 +327,7 @@ static void __dm_mq_kick_requeue_list(struct 
> request_queue *q, unsigned long mse
>   unsigned long flags;
>  
>   spin_lock_irqsave(q->queue_lock, flags);
> - if (!blk_queue_stopped(q))
> + if (!blk_mq_queue_stopped(q))
>   blk_mq_delay_kick_requeue_list(q, msecs);
>   spin_unlock_irqrestore(q->queue_lock, flags);
>  }
> 
Ah. Right. That answers my previous question.

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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/12] blk-mq: Add a kick_requeue_list argument to blk_mq_requeue_request()

[Hannes Reinecke]

On 10/27/2016 12:53 AM, Bart Van Assche wrote:
> Most blk_mq_requeue_request() and blk_mq_add_to_requeue_list() calls
> are followed by kicking the requeue list. Hence add an argument to
> these two functions that allows to kick the requeue list. This was
> proposed by Christoph Hellwig.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Christoph Hellwig 
> Cc: Hannes Reinecke 
> Cc: Sagi Grimberg 
> Cc: Johannes Thumshirn 
> ---
>  block/blk-flush.c|  5 +
>  block/blk-mq.c   | 10 +++---
>  drivers/block/xen-blkfront.c |  2 +-
>  drivers/md/dm-rq.c   |  2 +-
>  drivers/nvme/host/core.c |  2 +-
>  drivers/scsi/scsi_lib.c  |  4 +---
>  include/linux/blk-mq.h   |  5 +++--
>  7 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/block/blk-flush.c b/block/blk-flush.c
> index 6a14b68..a834aed 100644
> --- a/block/blk-flush.c
> +++ b/block/blk-flush.c
> @@ -134,10 +134,7 @@ static void blk_flush_restore_request(struct request *rq)
>  static bool blk_flush_queue_rq(struct request *rq, bool add_front)
>  {
>   if (rq->q->mq_ops) {
> - struct request_queue *q = rq->q;
> -
> - blk_mq_add_to_requeue_list(rq, add_front);
> - blk_mq_kick_requeue_list(q);
> + blk_mq_add_to_requeue_list(rq, add_front, true);
>   return false;
>   } else {
>   if (add_front)
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 4945437..688bcc3 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -492,12 +492,12 @@ static void __blk_mq_requeue_request(struct request *rq)
>   }
>  }
>  
> -void blk_mq_requeue_request(struct request *rq)
> +void blk_mq_requeue_request(struct request *rq, bool kick_requeue_list)
>  {
>   __blk_mq_requeue_request(rq);
>  
>   BUG_ON(blk_queued_rq(rq));
> - blk_mq_add_to_requeue_list(rq, true);
> + blk_mq_add_to_requeue_list(rq, true, kick_requeue_list);
>  }
>  EXPORT_SYMBOL(blk_mq_requeue_request);
>  
> @@ -535,7 +535,8 @@ static void blk_mq_requeue_work(struct work_struct *work)
>   blk_mq_start_hw_queues(q);
>  }
>  
> -void blk_mq_add_to_requeue_list(struct request *rq, bool at_head)
> +void blk_mq_add_to_requeue_list(struct request *rq, bool at_head,
> + bool kick_requeue_list)
>  {
>   struct request_queue *q = rq->q;
>   unsigned long flags;
> @@ -554,6 +555,9 @@ void blk_mq_add_to_requeue_list(struct request *rq, bool 
> at_head)
>   list_add_tail(>queuelist, >requeue_list);
>   }
>   spin_unlock_irqrestore(>requeue_lock, flags);
> +
> + if (kick_requeue_list)
> + blk_mq_kick_requeue_list(q);
>  }
>  EXPORT_SYMBOL(blk_mq_add_to_requeue_list);
>  
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 9908597..1ca702d 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2043,7 +2043,7 @@ static int blkif_recover(struct blkfront_info *info)
>   /* Requeue pending requests (flush or discard) */
>   list_del_init(>queuelist);
>   BUG_ON(req->nr_phys_segments > segs);
> - blk_mq_requeue_request(req);
> + blk_mq_requeue_request(req, false);
>   }
>   blk_mq_kick_requeue_list(info->rq);
>  
> diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> index dc75bea..fbd37b4 100644
> --- a/drivers/md/dm-rq.c
> +++ b/drivers/md/dm-rq.c
> @@ -354,7 +354,7 @@ EXPORT_SYMBOL(dm_mq_kick_requeue_list);
>  
>  static void dm_mq_delay_requeue_request(struct request *rq, unsigned long 
> msecs)
>  {
> - blk_mq_requeue_request(rq);
> + blk_mq_requeue_request(rq, false);
>   __dm_mq_kick_requeue_list(rq->q, msecs);
>  }
>  
Hmm. __dm_mq_kick_requeue_list() does essentially the same.
Have you checked if you can use 'true' here and drop the call to it?
However, it does take the queue_lock when doing so.
Is that required? None of the other drivers do it ...

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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: A question regarding "multiple SGL"

[Christoph Hellwig]

Hi Robert,

please explain your use cases that isn't handled.  The one and only
reason to set MSDBD to 1 is to make the code a lot simpler given that
there is no real use case for supporting more.

RDMA uses memory registrations to register large and possibly
discontiguous data regions for a single rkey, aka single SGL descriptor
in NVMe terms.  There would be two reasons to support multiple SGL
descriptors:  a) to support a larger I/O size than supported by a single
MR, or b) to support a data region format not mappable by a single
MR.

iSER only supports a single rkey (or stag in IETF terminology) and has
been doing fine on a) and mostly fine on b).   There are a few possible
data layouts not supported by the traditional IB/iWarp FR WRs, but the
limit is in fact exactly the same as imposed by the NVMe PRPs used for
PCIe NVMe devices, so the Linux block layer has support to not generate
them.  Also with modern Mellanox IB/RoCE hardware we can actually
register completely arbitrary SGLs.  iSER supports using this registration
mode already with a trivial code addition, but for NVMe we didn't have a
pressing need yet.
--
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: A question regarding "multiple SGL"

[Qiuxin (robert)]

Hi Christoph,

Thanks , got it.

Could you please do me favor to let me know the background why we ONLY support 
" MSDBD ==1"?   I am NOT trying to resist or oppose anything , I just want to 
know the reason.  You know,  it is a little wired for me, as  "MSDBD ==1" does 
not fulfill all the use cases which is depicted in the spec.

Best,
Robert Qiuxin

Robert Qiuxin
华为技术有限公司 Huawei Technologies Co., Ltd.
Phone: +86-755-28420357
Fax: 
Mobile: +86 15986638429
Email: qiu...@huawei.com
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com 

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which 
is intended only for the person or entity whose address is listed above. Any 
use of the 
information contained herein in any way (including, but not limited to, total 
or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by 
phone or email immediately and delete it!
-邮件原件-
发件人: Christoph Hellwig [mailto:h...@lst.de] 
发送时间: 2016年10月27日 14:41
收件人: 鑫愿
抄送: Bart Van Assche; Jens Axboe; linux-bl...@vger.kernel.org; James Bottomley; 
Martin K. Petersen; Mike Snitzer; linux-r...@vger.kernel.org; Ming Lei; 
linux-n...@lists.infradead.org; Keith Busch; Doug Ledford; 
linux-scsi@vger.kernel.org; Laurence Oberman; Christoph Hellwig; Tiger zhao; 
Qiuxin (robert)
主题: Re: A question regarding "multiple SGL"

Hi Robert,

There is no feature called "Multiple SGL in one NVMe capsule".  The NVMe over 
Fabrics specification allows a controller to advertise how many SGL descriptors 
it supports using the MSDBD Identify field:

"Maximum SGL Data Block Descriptors (MSDBD): This field indicates the maximum 
number of (Keyed) SGL Data Block descriptors that a host is allowed to place in 
a capsule. A value of 0h indicates no limit."

Setting this value to 1 is perfectly valid.  Similarly a host is free to chose 
any number of SGL descriptors between 0 (only for command that don't transfer 
data) to the limit imposed by the controller using the MSDBD field.

There are no plans to support a MSDBD value larger than 1 in the Linux NVMe 
target, and there are no plans to ever submit commands with multiple SGLs from 
the host driver either.

Cheers,
Christoph

Re: A question regarding "multiple SGL"

[Christoph Hellwig]

Hi Robert,

There is no feature called "Multiple SGL in one NVMe capsule".  The
NVMe over Fabrics specification allows a controller to advertise how
many SGL descriptors it supports using the MSDBD Identify field:

"Maximum SGL Data Block Descriptors (MSDBD): This field indicates the
maximum number of (Keyed) SGL Data Block descriptors that a host is allowed to
place in a capsule. A value of 0h indicates no limit."

Setting this value to 1 is perfectly valid.  Similarly a host is free
to chose any number of SGL descriptors between 0 (only for command that
don't transfer data) to the limit imposed by the controller using the
MSDBD field.

There are no plans to support a MSDBD value larger than 1 in the Linux
NVMe target, and there are no plans to ever submit commands with multiple
SGLs from the host driver either.

Cheers,
Christoph
--
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