summaryrefslogtreecommitdiffstats
path: root/drivers/scsi/fcoe/fcoe.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-nextLinus Torvalds2014-12-111-4/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull networking updates from David Miller: 1) New offloading infrastructure and example 'rocker' driver for offloading of switching and routing to hardware. This work was done by a large group of dedicated individuals, not limited to: Scott Feldman, Jiri Pirko, Thomas Graf, John Fastabend, Jamal Hadi Salim, Andy Gospodarek, Florian Fainelli, Roopa Prabhu 2) Start making the networking operate on IOV iterators instead of modifying iov objects in-situ during transfers. Thanks to Al Viro and Herbert Xu. 3) A set of new netlink interfaces for the TIPC stack, from Richard Alpe. 4) Remove unnecessary looping during ipv6 routing lookups, from Martin KaFai Lau. 5) Add PAUSE frame generation support to gianfar driver, from Matei Pavaluca. 6) Allow for larger reordering levels in TCP, which are easily achievable in the real world right now, from Eric Dumazet. 7) Add a variable of napi_schedule that doesn't need to disable cpu interrupts, from Eric Dumazet. 8) Use a doubly linked list to optimize neigh_parms_release(), from Nicolas Dichtel. 9) Various enhancements to the kernel BPF verifier, and allow eBPF programs to actually be attached to sockets. From Alexei Starovoitov. 10) Support TSO/LSO in sunvnet driver, from David L Stevens. 11) Allow controlling ECN usage via routing metrics, from Florian Westphal. 12) Remote checksum offload, from Tom Herbert. 13) Add split-header receive, BQL, and xmit_more support to amd-xgbe driver, from Thomas Lendacky. 14) Add MPLS support to openvswitch, from Simon Horman. 15) Support wildcard tunnel endpoints in ipv6 tunnels, from Steffen Klassert. 16) Do gro flushes on a per-device basis using a timer, from Eric Dumazet. This tries to resolve the conflicting goals between the desired handling of bulk vs. RPC-like traffic. 17) Allow userspace to ask for the CPU upon what a packet was received/steered, via SO_INCOMING_CPU. From Eric Dumazet. 18) Limit GSO packets to half the current congestion window, from Eric Dumazet. 19) Add a generic helper so that all drivers set their RSS keys in a consistent way, from Eric Dumazet. 20) Add xmit_more support to enic driver, from Govindarajulu Varadarajan. 21) Add VLAN packet scheduler action, from Jiri Pirko. 22) Support configurable RSS hash functions via ethtool, from Eyal Perry. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1820 commits) Fix race condition between vxlan_sock_add and vxlan_sock_release net/macb: fix compilation warning for print_hex_dump() called with skb->mac_header net/mlx4: Add support for A0 steering net/mlx4: Refactor QUERY_PORT net/mlx4_core: Add explicit error message when rule doesn't meet configuration net/mlx4: Add A0 hybrid steering net/mlx4: Add mlx4_bitmap zone allocator net/mlx4: Add a check if there are too many reserved QPs net/mlx4: Change QP allocation scheme net/mlx4_core: Use tasklet for user-space CQ completion events net/mlx4_core: Mask out host side virtualization features for guests net/mlx4_en: Set csum level for encapsulated packets be2net: Export tunnel offloads only when a VxLAN tunnel is created gianfar: Fix dma check map error when DMA_API_DEBUG is enabled cxgb4/csiostor: Don't use MASTER_MUST for fw_hello call net: fec: only enable mdio interrupt before phy device link up net: fec: clear all interrupt events to support i.MX6SX net: fec: reset fep link status in suspend function net: sock: fix access via invalid file descriptor net: introduce helper macro for_each_cmsghdr ...
| * vlan: make __vlan_hwaccel_put_tag return voidJiri Pirko2014-11-211-4/+2
| | | | | | | | | | | | | | | | Always returns the same skb it gets, so change to void. Signed-off-by: Jiri Pirko <jiri@resnulli.us> Acked-by: Pravin B Shelar <pshelar@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | scsi: drop reason argument from ->change_queue_depthChristoph Hellwig2014-11-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | Drop the now unused reason argument from the ->change_queue_depth method. Also add a return value to scsi_adjust_queue_depth, and rename it to scsi_change_queue_depth now that it can be used as the default ->change_queue_depth implementation. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Hannes Reinecke <hare@suse.de>
* | scsi: avoid ->change_queue_depth indirection for queue full trackingChristoph Hellwig2014-11-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All drivers use the implementation for ramping the queue up and down, so instead of overloading the change_queue_depth method call the implementation diretly if the driver opts into it by setting the track_queue_depth flag in the host template. Note that a few drivers validated the new queue depth in their change_queue_depth method, but as we never go over the queue depth set during slave_configure or the sysfs file this isn't nessecary and can safely be removed. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Venkatesh Srinivas <venkateshs@google.com>
* | scsi: always assign block layer tags if enabledChristoph Hellwig2014-11-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Allow a driver to ask for block layer tags by setting .use_blk_tags in the host template, in which case it will always see a valid value in request->tag, similar to the behavior when using blk-mq. This means even SCSI "untagged" commands will now have a tag, which is especially useful when using a host-wide tag map. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
* | scsi: provide a generic change_queue_type methodChristoph Hellwig2014-11-121-1/+1
|/ | | | | | | | | | | Most drivers use exactly the same implementation, so provide it as a library function. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
* sched, cleanup, treewide: Remove set_current_state(TASK_RUNNING) after ↵Kirill Tkhai2014-09-191-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | schedule() schedule(), io_schedule() and schedule_timeout() always return with TASK_RUNNING state set, so one more setting is unnecessary. (All places in patch are visible good, only exception is kiblnd_scheduler() from: drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c Its schedule() is one line above standard 3 lines of unified diff) No places where set_current_state() is used for mb(). Signed-off-by: Kirill Tkhai <ktkhai@parallels.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/1410529254.3569.23.camel@tkhai Cc: Alasdair Kergon <agk@redhat.com> Cc: Anil Belur <askb23@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dave Kleikamp <shaggy@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: David Howells <dhowells@redhat.com> Cc: Dmitry Eremin <dmitry.eremin@intel.com> Cc: Frank Blaschka <blaschka@linux.vnet.ibm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Helge Deller <deller@gmx.de> Cc: Isaac Huang <he.huang@intel.com> Cc: James E.J. Bottomley <JBottomley@parallels.com> Cc: James E.J. Bottomley <jejb@parisc-linux.org> Cc: J. Bruce Fields <bfields@fieldses.org> Cc: Jeff Dike <jdike@addtoit.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Laura Abbott <lauraa@codeaurora.org> Cc: Liang Zhen <liang.zhen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Masaru Nomura <massa.nomura@gmail.com> Cc: Michael Opdenacker <michael.opdenacker@free-electrons.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Neil Brown <neilb@suse.de> Cc: Oleg Drokin <green@linuxhacker.ru> Cc: Peng Tao <bergwolf@gmail.com> Cc: Richard Weinberger <richard@nod.at> Cc: Robert Love <robert.w.love@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Cc: Ursula Braun <ursula.braun@de.ibm.com> Cc: Zi Shen Lim <zlim.lnx@gmail.com> Cc: devel@driverdev.osuosl.org Cc: dm-devel@redhat.com Cc: dri-devel@lists.freedesktop.org Cc: fcoe-devel@open-fcoe.org Cc: jfs-discussion@lists.sourceforge.net Cc: linux390@de.ibm.com Cc: linux-afs@lists.infradead.org Cc: linux-cris-kernel@axis.com Cc: linux-kernel@vger.kernel.org Cc: linux-nfs@vger.kernel.org Cc: linux-parisc@vger.kernel.org Cc: linux-raid@vger.kernel.org Cc: linux-s390@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: qla2xxx-upstream@qlogic.com Cc: user-mode-linux-devel@lists.sourceforge.net Cc: user-mode-linux-user@lists.sourceforge.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
* Merge branch 'sched/urgent' into sched/core, to avoid conflictsIngo Molnar2014-05-071-2/+13
|\ | | | | | | Signed-off-by: Ingo Molnar <mingo@kernel.org>
| * scsi, fcoe: Fix CPU hotplug callback registrationSrivatsa S. Bhat2014-03-201-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); register_cpu_notifier(&foobar_cpu_notifier); put_online_cpus(); This is wrong, since it is prone to ABBA deadlocks involving the cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently with CPU hotplug operations). Instead, the correct and race-free way of performing the callback registration is: cpu_notifier_register_begin(); for_each_online_cpu(cpu) init_cpu(cpu); /* Note the use of the double underscored version of the API */ __register_cpu_notifier(&foobar_cpu_notifier); cpu_notifier_register_done(); Fix the fcoe code in scsi by using this latter form of callback registration. Cc: Robert Love <robert.w.love@intel.com> Cc: "James E.J. Bottomley" <JBottomley@parallels.com> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | sched, treewide: Replace hardcoded nice values with MIN_NICE/MAX_NICEDongsheng Yang2014-04-181-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | Replace various -20/+19 hardcoded nice values with MIN_NICE/MAX_NICE. Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/ff13819fd09b7a5dba5ab5ae797f2e7019bdfa17.1394532288.git.yangds.fnst@cn.fujitsu.com Cc: devel@driverdev.osuosl.org Cc: devicetree@vger.kernel.org Cc: fcoe-devel@open-fcoe.org Cc: linux390@de.ibm.com Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-s390@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: nbd-general@lists.sourceforge.net Cc: ocfs2-devel@oss.oracle.com Cc: openipmi-developer@lists.sourceforge.net Cc: qla2xxx-upstream@qlogic.com Cc: linux-arch@vger.kernel.org [ Consolidated the patches, twiddled the changelog. ] Signed-off-by: Ingo Molnar <mingo@kernel.org>
* scsi: Convert uses of compare_ether_addr to ether_addr_equalJoe Perches2013-10-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preliminary to removing compare_ether_addr altogether: Use the new bool function ether_addr_equal to add some clarity and reduce the likelihood for misuse of compare_ether_addr for sorting. Done via cocci script: $ cat compare_ether_addr.cocci @@ expression a,b; @@ - !compare_ether_addr(a, b) + ether_addr_equal(a, b) @@ expression a,b; @@ - compare_ether_addr(a, b) + !ether_addr_equal(a, b) @@ expression a,b; @@ - !ether_addr_equal(a, b) == 0 + ether_addr_equal(a, b) @@ expression a,b; @@ - !ether_addr_equal(a, b) != 0 + !ether_addr_equal(a, b) @@ expression a,b; @@ - ether_addr_equal(a, b) == 0 + !ether_addr_equal(a, b) @@ expression a,b; @@ - ether_addr_equal(a, b) != 0 + ether_addr_equal(a, b) @@ expression a,b; @@ - !!ether_addr_equal(a, b) + ether_addr_equal(a, b) Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* libfcoe: Make fcoe_sysfs optional / fix fnic NULL exceptionRobert Love2013-10-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fnic doesn't use any of the create/destroy/enable/disable interfaces either from the (legacy) module paramaters or the (new) fcoe_sysfs interfaces. When fcoe_sysfs was introduced fnic wasn't changed since it wasn't using the interfaces. libfcoe incorrectly assumed that that all of its users were using fcoe_sysfs and when adding and deleting FCFs would assume the existance of a fcoe_ctlr_device. fnic was not allocating this structure because it doesn't care about the standard user interfaces (fnic starts on link only). If/When libfcoe tried to use the fcoe_ctlr_device's lock for the first time a NULL pointer exception would be triggered. Since fnic doesn't care about sysfs or user interfaces, the solution is to drop libfcoe's assumption that all drivers are using fcoe_sysfs. This patch accomplishes this by changing some of the structure relationships. We need a way to determine when a LLD is using fcoe_sysfs or not and we can do that by checking for the existance of the fcoe_ctlr_device. Prior to this patch, it was assumed that the fcoe_ctlr structure was allocated with the fcoe_ctlr_device and immediately followed it in memory. To reach the fcoe_ctlr_device we would simply go back in memory from the fcoe_ctlr to get the fcoe_ctlr_device. Since fnic doesn't allocate the fcoe_ctlr_device, we cannot keep that assumption. This patch adds a pointer from the fcoe_ctlr to the fcoe_ctlr_device. For bnx2fc and fcoe we will continue to allocate the two structures together, but then we'll set the ctlr->cdev pointer to point at the fcoe_ctlr_device. fnic will not change and will continue to allocate the fcoe_ctlr itself, and ctlr->cdev will remain NULL. When libfcoe adds fcoe_fcf's to the fcoe_ctlr it will check if ctlr->cdev is set and only if so will it continue to interact with fcoe_sysfs. Signed-off-by: Robert Love <robert.w.love@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Tested-by: Hiral Patel <hiralpat@cisco.com>
* fcoe: Add missing newlines in debug messagesBart Van Assche2013-09-041-6/+6
| | | | | | | | FCoE debug statements must end in a newline. Add one where it is missing. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Cc: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* fcoe: cleanup return codes from fcoe_rcvNeil Horman2013-09-041-2/+2
| | | | | | | the return codes from fcoe_rcv should be NET_RX_*, not 0 or -1. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* fcoe: make sure fcoe frames are unshared prior to manipulating themNeil Horman2013-09-041-0/+6
| | | | | | | | | | | Based on my last patch I noticed that fcoe_rcv has a simmilar problem, in that it manipulates the passed in skb without checking to see if it has other users. Making manipulations to a shared skb can result in various corruptions. Easy fix, just make sure the skb is unshared prior to doing anything with it. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* Merge tag 'scsi-for-linus' of ↵Linus Torvalds2013-07-131-11/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull final round of SCSI updates from James Bottomley: "This is the remaining set of SCSI patches for the merge window. It's mostly driver updates (scsi_debug, qla2xxx, storvsc, mp3sas). There are also several bug fixes in fcoe, libfc, and megaraid_sas. We also have a couple of core changes to try to make device destruction more deterministic" * tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (46 commits) [SCSI] scsi constants: command, sense key + additional sense strings fcoe: Reduce number of sparse warnings fcoe: Stop fc_rport_priv structure leak libfcoe: Fix meaningless log statement libfc: Differentiate echange timer cancellation debug statements libfc: Remove extra space in fc_exch_timer_cancel definition fcoe: fix the link error status block sparse warnings fcoe: Fix smatch warning in fcoe_fdmi_info function libfc: Reject PLOGI from nodes with incompatible role [SCSI] enable destruction of blocked devices which fail LUN scanning [SCSI] Fix race between starved list and device removal [SCSI] megaraid_sas: fix a bug for 64 bit arches [SCSI] scsi_debug: reduce duplication between prot_verify_read and prot_verify_write [SCSI] scsi_debug: simplify offset calculation for dif_storep [SCSI] scsi_debug: invalidate protection info for unmapped region [SCSI] scsi_debug: fix NULL pointer dereference with parameters dif=0 dix=1 [SCSI] scsi_debug: fix incorrectly nested kmap_atomic() [SCSI] scsi_debug: fix invalid address passed to kunmap_atomic() [SCSI] mpt3sas: Bump driver version to v02.100.00.00 [SCSI] mpt3sas: when async scanning is enabled then while scanning, devices are removed but their transport layer entries are not removed ...
| * fcoe: Fix smatch warning in fcoe_fdmi_info functionNeerav Parikh2013-07-091-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a smatch warning as below: smatch warnings: drivers/scsi/fcoe/fcoe.c:782 fcoe_fdmi_info() warn: 'fdmi' puts 896 bytes on stack Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Neerav Parikh <Neerav.Parikh@intel.com> Tested-by: Jack Morgan <jack.morgan@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2013-07-031-2/+5
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/net/ethernet/freescale/fec_main.c drivers/net/ethernet/renesas/sh_eth.c net/ipv4/gre.c The GRE conflict is between a bug fix (kfree_skb --> kfree_skb_list) and the splitting of the gre.c code into seperate files. The FEC conflict was two sets of changes adding ethtool support code in an "!CONFIG_M5272" CPP protected block. Finally the sh_eth.c conflict was between one commit add bits set in the .eesr_err_check mask whilst another commit removed the .tx_error_check member and assignments. Signed-off-by: David S. Miller <davem@davemloft.net>
| * fcoe: Use correct API to set vlan tag for FCoE Ethertype skbsRobert Love2013-06-251-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fcoe_xmit was coded such that it would skip the vlan net device/layer and instead set some vlan flags and transmit on the real net device. The real net device has code that would add the vlan tag for fcoe skbs. This avoids some extra processing for data frames and provides a small performance improvement. Since fcoe_xmit was not using the vlan net device, __vlan_put_tag within the real net device's xmit routine was ultimately being called to set the vlan tag. With the below change the behavior of __vlan_put_tag changed slightly, it now sets the skb->protocol = vlan_proto. vlan_proto was not a field being set by fcoe_xmit, so the skb->protocol is now not being set to ETH_P_8021Q, as it should be. This patch converts fcoe_xmit to use the vlan_put_tag routine which will tag the skb and fcoe will continue to transmit fcoe skbs on the real net device. For reference, the below change was the one that altered the __vlan_put_tag behavior. commit 86a9bad3ab6b6f858fd4443b48738cabbb6d094c Author: Patrick McHardy <kaber@trash.net> Date: Fri Apr 19 02:04:30 2013 +0000 net: vlan: add protocol argument to packet tagging functions Add a protocol argument to the VLAN packet tagging functions. In case of HW tagging, we need that protocol available in the ndo_start_xmit functions, so it is stored in a new field in the skb. The new field fits into a hole (on 64 bit) and doesn't increase the sks's size. Signed-off-by: Robert Love <robert.w.love@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: John Fastabend <john.r.fastabend@intel.com>
* | net: pass info struct via netdevice notifierJiri Pirko2013-05-281-1/+1
|/ | | | | | | | | | | | | | So far, only net_device * could be passed along with netdevice notifier event. This patch provides a possibility to pass custom structure able to provide info that event listener needs to know. Signed-off-by: Jiri Pirko <jiri@resnulli.us> v2->v3: fix typo on simeth shortened dev_getter shortened notifier_info struct name v1->v2: fix notifier_call parameter in call_netdevice_notifier() Signed-off-by: David S. Miller <davem@davemloft.net>
* net: vlan: rename NETIF_F_HW_VLAN_* feature flags to NETIF_F_HW_VLAN_CTAG_*Patrick McHardy2013-04-191-1/+1
| | | | | | | | | | Rename the hardware VLAN acceleration features to include "CTAG" to indicate that they only support CTAGs. Follow up patches will introduce 802.1ad server provider tagging (STAGs) and require the distinction for hardware not supporting acclerating both. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* fcoe: Fix deadlock between create and destroy pathsRobert Love2013-03-251-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can deadlock (s_active and fcoe_config_mutex) if a port is being destroyed at the same time one is being created. [ 4200.503113] ====================================================== [ 4200.503114] [ INFO: possible circular locking dependency detected ] [ 4200.503116] 3.8.0-rc5+ #8 Not tainted [ 4200.503117] ------------------------------------------------------- [ 4200.503118] kworker/3:2/2492 is trying to acquire lock: [ 4200.503119] (s_active#292){++++.+}, at: [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70 [ 4200.503127] but task is already holding lock: [ 4200.503128] (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02f3338>] fcoe_destroy_work+0xe8/0x120 [fcoe] [ 4200.503133] which lock already depends on the new lock. [ 4200.503135] the existing dependency chain (in reverse order) is: [ 4200.503136] -> #1 (fcoe_config_mutex){+.+.+.}: [ 4200.503139] [<ffffffff810c7711>] lock_acquire+0xa1/0x140 [ 4200.503143] [<ffffffff816ca7be>] mutex_lock_nested+0x6e/0x360 [ 4200.503146] [<ffffffffa02f11bd>] fcoe_enable+0x1d/0xb0 [fcoe] [ 4200.503148] [<ffffffffa02f127d>] fcoe_ctlr_enabled+0x2d/0x50 [fcoe] [ 4200.503151] [<ffffffffa02ffbe8>] store_ctlr_enabled+0x38/0x90 [libfcoe] [ 4200.503154] [<ffffffff81424878>] dev_attr_store+0x18/0x30 [ 4200.503157] [<ffffffff8122b750>] sysfs_write_file+0xe0/0x150 [ 4200.503160] [<ffffffff811b334c>] vfs_write+0xac/0x180 [ 4200.503162] [<ffffffff811b3692>] sys_write+0x52/0xa0 [ 4200.503164] [<ffffffff816d7159>] system_call_fastpath+0x16/0x1b [ 4200.503167] -> #0 (s_active#292){++++.+}: [ 4200.503170] [<ffffffff810c680f>] __lock_acquire+0x135f/0x1c90 [ 4200.503172] [<ffffffff810c7711>] lock_acquire+0xa1/0x140 [ 4200.503174] [<ffffffff8122c626>] sysfs_deactivate+0x116/0x160 [ 4200.503176] [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70 [ 4200.503178] [<ffffffff8122b2eb>] sysfs_hash_and_remove+0x5b/0xb0 [ 4200.503180] [<ffffffff8122f3d1>] sysfs_remove_group+0x61/0x100 [ 4200.503183] [<ffffffff814251eb>] device_remove_groups+0x3b/0x60 [ 4200.503185] [<ffffffff81425534>] device_remove_attrs+0x44/0x80 [ 4200.503187] [<ffffffff81425e97>] device_del+0x127/0x1c0 [ 4200.503189] [<ffffffff81425f52>] device_unregister+0x22/0x60 [ 4200.503191] [<ffffffffa0300970>] fcoe_ctlr_device_delete+0xe0/0xf0 [libfcoe] [ 4200.503194] [<ffffffffa02f1b5c>] fcoe_interface_cleanup+0x6c/0xa0 [fcoe] [ 4200.503196] [<ffffffffa02f3355>] fcoe_destroy_work+0x105/0x120 [fcoe] [ 4200.503198] [<ffffffff8107ee91>] process_one_work+0x1a1/0x580 [ 4200.503203] [<ffffffff81080c6e>] worker_thread+0x15e/0x440 [ 4200.503205] [<ffffffff8108715a>] kthread+0xea/0xf0 [ 4200.503207] [<ffffffff816d70ac>] ret_from_fork+0x7c/0xb0 [ 4200.503209] other info that might help us debug this: [ 4200.503211] Possible unsafe locking scenario: [ 4200.503212] CPU0 CPU1 [ 4200.503213] ---- ---- [ 4200.503214] lock(fcoe_config_mutex); [ 4200.503215] lock(s_active#292); [ 4200.503218] lock(fcoe_config_mutex); [ 4200.503219] lock(s_active#292); [ 4200.503221] *** DEADLOCK *** [ 4200.503223] 3 locks held by kworker/3:2/2492: [ 4200.503224] #0: (fcoe){.+.+.+}, at: [<ffffffff8107ee2b>] process_one_work+0x13b/0x580 [ 4200.503228] #1: ((&port->destroy_work)){+.+.+.}, at: [<ffffffff8107ee2b>] process_one_work+0x13b/0x580 [ 4200.503232] #2: (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02f3338>] fcoe_destroy_work+0xe8/0x120 [fcoe] [ 4200.503236] stack backtrace: [ 4200.503238] Pid: 2492, comm: kworker/3:2 Not tainted 3.8.0-rc5+ #8 [ 4200.503240] Call Trace: [ 4200.503243] [<ffffffff816c2f09>] print_circular_bug+0x1fb/0x20c [ 4200.503246] [<ffffffff810c680f>] __lock_acquire+0x135f/0x1c90 [ 4200.503248] [<ffffffff810c463a>] ? debug_check_no_locks_freed+0x9a/0x180 [ 4200.503250] [<ffffffff810c7711>] lock_acquire+0xa1/0x140 [ 4200.503253] [<ffffffff8122d20b>] ? sysfs_addrm_finish+0x3b/0x70 [ 4200.503255] [<ffffffff8122c626>] sysfs_deactivate+0x116/0x160 [ 4200.503258] [<ffffffff8122d20b>] ? sysfs_addrm_finish+0x3b/0x70 [ 4200.503260] [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70 [ 4200.503262] [<ffffffff8122b2eb>] sysfs_hash_and_remove+0x5b/0xb0 [ 4200.503265] [<ffffffff8122f3d1>] sysfs_remove_group+0x61/0x100 [ 4200.503273] [<ffffffff814251eb>] device_remove_groups+0x3b/0x60 [ 4200.503275] [<ffffffff81425534>] device_remove_attrs+0x44/0x80 [ 4200.503277] [<ffffffff81425e97>] device_del+0x127/0x1c0 [ 4200.503279] [<ffffffff81425f52>] device_unregister+0x22/0x60 [ 4200.503282] [<ffffffffa0300970>] fcoe_ctlr_device_delete+0xe0/0xf0 [libfcoe] [ 4200.503285] [<ffffffffa02f1b5c>] fcoe_interface_cleanup+0x6c/0xa0 [fcoe] [ 4200.503287] [<ffffffffa02f3355>] fcoe_destroy_work+0x105/0x120 [fcoe] [ 4200.503290] [<ffffffff8107ee91>] process_one_work+0x1a1/0x580 [ 4200.503292] [<ffffffff8107ee2b>] ? process_one_work+0x13b/0x580 [ 4200.503295] [<ffffffffa02f3250>] ? fcoe_if_destroy+0x230/0x230 [fcoe] [ 4200.503297] [<ffffffff81080c6e>] worker_thread+0x15e/0x440 [ 4200.503299] [<ffffffff81080b10>] ? busy_worker_rebind_fn+0x100/0x100 [ 4200.503301] [<ffffffff8108715a>] kthread+0xea/0xf0 [ 4200.503304] [<ffffffff81087070>] ? kthread_create_on_node+0x160/0x160 [ 4200.503306] [<ffffffff816d70ac>] ret_from_fork+0x7c/0xb0 [ 4200.503308] [<ffffffff81087070>] ? kthread_create_on_node+0x160/0x160 Signed-off-by: Robert Love <robert.w.love@intel.com> Tested-by: Jack Morgan <jack.morgan@intel.com>
* fcoe: Fix deadlock while deleting FCoE interface with NPIV portsNeerav Parikh2013-01-281-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes following deadlock caused by destroying of an FCoE interface with active NPIV ports on that interface. Call Trace: [<ffffffff814b7e88>] schedule+0x64/0x66 [<ffffffff814b6b4f>] schedule_timeout+0x36/0xe3 [<ffffffff81070c55>] ? update_curr+0xd6/0x110 [<ffffffff81071f6b>] ? hrtick_update+0x1b/0x4d [<ffffffff81072405>] ? dequeue_task_fair+0x1ca/0x1d9 [<ffffffff8106a369>] ? need_resched+0x1e/0x28 [<ffffffff814b7d14>] wait_for_common+0x9b/0xf1 [<ffffffff8106e7be>] ? try_to_wake_up+0x1e0/0x1e0 [<ffffffff814b7e22>] wait_for_completion+0x1d/0x1f [<ffffffff8105ae82>] flush_workqueue+0x116/0x2a1 [<ffffffff8105b357>] drain_workqueue+0x66/0x14c [<ffffffff8105b8ef>] destroy_workqueue+0x1a/0xcf [<ffffffffa009211e>] fc_remove_host+0x154/0x17f [scsi_transport_fc] [<ffffffffa00edbb8>] fcoe_if_destroy+0x184/0x1c9 [fcoe] [<ffffffffa00edc28>] fcoe_destroy_work+0x2b/0x44 [fcoe] [<ffffffff8105a82a>] process_one_work+0x1a8/0x2a4 [<ffffffffa00edbfd>] ? fcoe_if_destroy+0x1c9/0x1c9 [fcoe] [<ffffffff8105c396>] worker_thread+0x1db/0x268 [<ffffffff810604a3>] ? wake_up_bit+0x2a/0x2a [<ffffffff8105c1bb>] ? manage_workers.clone.16+0x1f6/0x1f6 [<ffffffff8105ffd6>] kthread+0x6f/0x77 [<ffffffff814c0304>] kernel_thread_helper+0x4/0x10 [<ffffffff8105ff67>] ? kthread_freezable_should_stop+0x4b/0x4b Call Trace: [<ffffffff814b7e88>] schedule+0x64/0x66 [<ffffffff814b8041>] schedule_preempt_disabled+0xe/0x10 [<ffffffff814b70a1>] __mutex_lock_common.clone.5+0x117/0x17a [<ffffffff814b7117>] __mutex_lock_slowpath+0x13/0x15 [<ffffffff814b6f76>] mutex_lock+0x23/0x37 [<ffffffff8125b890>] ? list_del+0x11/0x30 [<ffffffffa00edc84>] fcoe_vport_destroy+0x43/0x5f [fcoe] [<ffffffffa009130a>] fc_vport_terminate+0x48/0x110 [scsi_transport_fc] [<ffffffffa00913ef>] fc_vport_sched_delete+0x1d/0x79 [scsi_transport_fc] [<ffffffff8105a82a>] process_one_work+0x1a8/0x2a4 [<ffffffffa00913d2>] ? fc_vport_terminate+0x110/0x110 [scsi_transport_fc] [<ffffffff8105c396>] worker_thread+0x1db/0x268 [<ffffffff8105c1bb>] ? manage_workers.clone.16+0x1f6/0x1f6 [<ffffffff8105ffd6>] kthread+0x6f/0x77 [<ffffffff814c0304>] kernel_thread_helper+0x4/0x10 [<ffffffff8105ff67>] ? kthread_freezable_should_stop+0x4b/0x4b [<ffffffff814c0300>] ? gs_change+0x13/0x13 A prior attempt to fix this issue is posted here: http://lists.open-fcoe.org/pipermail/devel/2012-October/012318.html or http://article.gmane.org/gmane.linux.scsi.open-fcoe.devel/11924 Based on feedback and discussion with Neil Horman it seems that the above patch may have a case where the fcoe_vport_destroy() and fcoe_destroy_work() can race; hence that patch has been withdrawn with this patch that is trying to solve the same problem in a different way. In the current approach instead of removing the fcoe_config_mutex from the vport_delete callback function; I've chosen to delete all the NPIV ports first on a given root lport before continuing with the removal of the root lport. Signed-off-by: Neerav Parikh <Neerav.Parikh@intel.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* fcoe: close race on link speed detection in fcoe codeNeil Horman2013-01-281-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When creating an fcoe interfce, we call fcoe_link_speed_update before we add the lports fcoe interface to the fc_hostlist. Since network device events like NETDEV_CHANGE are only processed if an fcoe interface is found with an underlying netdev that matches the netdev of the event. Since this processing in fcoe_device_notification is how link_speed changes get communicated to the libfc code (via fcoe_link_speed_update), we have a race condition - if a NETDEV_CHANGE event is sent after the call to fcoe_link_speed_update in fcoe_netdev_config, but before we add the interface to the fc_hostlist, we will loose the event and attributes like /sys/class/fc_host/hostX/speed will not get updated properly. Fix this by moving the add to the fc_hostlist above the serialized call to fcoe_netdev_config, ensuring that we catch netdev envents before we make a direct call to fcoe_link_speed_update. Also use this opportunity to clean up access to the fc_hostlist a bit by creating a fcoe_hostlist_del accessor and replacing the cleanup in fcoe_exit to use it properly. Tested by myself successfully [ Comment over 80 chars broken into multi-line by Robert Love to satisfy checkpatch.pl ] Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* libfcoe, fcoe: consolidate the fcoe_ctlr_get_lesb/fcoe_get_lesbYi Zou2012-12-141-40/+0
| | | | | | | | | | Similarly they can be moved into libfcoe instead of being private to fcoe now. Also add comments particularly on the term LESB to the corresponding function. Signed-off-by: Yi Zou <yi.zou@intel.com> Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* libfcoe, fcoe: move fcoe_link_speed_update() to libfcoe and export itYi Zou2012-12-141-35/+0
| | | | | | | | | | With the previous patch, fcoe_link_speed_update() can be moved into libfcoe and exported to used by fcoe, bnx2fc, and etc. Signed-off-by: Yi Zou <yi.zou@intel.com> Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* fcoe: add support to the get_netdev() for fcoe_interfaceYi Zou2012-12-141-0/+1
| | | | | | | | | Adds support to fcoe_port's newly added get_netdev fucntion pointer. Signed-off-by: Yi Zou <yi.zou@intel.com> Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
* fcoe: Use the fcoe_sysfs control interfaceRobert Love2012-12-141-15/+132
| | | | | | | | | | | | | | | | | | This patch adds support for the new fcoe_sysfs control interface to fcoe.ko. It keeps the deprecated interface in tact and therefore either the legacy or the new control interfaces can be used. A mixed mode is not supported. A user must either use the new interfaces or the old ones, but not both. The fcoe_ctlr's link state is now driven by both the netdev link state as well as the fcoe_ctlr_device's enabled attribute. The link must be up and the fcoe_ctlr_device must be enabled before the FCoE Controller starts discovery or login. Signed-off-by: Robert Love <robert.w.love@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com>
* libfcoe, fcoe, bnx2fc: Add new fcoe control interfaceRobert Love2012-12-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.love@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com>
* [SCSI] fcoe: Fix write errors on NPIV portsNeerav Parikh2012-10-071-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <Neerav.Parikh@intel.com> Acked-by: Yi Zou <yi.zou@intel.com> Acked-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] fcoe: Cleanup locking on fcoe_percpu_receive_threadNeil Horman2012-07-201-8/+10
| | | | | | | | | | | | | | | | | | | 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 <nhorman@tuxdriver.com> Acked-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] libfc, fcoe, bnx2fc: cleanup fcoe_dev_statsVasu Dev2012-07-201-9/+9
| | | | | | | | | | | | | | | 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 <vasu.dev@intel.com> Acked-by : Robert Love <robert.w.love@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Acked-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] fcoe, bnx2fc, libfcoe: SW FCoE and bnx2fc use FCoE SyfsRobert Love2012-05-231-7/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <robert.w.love@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] fcoe: Allocate fcoe_ctlr with fcoe_interface, not as a memberRobert Love2012-05-231-49/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <robert.w.love@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] fcoe: remove a stray unlockDan Carpenter2012-05-101-3/+2
| | | | | | | | | 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 <dan.carpenter@oracle.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] fcoe: Don't hold rtnl_mutex in fcoe_update_src_macRobert Love2012-05-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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){+.+...}: [<c1091f70>] lock_acquire+0x80/0x1b0 [<c147655d>] mutex_lock_nested+0x6d/0x340 [<f8970c32>] fcoe_ctlr_link_up+0x22/0x180 [libfcoe] [<f894620e>] fcoe_create+0x47e/0x6e0 [fcoe] [<f8973dd3>] fcoe_transport_create+0x143/0x250 [libfcoe] [<c10527e0>] param_attr_store+0x30/0x60 [<c1052696>] module_attr_store+0x26/0x40 [<c11a201e>] sysfs_write_file+0xae/0x100 [<c11449df>] vfs_write+0x8f/0x160 [<c1144cbd>] sys_write+0x3d/0x70 [<c147a0c4>] syscall_call+0x7/0xb -> #0 (rtnl_mutex){+.+.+.}: [<c109164b>] __lock_acquire+0x140b/0x1720 [<c1091f70>] lock_acquire+0x80/0x1b0 [<c147655d>] mutex_lock_nested+0x6d/0x340 [<c13a10c4>] rtnl_lock+0x14/0x20 [<f89445ac>] fcoe_update_src_mac+0x2c/0xb0 [fcoe] [<f8971712>] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe] [<c104fb69>] process_one_work+0x179/0x5d0 [<c10502f1>] worker_thread+0x121/0x2d0 [<c10550ed>] kthread+0x7d/0x90 [<c1481a82>] 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 <robert.w.love@intel.com> Tested-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] libfc: defer releasing master lport until complete fcoe interface ↵Vasu Dev2012-05-101-2/+7
| | | | | | | | | | | | | | cleanuped up 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 <vasu.dev@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] fcoe: remove lport from net device before doing per cpu rx thread cleanupVasu Dev2012-05-101-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | 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 <vasu.dev@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* Merge tag 'scsi-misc' of ↵Linus Torvalds2012-03-311-48/+35
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6 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] ...
| * [SCSI] fcoe: Drop the rtnl_mutex before calling fcoe_ctlr_link_upRobert Love2012-03-281-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rtnl_lock is primarily used to serialize networking driver changes as well as to ensure that a networking driver is not removed when making changes to it. fcoe also uses the rtnl_lock to protect the fcoe hostlist. fcoe_create holds the rtnl_lock over the entirity of the routine including a the call to fcoe_ctlr_link_up. This causes the below deadlock because fcoe_ctlr_link_up acquires the fcoe_ctlr ctlr_mutex and this deadlocks with a libfcoe thread that acquires the fcoe_ctlr ctlr_mutex and then the rtnl_lock (to update a MAC address). This patch drops the rtnl_lock before calling fcoe_ctlr_link_up and therefore the deadlock is prevented. https://bugzilla.kernel.org/show_bug.cgi?id=42918 the existing dependency chain (in reverse order) is: -> #1 (&fip->ctlr_mutex){+.+...}: [<c1091f70>] lock_acquire+0x80/0x1b0 [<c147655d>] mutex_lock_nested+0x6d/0x340 [<f8970c32>] fcoe_ctlr_link_up+0x22/0x180 [libfcoe] [<f894620e>] fcoe_create+0x47e/0x6e0 [fcoe] [<f8973dd3>] fcoe_transport_create+0x143/0x250 [libfcoe] [<c10527e0>] param_attr_store+0x30/0x60 [<c1052696>] module_attr_store+0x26/0x40 [<c11a201e>] sysfs_write_file+0xae/0x100 [<c11449df>] vfs_write+0x8f/0x160 [<c1144cbd>] sys_write+0x3d/0x70 [<c147a0c4>] syscall_call+0x7/0xb -> #0 (rtnl_mutex){+.+.+.}: [<c109164b>] __lock_acquire+0x140b/0x1720 [<c1091f70>] lock_acquire+0x80/0x1b0 [<c147655d>] mutex_lock_nested+0x6d/0x340 [<c13a10c4>] rtnl_lock+0x14/0x20 [<f89445ac>] fcoe_update_src_mac+0x2c/0xb0 [fcoe] [<f8971712>] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe] [<c104fb69>] process_one_work+0x179/0x5d0 [<c10502f1>] worker_thread+0x121/0x2d0 [<c10550ed>] kthread+0x7d/0x90 [<c1481a82>] 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 <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * [SCSI] fcoe: reduce contention for fcoe_rx_list lock [v2]Neil Horman2012-03-281-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is potentially lots of contention for the rx_list_lock. On a cpu that is receiving lots of fcoe traffic, the softirq context has to add and release the lock for every frame it receives, as does the receiving per-cpu thread. We can reduce this contention somewhat by altering the per-cpu threads loop such that when traffic is detected on the fcoe_rx_list, we splice it to a temporary list. In this way, we can process multiple skbs while only having to acquire and release the fcoe_rx_list lock once. [ Braces around single statement while loop removed by Robert Love to satisfy checkpath.pl. ] Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * [SCSI] fcoe: remove frame dropping code from fcoe_percpu_cleanNeil Horman2012-03-281-19/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | commit e7a51997dad4e17395be1209970e18d2e9305b24 ([SCSI] fcoe: flush per-cpu thread work when destroying interface) added a skb flush to the fcoe_rx_list, which ensures that we push any pending frames on the list through the per-cpu receive thread. Because of this, its redundant to lock and scan the list first, dropping any arriving frames. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * [SCSI] foce: remove bh disable from fcoe sw transport rcv functionNeil Horman2012-03-281-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The fcoe sw recive packet function (fcoe_rcv) only ever executes in softirq context. Given that, and the fact that no use of the fcoe_rx_list is made in irq context, its not necessecary to disable bottom halves while actually receiving the frame. Convert spin_*_bh calls in that function to their lock-only equivalents Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * [SCSI] fcoe: Ensure fcoe_recv_frame is always called in process contextNeil Horman2012-03-281-17/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 859b7b649ab58ee5cbfb761491317d5b315c1b0f introduced the ability to call fcoe_recv_frame in softirq context. While this is beneficial to performance, its not safe to do, as it breaks the serialization of access to the lport structure (i.e. when an fcoe interface is being torn down, theres no way to serialize the teardown effort with the completion of receieve operations occuring in softirq context. As a result, lport (and other) data structures can be read and modified in parallel leading to corruption. Most notable is the vport list, which is protected by a mutex, that will cause a panic if a softirq receive while said mutex is locked. Additionaly, the ema_list, discussed here: http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.html Can be corrupted if a list traversal occurs in softirq context at the same time as a list delete in process context. And generally the lport state variables will not be stable, and may lead to unpredictable results. The most direct fix is to remove the bits from the above commit that allowed fcoe_recv_frame to be called in softirq context. We just force all frames to be handled by the per-cpu rx threads. This will allow the fcoe_if_destroy's use of fcoe_percpu_clean to function properly, ensuring that no frames are being received while the lport is being torn down. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* | Merge tag 'scsi-misc' of ↵Linus Torvalds2012-03-221-55/+112
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6 SCSI updates from James Bottomley: "The update includes the usual assortment of driver updates (lpfc, qla2xxx, qla4xxx, bfa, bnx2fc, bnx2i, isci, fcoe, hpsa) plus a huge amount of infrastructure work in the SAS library and transport class as well as an iSCSI update. There's also a new SCSI based virtio driver." * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (177 commits) [SCSI] qla4xxx: Update driver version to 5.02.00-k15 [SCSI] qla4xxx: trivial cleanup [SCSI] qla4xxx: Fix sparse warning [SCSI] qla4xxx: Add support for multiple session per host. [SCSI] qla4xxx: Export CHAP index as sysfs attribute [SCSI] scsi_transport: Export CHAP index as sysfs attribute [SCSI] qla4xxx: Add support to display CHAP list and delete CHAP entry [SCSI] iscsi_transport: Add support to display CHAP list and delete CHAP entry [SCSI] pm8001: fix endian issue with code optimization. [SCSI] pm8001: Fix possible racing condition. [SCSI] pm8001: Fix bogus interrupt state flag issue. [SCSI] ipr: update PCI ID definitions for new adapters [SCSI] qla2xxx: handle default case in qla2x00_request_firmware() [SCSI] isci: improvements in driver unloading routine [SCSI] isci: improve phy event warnings [SCSI] isci: debug, provide state-enum-to-string conversions [SCSI] scsi_transport_sas: 'enable' phys on reset [SCSI] libsas: don't recover end devices attached to disabled phys [SCSI] libsas: fixup target_port_protocols for expanders that don't report sata [SCSI] libsas: set attached device type and target protocols for local phys ...
| * [SCSI] fcoe: Remove reference counting on 'stuct fcoe_interface'Robert Love2012-02-191-43/+5
| | | | | | | | | | | | | | | | | | | | | | | | The reference counting was necessary on these instances because it was possible for NPIV ports to be destroyed after the N_Port. A previous patch ensures that all NPIV ports are destroyed before the N_Port making the need to track references on the interface unnecessary. Signed-off-by: Robert Love <robert.w.love@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * [SCSI] fcoe: Do not switch context in vport_delete callbackRobert Love2012-02-191-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently all port deletion is routed though the FCoE workqueue (fcoe_wq). When fc_remove_host is called on an N_Port (for example, from fcoe_destroy) the vports are queued into a FC Transport workqueue. fc_remove_host flushes that queue and each vport is passed to fcoe's fcoe_vport_destroy, which simply queues the associated fcoe_ports for later deletion. This queue cannot be flushed within the N_Ports destroy path because of circular locking issues. The result is that the NPIV ports are destroyed after the N_Port, which is reverse of how they are created. This quirk causes fcoe to keep references on the fcoe_interface shared by each of these ports (N_Port and NPIV). Changing the ordering such that NPIV ports are destroyed before the N_Port will allow us to remove reference counting on the fcoe_interface instances. This patch simply allows fcoe_vport_destory to destroy NPIV ports without deferring them to a workqueue context. This ensures that when fc_remove_host is called the NPIV ports will be destroyed first before the N_Port and allows reference counting on the fcoe's fcoe_interface to be remove in a later patch. Signed-off-by: Robert Love <robert.w.love@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * [SCSI] fcoe: Rename out_nomod label to out_putmodRobert Love2012-02-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The label implies that it should be called when there is 'nomod.' I read that to mean that the module reference 'get' failed. However, it's only called when the module reference 'get' succeeded. I think it makes more sense to name the label, 'out_putmod' since it should be called when we need to 'put' the module reference taken in the routine before returning. Signed-off-by: Robert Love <robert.w.love@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * [SCSI] fcoe: Allow exposing FDMI attributes via sysfsNeerav Parikh2012-02-191-0/+8
| | | | | | | | | | | | | | | | | | | | Allow FDMI attributes to be exposed via the fc_host class object for the fcoe driver. Signed-off-by: Neerav Parikh <neerav.parikh@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * [SCSI] fcoe: Allow exposing FDMI attributes via sysfsNeerav Parikh2012-02-191-0/+8
| | | | | | | | | | | | | | | | | | | | Allow FDMI attributes to be exposed via the fc_host class object for the fcoe driver. Signed-off-by: Neerav Parikh <neerav.parikh@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Acked-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
OpenPOWER on IntegriCloud