Do not use a generic name to avoid confusions with other usages.
Signed-off-by: NHannes Reinecke <hare@suse.com>
Acked-by: NJohannes Thumshirn <jth@kernel.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Use defines from ethtool for 20Gbit and 40Gbit speeds instead of magic
numbers.
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: NLaurence Oberman <loberman@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

When the FIP mode is changed we need to update the multicast addresses
to ensure we get the correct frames.
Signed-off-by: NHannes Reinecke <hare@suse.com>
Acked-by: NJohannes Thumshirn <jth@kernel.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

'->realdev' is always set, so this check is pointless.
Signed-off-by: NHannes Reinecke <hare@suse.com>
Acked-by: NJohannes Thumshirn <jth@kernel.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The FIP mode is independent on the FIP state machine, so use a separate
enum for that instead of overloading it with state machine values.
Signed-off-by: NHannes Reinecke <hare@suse.com>
Acked-by: NJohannes Thumshirn <jth@kernel.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Update to latest FC-BB-6 draft to include FIP VN2VN VLAN notifications
and additional flags.
Signed-off-by: NHannes Reinecke <hare@suse.com>
Acked-by: NJohannes Thumshirn <jth@kernel.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The driver creates its own per-CPU threads which are updated based on
CPU hotplug events. It is also possible to use kworkers and remove some
of the kthread infrastrucure.

The code checked ->thread to decide if there is an active per-CPU
thread. By using the kworker infrastructure this is no longer
possible (or required). The thread pointer is saved in `kthread' instead
of `thread' so anything trying to use thread is caught by the
compiler. Currently only the bnx2fc driver is using struct fcoe_percpu_s
and the kthread member.

After a CPU went offline, we may still enqueue items on the "offline"
CPU. This isn't much of a problem. The work will be done on a random
CPU. The allocated crc_eof_page page won't be cleaned up. It is probably
expected that the CPU comes up at some point so it should not be a
problem. The crc_eof_page memory is released of course once the module
is removed.

This patch was only compile-tested due to -ENODEV.

Cc: Vasu Dev <vasu.dev@intel.com>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: fcoe-devel@open-fcoe.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: NJohannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Originally libfc would just be initializing the refcount to '1', and
using the disc_mutex to synchronize if and when the final put should be
happening.  This has a race condition as the mutex might be delayed,
causing other threads to access an invalid structure.  This patch
updates the rport reference counting to increase the reference every
time 'rport_lookup' is called, and decreases the reference
correspondingly.  This removes the need to hold 'disc_mutex' when
removing the structure, and avoids the above race condition.
Signed-off-by: NHannes Reinecke <hare@suse.com>
Acked-by: NVasu Dev <vasu.dev@intel.com>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Do not reset fip selection time for every advertisement
in fcoe_ctlr_recv_adv() but set it only once for the first
validated FCF. Otherwise FCF selection won't happen when the
advertisements consistently arrive with sub FCOE_CTLR_START_DELAY
periodicity.
Tested-by: NNarendra K <narendra_k@dell.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Acked-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NUsha Ketineni <usha.k.ketineni@intel.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Signed-off-by: NDavid Decotigny <decot@googlers.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When setting up CRC offload set ip_summed to CHECKSUM_PARTIAL
instead of CHECKSUM_UNNECESSARY. This is consistent with the
definition of CHECKSUM_PARTIAL.

The only driver that seems to be advertising NETIF_F_FCOE_CRC is
ixgbe. AFICT the driver does not look at ip_summed for FCOE and
just assumes that CRC is being offloaded.
Signed-off-by: NTom Herbert <tom@herbertland.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch changes the !blk-mq path to the same defaults as the blk-mq
I/O path by always enabling block tagging, and always using host wide
tags.  We've had blk-mq available for a few releases so bugs with
this mode should have been ironed out, and this ensures we get better
coverage of over tagging setup over different configs.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NJens Axboe <axboe@kernel.dk>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

There is a label pointing to the start of a while loop and a goto
nested only in the loop. The goto jumps to the label in some cases.
Replace the goto and the label by simple continue.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Acked-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

In little endian cases, the macro htons unfolds to __swab16 which
provides special case for constants. In big endian cases,
__constant_htons and htons expand directly to the same expression.
So, replace __constant_htons with htons with the goal of getting
rid of the definition of __constant_htons completely.

The semantic patch that performs this transformation is as follows:

@@expression x;@@

