kernel/git/stable/linux.git/drivers/scsi/fcoe, branch linux-2.6.38.y

[SCSI] libfcoe: change fip_select to return new FCF

2010-12-21T18:24:34+00:00

Neaten several calls to fip_select() by having it return the pointer to the new FCF. Signed-off-by: Joe Eykholt Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfcoe: reorder FCF list to put latest advertiser first

2010-12-21T18:24:33+00:00

When there are several FCFs to choose from, the one most likely to accept a FLOGI on certian switches is the one that last answered a multicast solicit. So, when receiving an advertisement, move the FCF to the front of the list so that it gets chosen first among those with the same priority. Without this, more FLOGIs need to be sent in a test with multiple FCFs and a switch in NPV mode, but it still eventually finds one that accepts the FLOGI. Signed-off-by: Joe Eykholt Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfcoe: add debug message for FCF destination MAC

2010-12-21T18:24:33+00:00

When multiple FCFs to the same fabric exist, the debug messages all look alike. Change the message to include the MAC address. Signed-off-by: Joe Eykholt Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfcoe: retry rejected FLOGI to another FCF if possible

2010-12-21T18:24:32+00:00

Switches using multiple-FCFs may reject FLOGI in order to balance the load between multiple FCFs. Even though the FCF was available, it may have more load at the point we actually send the FLOGI. If the FLOGI fails, select a different FCF if possible, among those with the same priority. If no other FCF is available, just deliver the reject to libfc for retry. Signed-off-by: Joe Eykholt Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfcoe: fix checking of conflicting fabrics in fcoe_ctlr_select()

2010-12-21T18:24:32+00:00

The check for conflicting fabrics in fcoe_ctlr_select() ignores any FCFs that aren't usable. This is a minor problem now but becomes more pronounced after later patches. Signed-off-by: Joe Eykholt Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfcoe: move some timer code to make it reusable.

2010-12-21T18:24:29+00:00

Move some of the code in fcoe_ctlr_timer_work() to fcoe_ctlr_select() so that it can be shared with another function in a forthcoming patch. Signed-off-by: Joe Eykholt Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfcoe: update FIP FCF announcements

2010-12-21T18:24:28+00:00

Move the announcement code to a separate function for reuse in a forthcoming patch. For messages regarding FCF timeout and selection, use the previously-announced FCF MAC address (dest_addr) in the fcoe_ctlr struct. Only print (announce) the FCF if it is new. Print MAC for timed-out or deselected FCFs. Signed-off-by: Joe Eykholt Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] drivers/scsi/fcoe: Update WARN uses

2010-12-21T18:24:24+00:00

Add missing newlines. Signed-off-by: Joe Perches Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] libfc: fix NULL pointer dereference bug in fc_fcp_pkt_release

2010-12-21T18:24:18+00:00

