commit 6942df7f775107b504f10de42c81971f514d718d Author: Joe Perches Date: Mon Sep 2 03:32:33 2013 +0000 scsi: Convert uses of compare_ether_addr to ether_addr_equal 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 commit 55d0ac5d2839fe270cea02fad44eed13750a0efd Author: Neil Horman Date: Tue Oct 8 23:43:58 2013 +0000 fcoe: Fix missing mutex_unlock in fcoe_sysfs_fcf_add error path 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: Neil Horman CC: thenzl@redhat.com Reported-by: thenzl@redhat.com Signed-off-by: Robert Love commit 9d34876f820d55c94bd0b2a2ed3d2e2976cbd997 Author: Robert Love Date: Thu Sep 5 07:47:27 2013 +0000 libfcoe: Make fcoe_sysfs optional / fix fnic NULL exception 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 commit 1c2c1b4fbd413fd814807768d2aba9023722ed76 Author: Bart Van Assche Date: Wed Aug 14 15:42:46 2013 +0000 fcoe: Reduce fcoe_sysfs_fcf_add() stack usage 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: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit 465b87bfe96a5b257804fd89aa982319e8c58064 Author: Bart Van Assche Date: Wed Aug 14 15:42:09 2013 +0000 fcoe: Add missing newlines in debug messages 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 commit 41463a8851cd334341d143fbed558fa0c2e6865b Author: Bart Van Assche Date: Wed Aug 14 15:41:22 2013 +0000 fcoe: Declare fcoe_ctlr_mode_set() static The function fcoe_ctlr_mode_set() is local, hence declare it static. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit 9de99010cbebca4d4343117eff1af9a64d5d4896 Author: Bart Van Assche Date: Wed Aug 14 15:40:49 2013 +0000 fcp: Do not interpret check condition as underrun This patch avoids that the FCoE initiator sends a REC message after having received a SCSI response with non-zero status and non-zero DATA IN buffer length. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit 7030fd626129ec4d616784516a462d317c251d39 Author: Bart Van Assche Date: Sat Aug 17 20:34:43 2013 +0000 libfc: Do not invoke the response handler after fc_exch_done() While the FCoE initiator driver invokes fc_exch_done() from inside the libfc response handler, FCoE target drivers typically invoke fc_exch_done() from outside the libfc response handler. The object fc_exch.arg points at may disappear as soon as fc_exch_done() has finished. So it's important not to invoke the response handler function after fc_exch_done() has finished. Modify libfc such that this guarantee is provided if fc_exch_done() is invoked from outside a response handler. This patch fixes a sporadic crash in FCoE target implementations after a command has been aborted. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit f95b35cfcacadac16dbc5477fd22b0786256a3d1 Author: Bart Van Assche Date: Wed Aug 14 15:38:24 2013 +0000 libfc: Reduce exchange lock contention in fc_exch_recv_abts() Reduce the time during which the exchange lock is held by allocating a frame before obtaining the exchange lock. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit cae7b6dd6c569f18f5c8e3f33cac60fbaeb58140 Author: Bart Van Assche Date: Wed Aug 14 15:37:52 2013 +0000 libfc: Avoid that sending after an abort triggers a kernel warning Calling fc_seq_send() after an ABTS message has been received triggers a kernel warning (WARN_ON(!(ep->esb_stat & ESB_ST_SEQ_INIT))). Avoid this by returning -ENXIO to the caller if fc_seq_send() is invoked after an ABTS message has been received. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit 5d73bea2d3a004698d16ba5face89f0bef383e76 Author: Bart Van Assche Date: Wed Aug 14 15:37:08 2013 +0000 libfc: Protect ep->esb_stat changes via ex_lock This patch avoids that the WARN_ON(!(ep->esb_stat & ESB_ST_SEQ_INIT)) statement in fc_seq_send_locked() gets triggered sporadically when running FCoE target code due to concurrent ep->esb_stat modifications. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit b86788658be425a5454246a954721d9122d2b3d6 Author: Bart Van Assche Date: Wed Aug 14 15:35:29 2013 +0000 libfc: Fix a race in fc_exch_timer_set_locked() It is allowed to pass a zero timeout value to fc_seq_exch_abort(). Avoid that this can cause the timeout function to drop the exchange reference before it has been increased by fc_exch_timer_set_locked(). This patch fixes a crash when running FCoE target code with poisoning enabled in the memory allocator. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit 8d08023687e2515f2a48235aed80b6982025cd09 Author: Bart Van Assche Date: Sat Aug 17 20:20:07 2013 +0000 libfc: Clarify fc_exch_find() The condition ep != NULL && ep->xid != xid can never be met. Make this explicit. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit a84ea8c7e839a73dab4bfc755f7f52e947690dab Author: Bart Van Assche Date: Wed Aug 14 15:33:35 2013 +0000 libfc: Micro-optimize fc_setup_exch_mgr() Convert a loop into an ilog2() call. Although this code is not performance sensitive this conversion makes this code easier to read. Signed-off-by: Bart Van Assche Cc: Neil Horman Signed-off-by: Robert Love commit b20d9bfda77306c2f66a90eb94ef9db58fb1e682 Author: Bart Van Assche Date: Wed Aug 14 15:32:51 2013 +0000 libfc: Debug code fixes The second argument of fc_lport_error() may be a valid frame pointer. Hence only print it as an error code if it really is an error code. 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 commit c1d454246c1339388ed0788f34f88ee12ad58ef3 Author: Bart Van Assche Date: Wed Aug 14 15:31:52 2013 +0000 libfc: Source code comment spelling fixes Change 'initiaive' into 'initiative', 'remainig' into 'remaining' and change 'exected' into 'expected'. Signed-off-by: Bart Van Assche Signed-off-by: Robert Love commit 34bac2ef5981666261fcf6932f4cd718b820323f Author: Neil Horman Date: Sat Aug 3 10:45:55 2013 +0000 fcoe: cleanup return codes from fcoe_rcv the return codes from fcoe_rcv should be NET_RX_*, not 0 or -1. Signed-off-by: Neil Horman Signed-off-by: Robert Love commit 8b6124345207e4c2141bed78f1bf7c4f526a6d19 Author: Neil Horman Date: Sat Aug 3 10:45:54 2013 +0000 fcoe: make sure fcoe frames are unshared prior to manipulating them 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 commit c0866286f10964e61ec10c8c605ef86e65fbbd38 Author: Neil Horman Date: Sat Aug 3 10:45:53 2013 +0000 fcoe: ensure that skb placed on the fip_recv_list are unshared 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: [] 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:[] [] 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] [] fcoe_ctlr_recv_work+0x59/0x9a0 [libfcoe] [ 807.793755] [] ? __switch_to+0x13e/0x4a0 [ 807.799324] [] process_one_work+0x176/0x420 [ 807.805151] [] worker_thread+0x11b/0x3a0 [ 807.810717] [] ? rescuer_thread+0x350/0x350 [ 807.816545] [] kthread+0xc0/0xd0 [ 807.821416] [] ? insert_kthread_work+0x40/0x40 [ 807.827503] [] ret_from_fork+0x7c/0xb0 [ 807.832897] [] ? insert_kthread_work+0x40/0x40 [ 807.858500] RIP [] skb_dequeue+0x47/0x70 [ 807.864076] RSP [ 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: Neil Horman Signed-off-by: Robert Love