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

Merge branch 'sched/urgent' into sched/core, to avoid conflicts

2014-05-07T11:15:46Z

Signed-off-by: Ingo Molnar

sched, treewide: Replace hardcoded nice values with MIN_NICE/MAX_NICE

2014-04-18T10:07:24Z

Replace various -20/+19 hardcoded nice values with MIN_NICE/MAX_NICE. Signed-off-by: Dongsheng Yang Acked-by: Tejun Heo Signed-off-by: Peter Zijlstra 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

scsi, fcoe: Fix CPU hotplug callback registration

2014-03-20T12:43:45Z

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 Cc: "James E.J. Bottomley" Cc: Ingo Molnar Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki

scsi: Convert uses of compare_ether_addr to ether_addr_equal

2013-10-14T15:25:40Z

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 Signed-off-by: Robert Love

libfcoe: Make fcoe_sysfs optional / fix fnic NULL exception

2013-10-11T20:25:40Z

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 Acked-by: Neil Horman Tested-by: Hiral Patel

fcoe: Add missing newlines in debug messages

2013-09-04T21:07:13Z

FCoE debug statements must end in a newline. Add one where it is missing. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love

fcoe: cleanup return codes from fcoe_rcv

2013-09-04T19:40:43Z

the return codes from fcoe_rcv should be NET_RX_*, not 0 or -1. Signed-off-by: Neil Horman Signed-off-by: Robert Love

fcoe: make sure fcoe frames are unshared prior to manipulating them

2013-09-04T19:33:08Z

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 Signed-off-by: Robert Love

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

2013-07-14T00:41:21Z

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 function

2013-07-09T16:29:17Z

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 Signed-off-by: Neerav Parikh Tested-by: Jack Morgan Signed-off-by: Robert Love