- __constant_htons(x)
+ htons(x)
Signed-off-by: NVaishali Thakkar <vthakkar1994@gmail.com>
Acked-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>

This patch fix some "a ethernet" in MODULE_DESCRIPTIONS in
fcoe_transport.c
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.com>

Since we got rid of ordered tag support in 2010 the prime use case of
switching on and off ordered tags has been obsolete.  The other function
of enabling/disabling tagging entirely has only been correctly implemented
by the 53c700 driver and isn't generally useful.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NBart Van Assche <bvanassche@acm.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com
Reviewed-by: NHannes Reinecke <hare@suse.de>

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: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Reviewed-by: NHannes Reinecke <hare@suse.de>

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: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Reviewed-by: NVenkatesh Srinivas <venkateshs@google.com>

Always returns the same skb it gets, so change to void.
Signed-off-by: NJiri Pirko <jiri@resnulli.us>
Acked-by: NPravin B Shelar <pshelar@nicira.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NHannes Reinecke <hare@suse.de>

Most drivers use exactly the same implementation, so provide it as a
library function.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NBart Van Assche <bvanassche@acm.org>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NHannes Reinecke <hare@suse.de>

add support for 20 Gbit and 40 Gbit links
Signed-off-by: NChris Leech <cleech@redhat.com>
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

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: NKirill Tkhai <ktkhai@parallels.com>
Signed-off-by: NPeter 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: NIngo Molnar <mingo@kernel.org>

Replace various -20/+19 hardcoded nice values with MIN_NICE/MAX_NICE.
Signed-off-by: NDongsheng Yang <yangds.fnst@cn.fujitsu.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NPeter 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: NIngo Molnar <mingo@kernel.org>

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: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NJoe Perches <joe@perches.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

In this pending patch:
http://patchwork.open-fcoe.org/patch/104/

Tomas Henzl noted that the error path when fcoe_fcf_device_add fails, was
missing a mutex_unlock call.

Not sure what staet the integration of the above patch is in, but if you could
either merge this with it, or apply it on top of what you already have, that
would be great.  Thanks!
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: thenzl@redhat.com
Reported-by: thenzl@redhat.com
Signed-off-by: NRobert Love <robert.w.love@intel.com>

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: NRobert Love <robert.w.love@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Tested-by: NHiral Patel <hiralpat@cisco.com>

I had a typo in a variable name for the previous patch (SCSI: fcoe:
convert bus code to use bus_group) that broke the build, this fixes
that.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the fcoe bus code to use the
correct field.

Cc: Robert Love <robert.w.love@intel.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes the following compiler warning:

drivers/scsi/fcoe/fcoe_ctlr.c: In function fcoe_sysfs_fcf_add:
drivers/scsi/fcoe/fcoe_ctlr.c:211:1: warning: the frame size of 1480 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

FCoE debug statements must end in a newline. Add one where it is missing.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

The function fcoe_ctlr_mode_set() is local, hence declare it static.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

the return codes from fcoe_rcv should be NET_RX_*, not 0 or -1.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

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: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Recently had this Oops reported to me on the 3.10 kernel:

