kernel.git/drivers/scsi/fcoe/fcoe.c, branch linux-3.8.y

[SCSI] fcoe: Fix write errors on NPIV ports

2012-10-07T10:49:34Z

SCSI errors were generated while writing to LUNs connected via NPIV ports. Debugging this it was found that the FCoE packets transmitted via the NPIV ports were not tagged with correct user priority as negotiated with peer by DCB agent. This resulted in FCoE traffic going with priority zero(0) that did not have priority flow control (PFC) enabled for it. The initiator after transferring data to the target never saw any reply indicating the transfer was complete. This resulted in error recovery (ABTS) and SCSI command retries by the scsi-mid layer; eventually resulting in I/O errors. This patch fixes this issue by keeping the FCoE user priority information in the fcoe_interface instance that is common for both the physical port as well as NPIV ports connected to that physical port; instead of storing it in fcoe_port structure that has a per port instance. Signed-off-by: Neerav Parikh Acked-by: Yi Zou Acked-by: John Fastabend Tested-by: Marcus Dennis Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] fcoe: Cleanup locking on fcoe_percpu_receive_thread

2012-07-20T07:58:55Z

Noticed that we can shuffle the code around in fcoe_percpu_receive_thread a bit and avoid taking the fcoe_rx_list lock twice per iteration. This should improve throughput somewhat. With this change we take the lock, and check for new frames in a single critical section. Only if the list is empty do we drop the lock and re-acquire it after being signaled to wake up. Change Notes: v2) did some further cleanup on the patch by replacing the 2nd call of spin_lock/splice_init with a goto to the top of the outer loop. This allows me to change the inner while loop to an if conditional and remove the sencond check of kthread_should_stop. Based on suggestion from Vasu Dev. Signed-off-by: Neil Horman Acked-by: Vasu Dev Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfc, fcoe, bnx2fc: cleanup fcoe_dev_stats

2012-07-20T07:31:47Z

The libfc is used by fcoe but fcoe agnostic, and therefore should not have any fcoe references. So renaming fcoe_dev_stats from libfc as its for fc_stats. After that libfc is fcoe string free except some strings for Open-FCoE.org. Signed-off-by: Vasu Dev Acked-by : Robert Love Tested-by: Ross Brattain Acked-by: Bhanu Prakash Gollapudi Signed-off-by: James Bottomley

[SCSI] fcoe, bnx2fc, libfcoe: SW FCoE and bnx2fc use FCoE Syfs

2012-05-23T08:43:13Z

This patch has the SW FCoE driver and the bnx2fc driver make use of the new fcoe_sysfs API added earlier in this patch series. After this patch a fcoe_ctlr_device is allocated with private data in this order. +------------------+ +------------------+ | fcoe_ctlr_device | | fcoe_ctlr_device | +------------------+ +------------------+ | fcoe_ctlr | | fcoe_ctlr | +------------------+ +------------------+ | fcoe_interface | | bnx2fc_interface | +------------------+ +------------------+ libfcoe also takes part in this new model since it discovers and manages fcoe_fcf instances. The memory allocation is different for FCFs. I didn't want to impact libfcoe's fcoe_fcf processing, so this patch creates fcoe_fcf_device instances for each discovered fcoe_fcf. The two are paired using a (void * priv) member of the fcoe_ctlr_device. This allows libfcoe to continue maintaining its list of fcoe_fcf instances and simply attaches and detaches them from existing or new fcoe_fcf_device instances. Signed-off-by: Robert Love Tested-by: Ross Brattain Signed-off-by: James Bottomley

[SCSI] fcoe: Allocate fcoe_ctlr with fcoe_interface, not as a member

2012-05-23T08:36:27Z

Currently the fcoe_ctlr associated with an interface is allocated as a member of struct fcoe_interface. This causes problems when attempting to use the new fcoe_sysfs APIs which allow us to allocate the fcoe_interface as private data to the fcoe_ctlr_device instance. The problem is that libfcoe wants to be able use pointer math to find a fcoe_ctlr's fcoe_ctlr_device as well as finding a fcoe_ctlr_device's assocated fcoe_ctlr. To do this we need to allocate the fcoe_ctlr_device, with private data for the LLD. The private data contains the fcoe_ctlr and its private data is the fcoe_interface. This patch only allocates the fcoe_interface with the fcoe_ctlr, the fcoe_ctlr_device will be added in a later patch, which will complete the below diagram- +------------------+ | fcoe_ctlr_device | +------------------+ | fcoe_ctlr | +------------------+ | fcoe_interface | +------------------+ This prep work will allow us to go from a fcoe_ctlr_device instance to its fcoe_ctlr as well as from a fcoe_ctlr to its fcoe_ctlr_device once the fcoe_sysfs API is in use (later patches in this series). Signed-off-by: Robert Love Tested-by: Ross Brattain Signed-off-by: James Bottomley

[SCSI] fcoe: remove a stray unlock

2012-05-10T07:59:26Z

We moved the locking in dd060e74fb "[SCSI] fcoe: remove frame dropping code from fcoe_percpu_clean" but this unlock was missed. Signed-off-by: Dan Carpenter Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] fcoe: Don't hold rtnl_mutex in fcoe_update_src_mac