This happens when then tearing down the fcoe interface with active I/O. The back trace shows dead000000200200 in RAX, i.e., LIST_POISON2, indicating that the fsp is already being dequeued, which is probably why no complaining was seen in fc_fcp_destroy() about outstanding fsp not freed, since we dequeue it in the end of fc_io_compl() before releasing it. The bug is due to the fact that we have already destroyed lport's scsi_pkt_pool while on-going i/o is still accessing it through fc_fcp_pkt_release(), like this trace or the similar code path from scsi-ml to fc_eh_abort, etc. This is fixed by moving the fc_fcp_destroy() after lport is detached from scsi-ml since fc_fcp_destroy is supposed to called only once where no lport lock is taken, otherwise the fc_fcp_pkt_release() would have to grab the lport lock. BUG: unable to handle kernel NULL pointer dereference at (null) ....... RIP: 0010:[<0000000000000000>] [<(null)>] (null) RSP: 0018:ffff8803270f7b88 EFLAGS: 00010282 RAX: dead000000200200 RBX: ffff880197d2fbc0 RCX: 0000000000005908 RDX: ffff880195ea6d08 RSI: 0000000000000282 RDI: ffff880180f4fec0 RBP: ffff8803270f7bc0 R08: ffff880197d2fbe0 R09: 0000000000000000 R10: ffff88032867f090 R11: 0000000000000000 R12: ffff880195ea6d08 R13: 0000000000000282 R14: ffff880180f4fec0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8801b5820000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000000 CR3: 00000001a6eae000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process fc_rport_eq (pid: 5278, threadinfo ffff8803270f6000, task ffff880326254ab0) Stack: ffffffffa02c39ca ffff8803270f7ba0 ffff88019331cbc0 ffff880197d2fbc0 0000000000000000 ffff8801a8c895e0 ffff8801a8c895e0 ffff8803270f7c10 ffffffffa02c4962 ffff8803270f7be0 ffffffff814c94ab ffff8803270f7c10 Call Trace: [] ? fc_io_compl+0x10a/0x530 [libfc] [] fc_fcp_complete_locked+0x72/0x150 [libfc] [] ? _spin_unlock_bh+0x1b/0x20 [] ? fc_exch_done+0x3f/0x60 [libfc] [] fc_fcp_retry_cmd+0x4f/0x60 [libfc] [] fc_fcp_recv+0x9b0/0xc30 [libfc] [] ? _call_console_drivers+0x4a/0x80 [] ? lock_timer_base+0x3c/0x70 [] ? try_to_del_timer_sync+0x7b/0xe0 [] fc_exch_mgr_reset+0x1df/0x250 [libfc] [] ? fc_fcp_recv+0x0/0xc30 [libfc] [] fc_rport_work+0xf2/0x4e0 [libfc] [] ? prepare_to_wait+0x4e/0x80 [] ? fc_rport_work+0x0/0x4e0 [libfc] [] worker_thread+0x170/0x2a0 [] ? autoremove_wake_function+0x0/0x40 [] ? worker_thread+0x0/0x2a0 [] kthread+0x96/0xa0 [] child_rip+0xa/0x20 [] ? kthread+0x0/0xa0 [] ? child_rip+0x0/0x20 Code: Bad RIP value. RIP [<(null)>] (null) RSP CR2: 0000000000000000 Signed-off-by: Yi Zou Signed-off-by: Robert Love Signed-off-by: James Bottomley

[SCSI] fcoe: Fix broken NPIV with correction to MAC validation

2010-10-25T20:11:39+00:00

A previous patch attempted to validate the destination MAC address of a FCoE frame by checking that MAC address against the received port's MAC address. The implementation seems fine on the surface, but any VN_Ports added using the NPIV feature will have their own MAC addresses and these MACs were not being checked, which prevented any NPIV VN_Ports from receiving frames. In other words, the following patch has broken NPIV. 519e5135e2537c9dbc1cbcc0891b0a936ff5dcd2 [SCSI] fcoe: adds src and dest mac address checking for fcoe frames Part of the offending patch is correct, but the part that broke NPIV was attempting to satisfy FC-BB-5 section D.5, 2.1- (discard frames that) "contain a destination MAC address/destination N_Port_ID pair that was not assigned by an FCF to one of the VN_Ports on the ENode" The language does _not_ say to compare the destination FC-MAP/destination N_Port_ID, but instead to compare the destination MAC address/destination N_Port_ID. >From the FC-BB-5 specification, "A properly formed FPMA is one in which the 24 most significant bits equal the Fabric’s FC-MAP value and the least significant 24 bits equal the N_Port_ID assigned to the VN_Port by the FCF." This means that we need to compare the FC Frame's destination FCID against the embedded FCID in the destination MAC address. This patch checks the lower 24 bits of the destination MAC address against destination FCID in the Fibre Channel frame. For MAC validation the first line of defense is the hardware MAC filtering. Each VN_Port will have a unicast MAC addresses added to the hardware's filtering table. The Ethernet driver should drop any MACs not destined for a programmed MAC. This patch adds a second line of defense that very specfically compares an element in the FC frame against an element in the Ethernet header, which is appropriate for the FCoE layer. Many alternative approaches were considered, including a LLD callback from libfc. The second most reasonable approach seemed to be walking the list of NPIV ports and check each of their MAC addresses against the destination MAC address of the received frame. The problem with this approach was that it is likely that performance would suffer with the more NPIV ports added to the system since every received frame would need to walk this list, comparing each entry's MAC. Signed-off-by: Robert Love Signed-off-by: James Bottomley