[PATCH] [RESEND] qla2xxx: fix potential deadlock on ha-hardware_lock
Lockdep reports:
=== [ cut here ] ===
=
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
-
qla2xxx_1_dpc/368 just changed the state of lock:
((ha-vport_slock)-rlock){+.}, at: [a009b377]
qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
((ha-hardware_lock)-rlock){-.}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock((ha-vport_slock)-rlock);
local_irq_disable();
lock((ha-hardware_lock)-rlock);
lock((ha-vport_slock)-rlock);
Interrupt
lock((ha-hardware_lock)-rlock);
=== [ cut here ] ===
Fix the potential deadlock by disabling IRQs while holding ha-vport_slock.
Reported-and-tested-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
drivers/scsi/qla2xxx/qla_init.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 799a58b..48fca47 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
uint8_t domain;
charconnect_type[22];
struct qla_hw_data *ha = vha-hw;
+ unsigned long flags;
/* Get host addresses. */
rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
vha-d_id.b.area = area;
vha-d_id.b.al_pa = al_pa;
- spin_lock(ha-vport_slock);
+ spin_lock_irqsave(ha-vport_slock, flags);
qlt_update_vp_map(vha, SET_AL_PA);
- spin_unlock(ha-vport_slock);
+ spin_unlock_irqrestore(ha-vport_slock, flags);
if (!vha-flags.init_done)
ql_log(ql_log_info, vha, 0x2010,
--
Jiri Kosina
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
Re: standards revisions
On Sun, 2012-10-07 at 11:11 -0700, Nicholas A. Bellinger wrote: On Sun, 2012-10-07 at 09:16 +0100, James Bottomley wrote: On Sat, 2012-10-06 at 23:11 -0700, Nicholas A. Bellinger wrote: On Sat, 2012-10-06 at 21:49 -0400, Christoph Hellwig wrote: Currenly all non-pscsi bakcneds report their standards version as SPC 2 via -get_device_rev. No, the proper on-the-wire bits to signal SPC-3 compliance are already being returned by virtual backend drivers within standard INQUIRY payload data. Notice the comment: root@tifa:/usr/src/target-pending.git# grep SCSI_SPC_2 drivers/target/*.c drivers/target/target_core_file.c:return SCSI_SPC_2; /* Returns SPC-3 in Initiator Data */ drivers/target/target_core_iblock.c: return SCSI_SPC_2; /* Returns SPC-3 in Initiator Data */ drivers/target/target_core_rd.c: return SCSI_SPC_2; /* Returns SPC-3 in Initiator Data */ That's causing confusion, I think! In addition to putting it into the inquirty data in spc_emulate_inquiry_std we also use it in two places to check on the version of the persistent reservation and alua support. What is the benefit of supporting the old-style SCSI 2 reservations and ALUA support when they can't be used at all with the virtual backends, and can only be used in the corner case emulated ALUA/PR support for pscsi? It's the include/scsi/scsi.h SCSI_3 + SCSI_SPC_* version definition names that are incorrect: #define SCSI_UNKNOWN0 #define SCSI_1 1 #define SCSI_1_CCS 2 #define SCSI_2 3 #define SCSI_3 4/* SPC */ #define SCSI_SPC_2 5 #define SCSI_SPC_3 6 from spc4r30 section 6.4.2 Standard INQUIRY data, Table 142 -- Version: 00h The device server does not claim conformance to any standard. 01h to 02h Obsolete 03h The device server complies to ANSI INCITS 301-1997 (a withdrawn standard). 04h The device server complies to ANSI INCITS 351-2001 (SPC-2). 05h The device server complies to ANSI INCITS 408-2005 (SPC-3). 06h The device server complies to this standard. How about the following patch to fix the long-standing incorrect name usage of these three scsi.h defines..? Because it's not incorrect. Your confusion is that the SCSI_ constants should match the inquiry data ... they shouldn't. No, my current confusion is stemming from why it's OK for SCSI_SPC_[2,3] constant names+values to not match what is actually defined in SPC-4 drafts for what target INQUIRY emulation bits end up going 'over the wire'. OK, I don't understand what you didn't get about the explanation below. But the gist is it's not a constant representing inquiry[2]7; it's an ordered set of enumerations representing gross capabilities abstracted into sdev-scsi_level. Look where we set scsi_level in scsi_scan.c:708-713. We have to fit an extra identifier for SCSI_1_CCS so the scsi_level doesn't actually match the inquiry data; it's incremented by 1 for SCSI_3 and above. The extra increment by 1 is required by some Linux/SCSI client implementation dependent requirements, yes..? Not at all, no. It's defined and used in the mid-layer. ULDs may consult it or even (once in the case of usb) modify scsi_level, but they don't use it for directly altering inquiry data. SCSI_3 does exist, by the way, it was defined in the first version of SPC and there are some devices which conform to it. Regardless, SCSI_SPC_[2,3] - SCSI_SPC[3,4] constants for target-core + scsi-core should still be re-named to avoid the extra confusion this introduces for folks reading code. I'm not convinced there is confusion; this use of enumerated levelling goes back to 2.2 and no-one else has had a problem with it. You're the only one whose had an issue and it does seem to be because you didn't bother reading the comment above their definitions in the header file which does explain what's going on. James -- 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] [RESEND] qla2xxx: fix potential deadlock on ha-hardware_lock
On 10/08/2012 12:53 PM, Jiri Kosina wrote:
Lockdep reports:
=== [ cut here ] ===
=
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
-
qla2xxx_1_dpc/368 just changed the state of lock:
((ha-vport_slock)-rlock){+.}, at: [a009b377]
qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
((ha-hardware_lock)-rlock){-.}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock((ha-vport_slock)-rlock);
local_irq_disable();
lock((ha-hardware_lock)-rlock);
lock((ha-vport_slock)-rlock);
Interrupt
lock((ha-hardware_lock)-rlock);
=== [ cut here ] ===
Fix the potential deadlock by disabling IRQs while holding ha-vport_slock.
Reported-and-tested-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
This needs a CC to stable also right?
Regards,
Srivatsa S. Bhat
---
drivers/scsi/qla2xxx/qla_init.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 799a58b..48fca47 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
uint8_t domain;
charconnect_type[22];
struct qla_hw_data *ha = vha-hw;
+ unsigned long flags;
/* Get host addresses. */
rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
vha-d_id.b.area = area;
vha-d_id.b.al_pa = al_pa;
- spin_lock(ha-vport_slock);
+ spin_lock_irqsave(ha-vport_slock, flags);
qlt_update_vp_map(vha, SET_AL_PA);
- spin_unlock(ha-vport_slock);
+ spin_unlock_irqrestore(ha-vport_slock, flags);
if (!vha-flags.init_done)
ql_log(ql_log_info, vha, 0x2010,
--
Regards,
Srivatsa S. Bhat
--
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 v7 2/6] scsi: sr: support runtime pm
On Sun, Sep 30, 2012 at 03:43:27PM -0400, Alan Stern wrote: On Sun, 30 Sep 2012, Jeff Garzik wrote: The simple fact of only ZPODD devices out there are ATA is not the decision-maker for where the code should live. It is more a question where ZPODD belongs in the device/command set model currently employed. I don't really accept this argument. It's a little like saying: The tty layer uses ioctl commands to control RS232 line settings; therefore RS232 settings should be handled in the VFS layer as part of the ioctl core. Regardless, according to Aaron the ZP power-off stuff is currently implemented only in ACPI, tied more closely to the ATA layer than the SCSI layer (though not part of either). It is not part of the SCSI spec in any form. The mechanism of SATA ODD zero power model is specified in Mount Fuji spec v8 section 15 describing what the ODD needs support, how to sense if the ODD is ready to be powered off and on power up what needs to be done, etc. And the actual power off and wakeup is implemented in ACPI and SATA. Now it's true that determining whether a device is in the right state for power to be removed involves sending a TEST UNIT READY command, which is of course a SCSI command. This seems to be incidental to the overall scheme, however. I need to add that, there are 2 schemes to sense if the ODD is ready to be powered off: 1 the one I used here, by checking if the door is closed and no media inside with test_unit_ready; 2 some ZP capable ODDs can report zero power ready(ZPReady) event to host when queried, eliminating the need of host checking the conditions. Thanks, Aaron -- 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: [V5 PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
Hi James, Please let me know if you are expecting any more changes to this driver to resume its review. I have addressed all review comments as of the last series of patches (below). Thanks, Naresh. On 9/24/2012 10:47 PM, Naresh Kumar Inna wrote: This is the initial submission of the Chelsio FCoE offload driver (csiostor) to the upstream kernel. This driver currently supports FCoE offload functionality over Chelsio T4-based 10Gb Converged Network Adapters. The following patches contain the driver sources for csiostor driver and updates to firmware/hardware header files shared between csiostor, cxgb4 (Chelsio T4-based NIC driver) and cxgb4vf (Chelsio T4-based Virtual Function NIC driver). The csiostor driver is dependent on these header updates. These patches have been generated against scsi 'misc' branch. csiostor is a low level SCSI driver that interfaces with PCI, SCSI midlayer and FC transport subsystems. This driver claims the FCoE PCIe function on Chelsio Converged Network Adapters. It relies on firmware events for slow path operations like discovery, thereby offloading session management. The driver programs firmware via Work Request interfaces for fast path I/O offload features. Version V5 of the patches addresses James's comment, primary among them being moving to the lockless version of queuecommand(). Rest of the V5 changes are listed in the individual patches. Here is the brief description of patches: [V5 PATCH 1/8]: Updates to header files shared between cxgb4, cxgb4vf and csiostor. [V5 PATCH 2/8]: Header files part 1. [V5 PATCH 3/8]: Header files part 2. [V5 PATCH 4/8]: Driver initialization and Work Request services. [V5 PATCH 5/8]: FC transport interfaces and mailbox services. [V5 PATCH 6/8]: Local and remote port state tracking functionality. [V5 PATCH 7/8]: Interrupt handling and fast path I/O functionality. [V5 PATCH 8/8]: Hardware interface, Makefile and Kconfig changes. Naresh Kumar Inna (8): cxgb4/cxgb4vf: Chelsio FCoE offload driver submission (common header updates). csiostor: Chelsio FCoE offload driver submission (headers part 1). csiostor: Chelsio FCoE offload driver submission (headers part 2). csiostor: Chelsio FCoE offload driver submission (sources part 1). csiostor: Chelsio FCoE offload driver submission (sources part 2). csiostor: Chelsio FCoE offload driver submission (sources part 3). csiostor: Chelsio FCoE offload driver submission (sources part 4). csiostor: Chelsio FCoE offload driver submission (sources part 5). drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |2 +- drivers/net/ethernet/chelsio/cxgb4/sge.c| 10 +- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 16 +- drivers/net/ethernet/chelsio/cxgb4/t4_msg.h |1 + drivers/net/ethernet/chelsio/cxgb4/t4_regs.h| 69 +- drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 104 +- drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 11 +- drivers/scsi/Kconfig|1 + drivers/scsi/Makefile |1 + drivers/scsi/csiostor/Kconfig | 19 + drivers/scsi/csiostor/Makefile | 11 + drivers/scsi/csiostor/csio_attr.c | 804 + drivers/scsi/csiostor/csio_defs.h | 121 + drivers/scsi/csiostor/csio_hw.c | 4395 +++ drivers/scsi/csiostor/csio_hw.h | 666 drivers/scsi/csiostor/csio_init.c | 1274 +++ drivers/scsi/csiostor/csio_init.h | 158 + drivers/scsi/csiostor/csio_isr.c| 624 drivers/scsi/csiostor/csio_lnode.c | 2133 +++ drivers/scsi/csiostor/csio_lnode.h | 255 ++ drivers/scsi/csiostor/csio_mb.c | 1769 + drivers/scsi/csiostor/csio_mb.h | 278 ++ drivers/scsi/csiostor/csio_rnode.c | 889 + drivers/scsi/csiostor/csio_rnode.h | 141 + drivers/scsi/csiostor/csio_scsi.c | 2554 + drivers/scsi/csiostor/csio_scsi.h | 342 ++ drivers/scsi/csiostor/csio_wr.c | 1632 + drivers/scsi/csiostor/csio_wr.h | 512 +++ drivers/scsi/csiostor/t4fw_api_stor.h | 578 +++ 29 files changed, 19333 insertions(+), 37 deletions(-) create mode 100644 drivers/scsi/csiostor/Kconfig create mode 100644 drivers/scsi/csiostor/Makefile create mode 100644 drivers/scsi/csiostor/csio_attr.c create mode 100644 drivers/scsi/csiostor/csio_defs.h create mode 100644 drivers/scsi/csiostor/csio_hw.c create mode 100644 drivers/scsi/csiostor/csio_hw.h create mode 100644 drivers/scsi/csiostor/csio_init.c create mode 100644 drivers/scsi/csiostor/csio_init.h create mode 100644 drivers/scsi/csiostor/csio_isr.c create mode 100644 drivers/scsi/csiostor/csio_lnode.c create
Re: [PATCH v7 2/6] scsi: sr: support runtime pm
On Mon, 2012-10-08 at 17:27 +0800, Aaron Lu wrote: On Sun, Sep 30, 2012 at 03:43:27PM -0400, Alan Stern wrote: On Sun, 30 Sep 2012, Jeff Garzik wrote: The simple fact of only ZPODD devices out there are ATA is not the decision-maker for where the code should live. It is more a question where ZPODD belongs in the device/command set model currently employed. I don't really accept this argument. It's a little like saying: The tty layer uses ioctl commands to control RS232 line settings; therefore RS232 settings should be handled in the VFS layer as part of the ioctl core. Regardless, according to Aaron the ZP power-off stuff is currently implemented only in ACPI, tied more closely to the ATA layer than the SCSI layer (though not part of either). It is not part of the SCSI spec in any form. The mechanism of SATA ODD zero power model is specified in Mount Fuji spec v8 section 15 describing what the ODD needs support, how to sense if the ODD is ready to be powered off and on power up what needs to be done, etc. And the actual power off and wakeup is implemented in ACPI and SATA. Now it's true that determining whether a device is in the right state for power to be removed involves sending a TEST UNIT READY command, which is of course a SCSI command. This seems to be incidental to the overall scheme, however. I need to add that, there are 2 schemes to sense if the ODD is ready to be powered off: 1 the one I used here, by checking if the door is closed and no media inside with test_unit_ready; 2 some ZP capable ODDs can report zero power ready(ZPReady) event to host when queried, eliminating the need of host checking the conditions. The way I read the standard is that ZP ODD is a hack to try and get to off and ZPready is the same hack but integrated into the standardised power management states (and hence available to normal power saving). The standard even implies ZP ODD is a less desirable hack by recommending the use of ZPready. The ZPready method, being an extension of the usual SCSI power management model, is pretty much what we support today (especially as the whole thing is timer driven from values in the mode page and happens pretty much invisibly to us). Since the object is to make this as painless as possible, why don't we just implement ZPODD the way the spec recommends? i.e. emulate the timers at an incredibly low level and intercept and emulate the non-disk commands listed in table 321. I bet, in Linux, since we moved basically to GET_EVENT_STATUS_NOTIFICATION, that's the only one that actually needs an emulation. The state model seems to work if you snoop the polled media event, so you wait for no media, then set your internal timer, stop it if we get a media change and power off the device after interval expiry. Thereafter you emulate media event with no change keeping the device powered off. If a disc gets inserted or the eject button is pressed, you see that via the SATA PHY events (so wake the drive) and if the Upper Layer sends an unexpected command, you also power on the drive. That way all of this should be nicely containable within SATA/ACPI. James -- 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: [V5 PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
On Mon, 2012-10-08 at 15:37 +0530, Naresh Kumar Inna wrote: Please let me know if you are expecting any more changes to this driver to resume its review. I have addressed all review comments as of the last series of patches (below). No, I don't think so, but please understand that the review talent is all busy concentrating on the merge window for at least the next week and a bit, so I won't be able to get them to pay attention until 3.7-rc1 is released. Thanks, James -- 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: Request for improved commit tracking between fcoe and scsi trees
On Sun, Oct 07, 2012 at 11:59:29AM +0100, James Bottomley wrote: On Wed, 2012-10-03 at 15:23 -0400, Neil Horman wrote: James, Robert- I've been doing lots of backports of FCoE code to the RHEL tree these last few months, and I've noticed something fairly irritating, and I was wondering if you two could help me out with it (in fact you two are the only two which can). I noticed that commits which are accepted into the FCoE tree that get passed upstream through the scsi tree have their commit hashes altered. I can't find any examples currently, due to the fact that you, Robert, have recently re-cloned your git tree at open-fcoe.org, so all this nastiness has been covered up currently, but if things don't change, this issue will quickly resurface. Regardless, This makes it _really_ difficult to track a given patchs' traversal between trees upstream, and makes my life as a distro subsystem maintainer fairly painful. Normally I would just live with it, but I can't see any reason why it should be this way, given that git can easily prevent this with a pull. James, Robert, could you two please work out a way to provide commit hash consistency between your trees? It would make mine (and I'm sure many other people's) lives, much easier. I'm reluctant to commit to any tracking process that relies on stable commit ids simply because they're illusory in git: if we find a bug in a commit (or even worse a bisection failure) in a tree, we fix it there, which causes the commit id to change. The way I do this type of tracking is via the Subject: line ... why can't you use that? Because git workflows are rooted in the notion that (illusory or not), commits are immutable and stable. Like it or not, its how changes (generally speaking) get tracked. Every time you rewrite history, that gets messed up. And yes, I (and any one else) pulling changes from the scsi tree could track things based on Subject line, but thats got its own problems, as multiple trees run the risk of of having the same trivial subject line, which is far more likely to occur than a sha collision. It would also require a customization of my workflow specifically for the scsi tree that differs from any other tree that I follow. I think in short, I would far prefer to see a pull/merge strategy from your downtream contributing trees, with myself handling the risk of having to do a whole series fixup should you need to fix something during a rewrite in the scsi tree. I'd gladly accept that risk in exchange for the ability to handle your tree like I do others. It seems from your previous note that you're will to go that route, and I certainly appreciate that. Thanks! Neil James -- 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: [Open-FCoE] [RFC PATCH v3 2/4] libfcoe, fcoe, bnx2fc: Add new fcoe control interface
On Fri, Oct 05, 2012 at 09:54:32AM -0700, Robert Love wrote:
This patch does a few things.
1) Makes /sys/bus/fcoe/ctlr_{create,destroy} interfaces.
These interfaces take an ifname and will either
create an FCoE Controller or destroy an FCoE
Controller depending on which file is written to.
The new FCoE Controller will start in a DISABLED
state and will not do discovery or login until it
is ENABLED. This pause will allow us to configure
the FCoE Controller before enabling it.
2) Makes the 'mode' attribute of a fcoe_ctlr_device
writale. This allows the user to configure the mode
in which the FCoE Controller will start in when it
is ENABLED.
Possible modes are 'Fabric', or 'VN2VN'.
The default mode for a fcoe_ctlr{,_device} is 'Fabric'.
Drivers must implement the set_fcoe_ctlr_mode routine
to support this feature.
libfcoe offers an exported routine to set a FCoE
Controller's mode. The mode can only be changed
when the FCoE Controller is DISABLED.
This patch also removes the get_fcoe_ctlr_mode pointer
in the fcoe_sysfs function template, the code in
fcoe_ctlr.c to get the mode and the assignment of
the fcoe_sysfs function pointer to the fcoe_ctlr.c
implementation (in fcoe and bnx2fc). fcoe_sysfs can
return that value for the mode without consulting the
LLD.
3) Make a 'enabled' attribute of a fcoe_ctlr_device. On a
read, fcoe_sysfs will return the attribute's value. On
a write, fcoe_sysfs will call the LLD (if there is a
callback) to notifiy that the enalbed state has changed.
This patch maintains the old FCoE control interfaces as
module parameters, but it adds comments pointing out that
the old interfaces are deprecated.
Signed-off-by: Robert Love robert.w.l...@intel.com
---
Documentation/ABI/testing/sysfs-bus-fcoe | 42 +++
drivers/scsi/bnx2fc/bnx2fc_fcoe.c|1
drivers/scsi/fcoe/fcoe.c |1
drivers/scsi/fcoe/fcoe_sysfs.c | 186
+++---
drivers/scsi/fcoe/fcoe_transport.c | 104 +
include/scsi/fcoe_sysfs.h| 11 ++
include/scsi/libfcoe.h | 16 ++-
7 files changed, 338 insertions(+), 23 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe
b/Documentation/ABI/testing/sysfs-bus-fcoe
index 469d09c..a57bf37 100644
--- a/Documentation/ABI/testing/sysfs-bus-fcoe
+++ b/Documentation/ABI/testing/sysfs-bus-fcoe
@@ -1,14 +1,54 @@
+What:/sys/bus/fcoe/
+Date:August 2012
+KernelVersion: TBD
+Contact: Robert Love robert.w.l...@intel.com, de...@open-fcoe.org
+Description: The FCoE bus. Attributes in this directory are control
interfaces.
+Attributes:
+
+ ctlr_create: 'FCoE Controller' instance creation interface. Writing an
+ ifname to this file will allocate and populate sysfs
with a
+ fcoe_ctlr_device (ctlr_X). The user can then configure any
+ per-port settings and finally write to the
fcoe_ctlr_device's
+ 'start' attribute to begin the kernel's discovery and login
+ process.
+
+ ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
+fcoe_ctlr_device's sysfs name to this file will log the
+fcoe_ctlr_device out of the fabric or otherwise connected
+FCoE devices. It will also free all kernel memory
allocated
+for this fcoe_ctlr_device and any structures associated
+with it, this includes the scsi_host.
+
What:/sys/bus/fcoe/ctlr_X
Date:March 2012
KernelVersion: TBD
Contact: Robert Love robert.w.l...@intel.com, de...@open-fcoe.org
-Description: 'FCoE Controller' instances on the fcoe bus
+Description: 'FCoE Controller' instances on the fcoe bus.
+
+ The FCoE Controller now has a three stage creation process.
+ 1) Write interface name to ctlr_create 2) Configure the FCoE
+ Controller (ctlr_X) 3) Enable the FCoE Controller to begin
+ discovery and login. The FCoE Controller is destroyed by
+ writing it's name, i.e. ctlr_X to the ctlr_delete file.
+
Attributes:
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.
+ mode: Display or change the FCoE Controller's mode. Possible
+ modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
+ is started in 'Fabric' mode then FIP FCF discovery is
+ initiated and ultimately a fabric login is attempted.
+ If a FCoE Controller is started
RE: [PATCH 1/1] Drivers: scsi: storvsc: Account for in-transit packets in the RESET path
-Original Message- From: K. Y. Srinivasan [mailto:k...@microsoft.com] Sent: Tuesday, October 02, 2012 2:04 PM To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org Cc: KY Srinivasan; sta...@vger.kernel.org Subject: [PATCH 1/1] Drivers: scsi: storvsc: Account for in-transit packets in the RESET path Properly account for I/O in transit before returning from the RESET call. In the absense of this patch, we could have a situation where the host may respond to a command that was issued prior to the issuance of the RESET command at some arbitrary time after responding to the RESET command. Currently, the host does not do anything with the RESET command. Signed-off-by: K. Y. Srinivasan k...@microsoft.com Cc: sta...@vger.kernel.org --- drivers/scsi/storvsc_drv.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 528d52b..0144078 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1221,7 +1221,12 @@ static int storvsc_host_reset_handler(struct scsi_cmnd *scmnd) /* * At this point, all outstanding requests in the adapter * should have been flushed out and return to us + * There is a potential race here where the host may be in + * the process of responding when we return from here. + * Just wait for all in-transit packets to be accounted for + * before we return from here. */ + storvsc_wait_to_drain(stor_device); return SUCCESS; } -- 1.7.4.1 James, This patch is critical for running Linux based workloads on our Cloud infrastructure - Azure. Please let me know if there are any issues. Regards, K. Y -- 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] qla2xxx: silence two GCC warnings
Acked-by: Saurav Kashyap saurav.kash...@qlogic.com Thanks, ~Saurav Compiling qla_gs.o (part of the qla2xxx module) triggers two GCC warnings: drivers/scsi/qla2xxx/qla_gs.c: In function Œqla2x00_fdmi_rhba¹: drivers/scsi/qla2xxx/qla_gs.c:1339:7: warning: array subscript is above array bounds [-Warray-bounds] drivers/scsi/qla2xxx/qla_gs.c: In function Œqla2x00_fdmi_register¹: drivers/scsi/qla2xxx/qla_gs.c:1663:15: warning: array subscript is above array bounds [-Warray-bounds] It seems that the sequence of a strcpy followed by a strlen confuses GCC when it is keeping track of array bounds here. (It is not clear to me which array triggers this warning and by how much GCC thinks the subscript is above its bounds. Neither is it clear to me why comparable code in these two functions doesn't trigger this warning.) An easy way to silence these warnings is to use preprocessor macros and strncpy, as that apparently gives GCC enough information to keep track of array bounds. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) Updated for Saurav's request to use strncpy(). 1) Still only compile tested. drivers/scsi/qla2xxx/qla_def.h | 1 + drivers/scsi/qla2xxx/qla_gs.c | 8 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h index 39007f5..8895038 100644 --- a/drivers/scsi/qla2xxx/qla_def.h +++ b/drivers/scsi/qla2xxx/qla_def.h @@ -37,6 +37,7 @@ #include qla_nx.h #define QLA2XXX_DRIVER_NAME qla2xxx #define QLA2XXX_APIDEVql2xapidev +#define QLA2XXX_MANUFACTURER QLogic Corporation /* * We have MAILBOX_REGISTER_COUNT sized arrays in a few places, diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c index 05260d2..824cbcf 100644 --- a/drivers/scsi/qla2xxx/qla_gs.c +++ b/drivers/scsi/qla2xxx/qla_gs.c @@ -1325,8 +1325,8 @@ qla2x00_fdmi_rhba(scsi_qla_host_t *vha) /* Manufacturer. */ eiter = (struct ct_fdmi_hba_attr *) (entries + size); eiter-type = __constant_cpu_to_be16(FDMI_HBA_MANUFACTURER); - strcpy(eiter-a.manufacturer, QLogic Corporation); - alen = strlen(eiter-a.manufacturer); + alen = strlen(QLA2XXX_MANUFACTURER); + strncpy(eiter-a.manufacturer, QLA2XXX_MANUFACTURER, alen + 1); alen += (alen 3) ? (4 - (alen 3)) : 4; eiter-len = cpu_to_be16(4 + alen); size += 4 + alen; @@ -1646,8 +1646,8 @@ qla2x00_fdmi_rpa(scsi_qla_host_t *vha) /* OS device name. */ eiter = (struct ct_fdmi_port_attr *) (entries + size); eiter-type = __constant_cpu_to_be16(FDMI_PORT_OS_DEVICE_NAME); - strcpy(eiter-a.os_dev_name, QLA2XXX_DRIVER_NAME); - alen = strlen(eiter-a.os_dev_name); + alen = strlen(QLA2XXX_DRIVER_NAME); + strncpy(eiter-a.os_dev_name, QLA2XXX_DRIVER_NAME, alen + 1); alen += (alen 3) ? (4 - (alen 3)) : 4; eiter-len = cpu_to_be16(4 + alen); size += 4 + alen; -- 1.7.11.4 This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this 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] [RESEND] qla2xxx: fix potential deadlock on ha-hardware_lock
Acked-by: Saurav Kashyap saurav.kash...@qlogic.com
Thanks,
~Saurav
Lockdep reports:
=== [ cut here ] ===
=
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
-
qla2xxx_1_dpc/368 just changed the state of lock:
((ha-vport_slock)-rlock){+.}, at: [a009b377]
qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
((ha-hardware_lock)-rlock){-.}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock((ha-vport_slock)-rlock);
local_irq_disable();
lock((ha-hardware_lock)-rlock);
lock((ha-vport_slock)-rlock);
Interrupt
lock((ha-hardware_lock)-rlock);
=== [ cut here ] ===
Fix the potential deadlock by disabling IRQs while holding
ha-vport_slock.
Reported-and-tested-by: Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
drivers/scsi/qla2xxx/qla_init.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c
b/drivers/scsi/qla2xxx/qla_init.c
index 799a58b..48fca47 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
uint8_t domain;
charconnect_type[22];
struct qla_hw_data *ha = vha-hw;
+ unsigned long flags;
/* Get host addresses. */
rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
vha-d_id.b.area = area;
vha-d_id.b.al_pa = al_pa;
- spin_lock(ha-vport_slock);
+ spin_lock_irqsave(ha-vport_slock, flags);
qlt_update_vp_map(vha, SET_AL_PA);
- spin_unlock(ha-vport_slock);
+ spin_unlock_irqrestore(ha-vport_slock, flags);
if (!vha-flags.init_done)
ql_log(ql_log_info, vha, 0x2010,
--
Jiri Kosina
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
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this 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