[  807.554955] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[  807.562799] IP: [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[  807.568296] PGD 20c889067 PUD 20c8b8067 PMD 0
[  807.572769] Oops: 0002 [#1] SMP
[  807.655597] Hardware name: Dell Inc. PowerEdge R415/0DDT2D, BIOS 1.8.6 12/06/2011
[  807.663079] Workqueue: events fcoe_ctlr_recv_work [libfcoe]
[  807.668656] task: ffff88020b42a160 ti: ffff88020ae6c000 task.ti: ffff88020ae6c000
[  807.676126] RIP: 0010:[<ffffffff814e6fc7>]  [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[  807.684046] RSP: 0000:ffff88020ae6dd70  EFLAGS: 00010097
[  807.689349] RAX: 0000000000000246 RBX: ffff8801d04d6700 RCX: 0000000000000000
[  807.696474] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88020df26434
[  807.703598] RBP: ffff88020ae6dd88 R08: 00000000000173e0 R09: ffff880216e173e0
[  807.710723] R10: ffffffff814e5897 R11: ffffea0007413580 R12: ffff88020df26420
[  807.717847] R13: ffff88020df26434 R14: 0000000000000004 R15: ffff8801d04c42ce
[  807.724972] FS:  00007fdaab6048c0(0000) GS:ffff880216e00000(0000) knlGS:0000000000000000
[  807.733049] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  807.738785] CR2: 0000000000000008 CR3: 000000020cbc9000 CR4: 00000000000006f0
[  807.745910] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  807.753033] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  807.760156] Stack:
[  807.762162]  ffff8801d04d6700 0000000000000001 ffff88020df26400 ffff88020ae6de20
[  807.769586]  ffffffffa0444409 ffff88020b046a00 ffff88020ae6dde8 ffffffff810105be
[  807.777008]  ffff88020b42a868 0000000000000000 ffff88020df264a8 ffff88020df26348
[  807.784431] Call Trace:
[  807.786885]  [<ffffffffa0444409>] fcoe_ctlr_recv_work+0x59/0x9a0 [libfcoe]
[  807.793755]  [<ffffffff810105be>] ? __switch_to+0x13e/0x4a0
[  807.799324]  [<ffffffff8107d0e6>] process_one_work+0x176/0x420
[  807.805151]  [<ffffffff8107dd0b>] worker_thread+0x11b/0x3a0
[  807.810717]  [<ffffffff8107dbf0>] ? rescuer_thread+0x350/0x350
[  807.816545]  [<ffffffff810842b0>] kthread+0xc0/0xd0
[  807.821416]  [<ffffffff810841f0>] ? insert_kthread_work+0x40/0x40
[  807.827503]  [<ffffffff8160ce2c>] ret_from_fork+0x7c/0xb0
[  807.832897]  [<ffffffff810841f0>] ? insert_kthread_work+0x40/0x40
[  807.858500] RIP  [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[  807.864076]  RSP <ffff88020ae6dd70>
[  807.867558] CR2: 0000000000000008

Looks like the root cause is the fact that the packet recieve function
fcoe_ctlr_recv enqueues the skb to a sk_buff_head_list prior to ensuring that
the skb is unshared.  This can happen when multiple packet listeners recieve an
skb, as the deliver_skb function just increments skb->users for each handler.
As a result, having multiple users of a single skb results in multiple
manipulators of its methods, implying list corruption, and the oops recorded
above.

The fix is pretty easy, just make sure that we clone the skb if its got multiple
users with the skb_share_check function, like other protocols do.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Declare local variables and functions 'static'. This patch does not
change any functionality.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

When repeatedly doing rmmod and modprobe on the ixgbe
driver while FCoE is active in a VN2VN configuration,
memory leaks would be discovered by kmemleak with the
following backtrace:

unreferenced object 0xffff88003d076000 (size 1024):
  comm "kworker/0:3", pid 2998, jiffies 4295436448 (age 1015.332s)
  hex dump (first 32 bytes):
    48 8a fe 6f 00 88 ff ff 00 00 00 00 00 00 00 00  H..o............
    01 00 00 00 02 00 00 00 7b ac 87 21 1b 00 00 10  ........{..!....
  backtrace:
    [<ffffffff814b308b>] kmemleak_alloc+0x5b/0xc0
    [<ffffffff8115c6e8>] __kmalloc+0xd8/0x1b0
    [<ffffffffa0216638>] fc_rport_create+0x48/0x1f0 [libfc]
    [<ffffffffa023cd86>] fcoe_ctlr_vn_add.isra.10+0x56/0x1a0 [libfcoe]
    [<ffffffffa023f440>] fcoe_ctlr_vn_recv+0x8b0/0xab0 [libfcoe]
    [<ffffffffa023fb06>] fcoe_ctlr_recv_work+0x4c6/0xf60 [libfcoe]
    [<ffffffff81067404>] process_one_work+0x1e4/0x4d0
    [<ffffffff81068def>] worker_thread+0x10f/0x380
    [<ffffffff8107019a>] kthread+0xea/0xf0
    [<ffffffff814d32ec>] ret_from_fork+0x7c/0xb0
    [<ffffffffffffffff>] 0xffffffffffffffff

This patch stops the leak of the fc_rport_priv structure.
Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

ctlr_dev was initialized to NULL, and never re-assigned. This
caused the log statement to always report failure. This patch
removes the unused variable and fixes the log statement to always
report 'success', as that is what should be logged if the code
reaches this point.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

Both fcoe_fc_els_lesb and fc_els_lesb are in __be32 already, and both are
exactly the same size in bytes, with somewhat different member names to
reflect the fact the former is for Ethernet media the latter is for Fiber
Channel, so, remove conversion and use __be32 directly. This fixes the warning
from sparse check.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>