Testing with Loopback I found, that after a Loopback LUN
has executed a TMR, I can no longer unlink the LUN.
The rm command hangs in transport_clear_lun_ref() at
wait_for_completion(&lun->lun_shutdown_comp)
The reason is, that transport_lun_remove_cmd() is not
called at the end of target_tmr_work().
It seems, that in other fabrics this call happens implicitly
when the fabric drivers call transport_generic_free_cmd()
during their ->queue_tm_rsp().
Unfortunately Loopback seems to not comply to the common way
of calling transport_generic_free_cmd() from ->queue_*().
Instead it calls transport_generic_free_cmd() from its
->check_stop_free() only.
But the ->check_stop_free() is called by
transport_cmd_check_stop_to_fabric() after it has reset the
se_cmd->se_lun pointer.
Therefore the following transport_generic_free_cmd() skips the
transport_lun_remove_cmd().
So this patch re-adds the transport_lun_remove_cmd() at the end
of target_tmr_work(), which was removed during commit
2c9fa49e100f962af988f1c0529231bf14905cda
"scsi: target/core: Make ABORT and LUN RESET handling synchronous"
For fabrics using transport_generic_free_cmd() in the usual way
the double call to transport_lun_remove_cmd() doesn't harm, as
transport_lun_remove_cmd() checks for this situation and does
not release lun_ref twice.
Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bodo Stroesser <bstroesser(a)ts.fujitsu.com>
Tested-by: Bryant G. Ly <bryangly(a)gmail.com>
Reviewed-by: Bart van Assche <bvanassche(a)acm.org>
---
v2:
- Resend of the same patch with added tags "Fixes:",
"Cc: stable@.." and "Reviewed-by:"
drivers/target/target_core_transport.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index 594b724bbf79..264a822c0bfa 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3350,6 +3350,7 @@ static void target_tmr_work(struct work_struct *work)
cmd->se_tfo->queue_tm_rsp(cmd);
+ transport_lun_remove_cmd(cmd);
transport_cmd_check_stop_to_fabric(cmd);
return;
--
2.12.3
Root Complex Integrated devices (RCiEP) do not have a Root Port before the
device. pci_configure_mps() should simply stick the max value for MaxPayload
size in Device Control, and for MaxReadReq. Unless pcie=pcie_bus-peer2peer
is used in kernel commandline PCIE_BUS_PEER2PEER.
When MPS is configured lower, it could result in reduced performance.
Fixes: 9dae3a97297f ("PCI: Move MPS configuration check to pci_configure_device()")
Signed-off-by: Ashok Raj <ashok.raj(a)intel.com>
Tested-by: Dave Jiang <dave.jiang(a)intel.com>
To: Bjorn Helgaas <bhelgaas(a)google.com>
To: linux-pci(a)vger.kernel.org
Cc: linux-kernel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org
Cc: Ashok Raj <ashok.raj(a)intel.com>
---
drivers/pci/probe.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index eeff8a07..a738b1c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1895,13 +1895,34 @@ static void pci_configure_mps(struct pci_dev *dev)
struct pci_dev *bridge = pci_upstream_bridge(dev);
int mps, mpss, p_mps, rc;
- if (!pci_is_pcie(dev) || !bridge || !pci_is_pcie(bridge))
+ if (!pci_is_pcie(dev))
return;
/* MPS and MRRS fields are of type 'RsvdP' for VFs, short-circuit out */
if (dev->is_virtfn)
return;
+ /*
+ * If this is a Root Complex Integrated Endpoint
+ * Simply program the max value from DEVCAP. No additional
+ * Lookup is necessary
+ */
+ if (pci_pcie_type(dev) == PCI_EXP_TYPE_RC_END) {
+ if (pcie_bus_config == PCIE_BUS_PEER2PEER)
+ mps = 128;
+ else
+ mps = 128 << dev->pcie_mpss;
+ rc = pcie_set_mps(dev, mps);
+ if (rc) {
+ pci_warn(dev, "can't set Max Payload Size to %d; if necessary, use \"pci=pcie_bus_safe\" and report a bug\n",
+ mps);
+ return;
+ }
+ }
+
+ if (!bridge || !pci_is_pcie(bridge))
+ return;
+
mps = pcie_get_mps(dev);
p_mps = pcie_get_mps(bridge);
--
2.7.4