2012-05-10T07:59:25Z

The rtnl_mutex was held to protect calls to dev_uc_add and dev_uc_del. Holding rtnl is not required as those functions make use of the netif_addr_lock* API to protect the MAC changing. This change fixes the following regression by removing the rtnl usage when fcoe_update_src_mac is called. https://bugzilla.kernel.org/show_bug.cgi?id=42918 the existing dependency chain (in reverse order) is: -> #1 (&fip->ctlr_mutex){+.+...}: [] lock_acquire+0x80/0x1b0 [] mutex_lock_nested+0x6d/0x340 [] fcoe_ctlr_link_up+0x22/0x180 [libfcoe] [] fcoe_create+0x47e/0x6e0 [fcoe] [] fcoe_transport_create+0x143/0x250 [libfcoe] [] param_attr_store+0x30/0x60 [] module_attr_store+0x26/0x40 [] sysfs_write_file+0xae/0x100 [] vfs_write+0x8f/0x160 [] sys_write+0x3d/0x70 [] syscall_call+0x7/0xb -> #0 (rtnl_mutex){+.+.+.}: [] __lock_acquire+0x140b/0x1720 [] lock_acquire+0x80/0x1b0 [] mutex_lock_nested+0x6d/0x340 [] rtnl_lock+0x14/0x20 [] fcoe_update_src_mac+0x2c/0xb0 [fcoe] [] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe] [] process_one_work+0x179/0x5d0 [] worker_thread+0x121/0x2d0 [] kthread+0x7d/0x90 [] kernel_thread_helper+0x6/0x10 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&fip->ctlr_mutex); lock(rtnl_mutex); lock(&fip->ctlr_mutex); lock(rtnl_mutex); *** DEADLOCK *** Signed-off-by: Robert Love Tested-by: Bart Van Assche Signed-off-by: James Bottomley

[SCSI] libfc: defer releasing master lport until complete fcoe interface cleanuped up

2012-05-10T07:59:25Z

The fcoe controller has back references, therefore defer releasing master lport which gets freed along scsi_host_put and then free it once fcoe interface is fully cleaned. Signed-off-by: Vasu Dev Acked-by: Neil Horman Tested-by: Ross Brattain Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] fcoe: remove lport from net device before doing per cpu rx thread cleanup

2012-05-10T07:59:24Z

Remove lport from net device and then do synchronize net device to flush inflight rx frames for the lport before doing fcoe_percpu_clean. In case of master lport, remove all rx packet handlers completely and then only do fcoe_percpu_clean. This required splitting fcoe_interface_cleanup to do remove part separately and for that added func fcoe_interface_remove and then call it from fcoe_if_destory before doing fcoe_percpu_clean. However if fcoe_interface_remove() is already called then don't call again from fcoe_interface_cleanup() to preserve its existing flows. This patch along with Neil's other patch to avoid soft irq context on ingress will avoid passing up frames on disabled lport as discussed in this mail thread:- http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.html Signed-off-by: Vasu Dev Acked-by: Neil Horman Tested-by: Ross Brattain Signed-off-by: Robert Love Signed-off-by: James Bottomley

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6

2012-03-31T20:31:23Z

Pull SCSI updates from James Bottomley: "This is primarily another round of driver updates (lpfc, bfa, fcoe, ipr) plus a new ufshcd driver. There shouldn't be anything controversial in here (The final deletion of scsi proc_ops which caused some build breakage has been held over until the next merge window to give us more time to stabilise it). I'm afraid, with me moving continents at exactly the wrong time, anything submitted after the merge window opened has been held over to the next merge window." * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (63 commits) [SCSI] ipr: Driver version 2.5.3 [SCSI] ipr: Increase alignment boundary of command blocks [SCSI] ipr: Increase max concurrent oustanding commands [SCSI] ipr: Remove unnecessary memory barriers [SCSI] ipr: Remove unnecessary interrupt clearing on new adapters [SCSI] ipr: Fix target id allocation re-use problem [SCSI] atp870u, mpt2sas, qla4xxx use pci_dev->revision [SCSI] fcoe: Drop the rtnl_mutex before calling fcoe_ctlr_link_up [SCSI] bfa: Update the driver version to 3.0.23.0 [SCSI] bfa: BSG and User interface fixes. [SCSI] bfa: Fix to avoid vport delete hang on request queue full scenario. [SCSI] bfa: Move service parameter programming logic into firmware. [SCSI] bfa: Revised Fabric Assigned Address(FAA) feature implementation. [SCSI] bfa: Flash controller IOC pll init fixes. [SCSI] bfa: Serialize the IOC hw semaphore unlock logic. [SCSI] bfa: Modify ISR to process pending completions [SCSI] bfa: Add fc host issue lip support [SCSI] mpt2sas: remove extraneous sas_log_info messages [SCSI] libfc: fcoe_transport_create fails in single-CPU environment [SCSI] fcoe: reduce contention for fcoe_rx_list lock [v2] ...