summaryrefslogtreecommitdiff
path: root/drivers/scsi/fcoe/fcoe.c
AgeCommit message (Collapse)AuthorFilesLines
2010-05-16[SCSI] fcoe: fix a circular locking issue with rtnl and sysfs mutexVasu Dev1-7/+34
Currently rtnl mutex is grabbed during fcoe create, destroy, enable and disable operations while sysfs s_active read mutex is already held, but simultaneously other networking events could try grabbing write s_active mutex while rtnl is already held and that is causing circular lock warning, its detailed log pasted at end. In this log, the rtnl was held before write s_active during device renaming but there are more such cases as Joe reported another instance with tg3 open at:- http://www.open-fcoe.org/pipermail/devel/2010-February/008263.html This patch fixes this issue by not waiting for rtnl mutex during fcoe ops, that means if rtnl mutex is not immediately available then restart_syscall() to allow others waiting in line to grab s_active along with rtnl mutex to finish their work first under these mutex. Currently rtnl mutex was grabbed twice during fcoe_destroy call flow, second grab was from fcoe_if_destroy called from fcoe_destroy after dropping rtnl mutex before calling fcoe_if_destroy, so instead made fcoe_if_destroy always called with rtnl mutex held to have this mutex grabbed only once in this code path. However left matching rtnl_unlock as-is in its original place as it was dropped there for good reason since very next call causes synchronous fip worker flush and if rtnl mutex is still held before flush then that would cause new circular warning between fip->recv_work and rtnl mutex, I've added detailed comment for this on fcoe_if_destroy calling and rtnl muxtes unlocking. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.33.1linux-stable-2.6.33 #1 ------------------------------------------------------- fcoemon/18823 is trying to acquire lock: (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] but task is already holding lock: (s_active){++++.+}, at: [<ffffffff8115ef93>] sysfs_get_active_two+0x31/0x48 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (s_active){++++.+}: [<ffffffff81077bdb>] __lock_acquire+0xb73/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8115e5df>] sysfs_deactivate+0x8b/0xe0 [<ffffffff8115edfb>] sysfs_addrm_finish+0x36/0x55 [<ffffffff8115d0cc>] sysfs_hash_and_remove+0x53/0x6a [<ffffffff8115f353>] sysfs_remove_link+0x21/0x23 [<ffffffff812b6c93>] device_rename+0x99/0xcb [<ffffffff8138dbf0>] dev_change_name+0xd5/0x1d2 [<ffffffff8138deee>] dev_ifsioc+0x201/0x2ac [<ffffffff8138e4ba>] dev_ioctl+0x521/0x632 [<ffffffff81379e43>] sock_do_ioctl+0x3d/0x47 [<ffffffff8137a254>] sock_ioctl+0x213/0x222 [<ffffffff81114614>] vfs_ioctl+0x32/0xa6 [<ffffffff81114b94>] do_vfs_ioctl+0x490/0x4d6 [<ffffffff81114c30>] sys_ioctl+0x56/0x79 [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b -> #1 (rtnl_mutex){+.+.+.}: [<ffffffff81077bdb>] __lock_acquire+0xb73/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffff813959f9>] rtnl_lock+0x17/0x19 [<ffffffff8138ccae>] register_netdevice_notifier+0x1e/0x19b [<ffffffffa02580c1>] 0xffffffffa02580c1 [<ffffffff81002069>] do_one_initcall+0x5e/0x15e [<ffffffff81084094>] sys_init_module+0xd8/0x23a [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b -> #0 (fcoe_config_mutex){+.+.+.}: [<ffffffff81077a85>] __lock_acquire+0xa1d/0xd2b [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff810635b1>] param_attr_store+0x27/0x35 [<ffffffff81063619>] module_attr_store+0x26/0x2a [<ffffffff8115dae3>] sysfs_write_file+0x108/0x144 [<ffffffff81107bd1>] vfs_write+0xae/0x10b [<ffffffff81107cee>] sys_write+0x4a/0x6e [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b other info that might help us debug this: 3 locks held by fcoemon/18823: #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8115da17>] sysfs_write_file+0x3c/0x144 #1: (s_active){++++.+}, at: [<ffffffff8115ef86>] sysfs_get_active_two+0x24/0x48 #2: (s_active){++++.+}, at: [<ffffffff8115ef93>] sysfs_get_active_two+0x31/0x48 stack backtrace: Pid: 18823, comm: fcoemon Tainted: G W 2.6.33.1linux-stable-2.6.33 #1 Call Trace: [<ffffffff81076c38>] print_circular_bug+0xa8/0xb6 [<ffffffff81077a85>] __lock_acquire+0xa1d/0xd2b [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff81077e60>] lock_acquire+0xcd/0xf1 [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff8142f343>] __mutex_lock_common+0x4b/0x383 [<ffffffffa02ba5fc>] ? fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff8106ac70>] ? cpu_clock+0x43/0x5e [<ffffffff81074e12>] ? lockstat_clock+0x11/0x13 [<ffffffff81074e40>] ? lock_release_holdtime+0x2c/0x127 [<ffffffff8115ef93>] ? sysfs_get_active_two+0x31/0x48 [<ffffffff8142f73f>] mutex_lock_nested+0x3e/0x43 [<ffffffffa02ba5fc>] fcoe_create+0x27/0x4f7 [fcoe] [<ffffffff810635b1>] param_attr_store+0x27/0x35 [<ffffffff81063619>] module_attr_store+0x26/0x2a [<ffffffff8115dae3>] sysfs_write_file+0x108/0x144 [<ffffffff81107bd1>] vfs_write+0xae/0x10b [<ffffffff81076596>] ? trace_hardirqs_on_caller+0x125/0x150 [<ffffffff81107cee>] sys_write+0x4a/0x6e [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-05-16[SCSI] fcoe: move link speed checking into its own routineRobert Love1-13/+29
It doesn't make sense to update the link speed in the is_link_ok() routine. Move it to it's own routine and acquire the device speed when we're configuring the device initially as well as if there are any netdev events received. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-05-16[SCSI] fcoe: fixes wrong error exit in fcoe_createVasu Dev1-1/+1
fcoe_create exits using out_nodev label when module is not yet LIVE but this exit path unlocks the rtnl_lock though rtnl lock was not held in this case. So this patch replaces out_nodev with out_nomod to exit w/o unlocking rtnl_lock. Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] libfc, fcoe: normalize format specifies for world wide namesChris Leech1-1/+2
Print all world wide node names (node, port and fabric) with the same format specifier of "%16.16llx". That makes sure they all print as a 16 character hex string, with lower case letters, no 0x prefix, and without stripping off any leading 0s. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] fcoe, fnic, libfc: increased CDB size to 16 bytes for fcoe.Vasu Dev1-0/+2
No reason to restrict CDB size to 12 bytes in fcoe, so increased to 16 so that 16 bytes SCSI CDB doesn't fail. Uses common define to set max_cmd_len for fcoe and fnic, fnic is already setting max_cmd_len to 16. sg_readcap -l fails without this fix. Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] fcoe: removes unused shost in fcoe_shost_configVasu Dev1-6/+2
Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] fcoe: check netif operstate instead of IFF_UP & link stateChris Leech1-2/+1
Allow for dormant states while link configuration completes. In the default link mode, this is equivalent to the old check. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] fcoe: reset FIP ctlr link state on disable/enableChris Leech1-4/+7
The FIP controler state wasn't being reset on a disable. A disable/enable sequence should be treated as a link event. Otherwise, when using disable to mask a time when the link is up but unusable, FCF discovery would attempt to continue and login would jump directly to the non-FIP fallback on enable. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] libfc, libfcoe, fcoe: use smp_processor_id() only when preempt disabledJoe Eykholt1-26/+25
When the kernel is configured for preemption, using smp_processor_id() when preemption is enabled causes a warning backtrace and is wrong since we could move off of that CPU as soon as we get the ID, and we would be referencing the wrong CPU, and possibly an invalid one if it could be hotswapped out. Remove the fc_lport_get_stats() function and explicitly use per_cpu_ptr() to get the statistics. Where preemption has been disabled by holding a _bh lock continue to use smp_processor_id(), but otherwise use get_cpu()/put_cpu(). In fcoe_recv_frame() also changed the cases where we return in the middle to do a goto to the code which bumps ErrorFrames and does a put_cpu(). Two of these cases didn't bump ErrorFrames before, but doing so is harmless because they "can't happen", due to prior length checks. Also rearranged code in fcoe_recv_frame() to have only one call to fc_exch_recv(). It's just as efficient and saves a call to put_cpu(). In fc_fcp.c, adjusted a FIXME comment for code which doesn't need fixing. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] fcoe: remove an unused variable in fcoe_recv_frame()Joe Eykholt1-5/+0
Remove an unused variable, mac, in fcoe_recv_frame(). Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] fcoe: save gateway address when receiving FLOGI requestJoe Eykholt1-0/+24
In point-to-point mode, we need to save the source MAC from received FLOGI requests to use as the destination MAC for all outgoing frames. We stopped doing that at some point. Use the lport_set_port_id method to catch incoming FLOGI frames and pass them to fcoe_ctlr_recv_flogi() so it can save the source MAC. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] fcoe: call fcoe_ctlr_els_send even for ELS responsesJoe Eykholt1-1/+1
In point-to-point mode, the destination MAC address for the FLOGI response was zero because the LS_ACC for the FLOGI wasn't getting intercepted by FIP. Change to call fcoe_ctlr_els_send when sending any ELS, not just requests. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo1-0/+1
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-02-17[SCSI] fcoe: Only rmmod fcoe.ko if there are no active connectionsRob Love1-2/+16
Currently we're gracefully tearing down each active connection when fcoe.ko is removed. We shouldn't allow the user to destroy connections by removing the module. We should force the user to destroy each connection and then the module can be removed. This patch makes it so a refrerence count on the module is taken each time a fcoe_interface is created. The reference count is dropped when the fcoe_interface is destroyed. This makes it so that module_exit() doesn't get called unless all fcoe_interfaces have been destroyed. This patch leaves the removal of interfaces in the module_exit routine so that if the user does a 'rmmod -f' we'll clean everything up before removing the module. The module_put line was put before the out_putdev goto line because we should only be decrementing the reference count if a fcoe_interface is actually destroyed. If we can't find the netdev or the fcoe_interface then it's assumed that something else has destroyed the fcoe_interface and it would have decremented the reference count at that time. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-17Merge branch 'cpumask-cleanups' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus * 'cpumask-cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus: cpumask: rename tsk_cpumask to tsk_cpus_allowed cpumask: don't recommend set_cpus_allowed hack in Documentation/cpu-hotplug.txt cpumask: avoid dereferencing struct cpumask cpumask: convert drivers/idle/i7300_idle.c to cpumask_var_t cpumask: use modern cpumask style in drivers/scsi/fcoe/fcoe.c cpumask: avoid deprecated function in mm/slab.c cpumask: use cpu_online in kernel/perf_event.c
2009-12-17cpumask: use modern cpumask style in drivers/scsi/fcoe/fcoe.cRusty Russell1-1/+1
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: "James E.J. Bottomley" <James.Bottomley@suse.de> Cc: Robert Love <robert.w.love@intel.com> Cc: Chris Leech <christopher.leech@intel.com> Cc: linux-scsi@vger.kernel.org
2009-12-12[SCSI] fcoe, libfc: adds enable/disable for fcoe interfaceVasu Dev1-2/+108
This is to allow fcoemon util to enable or disable a fcoe interface according to DCB link state change. Adds sysfs module param enable and disable for this and also updates existing other module param description to be consistent and more accurate since older description had double "fcoe" word with less meaningful netdev reference to user space. Adds code to ignore redundant fc_lport_enter_reset handling for a already disabled fcoe interface by checking LPORT_ST_DISABLED or LPORT_ST_LOGO states, this also prevents lport state transition on link flap on a disabled interface. Above changes required lport state transition to get out of disabled or logo state on call to fc_fabric_login. Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-10[SCSI] fcoe: Use LLD's WWPN and WWNN for lport if LLD supports ndo_fcoe_get_wwnYi Zou1-2/+23
If the LLD wants its own WWNN/WWPN to be used, it should implement the netdev_ops.ndo_fcoe_get_wwn(). If that is the case, we query the LLD and use the queried WWNN/WWPN from the LLD. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe, libfc: add get_lesb() to allow LLD to fill the link error ↵Yi Zou1-0/+34
status block (LESB) Add a member function pointer as get_lesb to libfc_function_template so LLD can fill the LESB based on its own statistics. For fcoe, it fills the LESB as a fcoe_fc_els_lesb struct according to FC-BB-5. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: allow SCSI-FCP to be processed directly in softirq contextChris Leech1-110/+135
Allow FCP frames to bypass the FCoE receive processing threads and handle them directly in softirq context, if they are received on the correct CPU. This preserves the queuing to threads for scaling out receive processing to multiple CPUs, but allows FCoE-aware multi-queue network drivers that direct frames to the originating CPUs to handle FCP processing with less scheduling latency. Only FCP is handled directly, because libfc makes use of mutexes in ELS handling routines. The bulk of this change is just moving the FCoE receive processing out of the receive thread function, leaving behind just the thread and queue management. The interesting bits are in fcoe_rcv() Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc fcoe: increase ELS and CT timeoutsJoe Eykholt1-1/+1
The FC-LS spec. says ELS timeouts should be 2 x R_A_TOV. The FC-GS spec. says CT timeouts should be 3 x R_A_TOV. We've been using E_D_TOV for both of those. Change for all ELS and CT requests except FLOGI, which we leave at 2 seconds (using E_D_TOV). One could argue that R_A_TOV is locally determined until after FLOGI succeeds. This does change FLOGI for vports which becomes FDISC. This does not change the REC/SRR timeout which is 2 seconds. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc, fcoe: fixes for highmem skb linearize panicsChris Leech1-2/+3
There are cases outside of our control that may result in a transmit skb being linearized in dev_queue_xmit. There are a couple of bugs in libfc/fcoe that can result in a panic at that point. This patch contains two fixes to prevent those panics. 1) use fast cloning instead of shared skbs with dev_queue_xmit dev_queue_xmit doen't want shared skbuffs being passed in, and __skb_linearize will BUG if the skb is shared. FCoE is holding an extra reference around the call to dev_queue_xmit, so that when it returns an error code indicating the frame has been dropped it can maintain it's own backlog and retransmit. Switch to using fast skb cloning for this instead. 2) don't append compound pages as > PAGE_SIZE skb fragments fc_fcp_send_data will append pages from a scatterlist to the nr_frags[] if the netdev supports it. But, it's using > PAGE_SIZE compound pages as a single skb_frag. In the highmem linearize case that page will be passed to kmap_atomic to get a mapping to copy out of, but kmap_atomic will only allow access to the first PAGE_SIZE part. The memcpy will keep going and cause a page fault once is crosses the first boundary. If fc_fcp_send_data uses linear buffers from the start, it calls kmap_atomic one PAGE_SIZE at a time. That same logic needs to be applied when setting up skb_frags. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: Fix using VLAN ID in creating lport's WWWN/WWPNYi Zou1-2/+9
If the underlying netdev is a VLAN device, make sure the VLAN ID is integrated into the WWNN/WWPN name generation. Also added/updated the comments to reflect this change. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: Fix setting lport's WWNN/WWPN to use san mac addressYi Zou1-2/+2
We are still using netdev->dev_addr to generate lport's WWNN/WWPN even if the LLD has support for NETDEV_HW_ADDR_T_SAN. Instead, we should just use the fip->ctl_src_addr, which is the NETDEV_HW_ADDR_T_SAN if LLD supports it or it is just the netdev->dev_addr if it does not. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: Fix getting san mac for VLAN interfaceYi Zou1-1/+4
Make sure we are get the SAN MAC address from the real netdev if the input netdev is a VLAN device. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: Fix checking san mac addressYi Zou1-1/+1
This was fixed before in 7a7f0c7 but it's introduced again recently. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfcoe: fcoe: simplify receive FLOGI responseJoe Eykholt1-10/+5
There was a locking problem where the fip->lock was held during the call to update_mac(). The rtnl_lock() must be taken before the fip->lock, not the other way around. This fixes that. Now that fcoe_ctlr_recv_flog() is called only from the response handler to a FLOGI request, some checking can be eliminated. Instead of calling update_mac(), just fill in the granted_mac address for the passed-in frame (skb). Eliminate the passed-in source MAC address since it is also in the skb. Also, in fcoe, call fcoe_set_src_mac() directly instead of going thru the fip function pointer. This will generate less code. Then, since fip isn't needed for LOGO response, use lport as the arg. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: add check to fail gracefully in bonding modejohn fastabend1-1/+9
This patch adds a check to fail gracefully when the netdevice is bonded. Previously, the error was detected but the stack would continue to load. This resulted in a partially enabled fcoe intance and errors when the fcoe instance was destroy. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: remove extra function decalrationsYi Zou1-3/+0
Remove the two extra function decalartions in fcoe.c. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: Formatting cleanups and commentingRobert Love1-333/+389
Added kernel-doc comment blocks to all structures and functions. Renamed fc_lport instances rom lp to lport to be inline with our naming convention. Renamed all misnamed net_device instances to netdev to be inline with our naming convention. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc, fcoe: Add FC passthrough supportSteve Ma1-0/+4
This is the Open-FCoE implementation of the FC passthrough support via bsg interface. Passthrough support is added to both N_Ports and VN_Ports. Signed-off-by: Steve Ma <steve.ma@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: vport symbolic name supportChris Leech1-0/+33
Allow a vport specific string to be appended to the port symbolic name. The new symbolic name is sent to the name server after it is set. This currently messes with libhbalinux, which is looking for the fcoe "fcoe <ver> over <ethX>" string and expects whatever comes after the "over" to be a network interface name only. Adds an EXPORT_SYMBOL to libfc for fc_frame_alloc_fill, which is needed to allow fcoe to allocate a frame of variable length for the RSPN request. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc: Register Symbolic Node Name (RSNN_NN)Chris Leech1-3/+3
Register the fc_host symbolic name as the symbolic node name with the fabric name server. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: NPIV vport create/destroyChris Leech1-23/+139
Add NPIV vport create and destroy handlers and register them with the FC transport. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: add a separate scsi transport template for NPIV vportsChris Leech1-7/+47
Right now it's exactly the same as the physical port template, and there is no way to create a port on anything other than the netdev. When the vport_create entry point gets hooked up it will create lports on top of vport devices, which will use this. Rename scsi_transport_fcoe_sw to fcoe_transport_template to be more clear with naming now that there are two templates. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfcoe, fcoe: libfcoe NPIV supportChris Leech1-19/+128
The FIP code in libfcoe needed several changes to support NPIV 1) dst_src_addr needs to be managed per-n_port-ID for FPMA fabrics with NPIV enabled. Managing the MAC address is now handled in fcoe, with some slight changes to update_mac() and a new get_src_addr() function pointer. 2) The libfc elsct_send() hook is used to setup FCoE specific response handlers for FIP encapsulated ELS exchanges. This lets the FCoE specific handling know which VN_Port the exchange is for, and doesn't require tracking OX_IDs. It might be possible to roll back to the full FIP frame in these, but for now I've just stashed the contents of the MAC address descriptor in the skb context block for later use. Also, because fcoe_elsct_send() just passes control on to fc_elsct_send(), all transmits still come through the normal frame_send() path. 3) The NPIV changes added a mutex hold in the keep alive sending, the lport mutex is protecting the vport list. We can't take a mutex from a timer, so move the FIP keep alive logic to the link work struct. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc: changes to libfc_host_alloc to consolidate initialization with ↵Chris Leech1-5/+3
allocation I'd like to keep basic initialization together with allocation, which means this can't just be a tail-call to scsi_host_alloc. This is needed to create a generic libfc host allocation routine for NPIV VN_Ports, which will share the exchange ID space (through sharing exchange manager structures) with the parent lport. In order to clone the exchange manager list when the lport is allocated, the list head must be initialized earlier. Also, update fnic to use the libfc_host_alloc so that later changes do not break it. (contribution by Joe Eykholt) Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe, libfc: fix an libfc issue with queue ramp down in libfcVasu Dev1-1/+1
The cmd_per_lun value is used by scsi-ml as fall back lowest queue_depth value but in case of libfc cmd_per_lun is set to same value as max queue_depth = 32. So this patch reduces cmd_per_lun value to 3 and configures each lun with default max queue_depth 32 in fc_slave_alloc. Signed-off-by: Vasu Dev <vasu.dev@intel.com> Acked-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: Call ndo_fcoe_enable/disable to turn FCoE feature on/off in LLDYi Zou1-0/+18
Calls ndo_fcoe_enabled() of the associated netdev upon creating the FCoE instance to make sure LLD has all necessary resources allocated and setup properly before passing FCoE traffic. Similarly, calls ndo_fcoe_disable() upon destroying the FCoE instance on the associated netdev to allow the LLD to release all allocated resources for FCoE. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: Use NETIF_F_FCOE_MTU flag to set up max frame size (lport->mfs)Yi Zou1-2/+8
Add a define of FCOE_MTU as 2158 bytes and use FCOE_MTU when the LLD is found to support NETIF_F_FCOE_MTU. The lport->mfs is then calculated out of the 2158 FCOE_MTU. Otherwise, we stick with the netdev->mtu, i.e., LAN MTU. Also, change the notification on NETDEV_CHANGEMTU event to bypass changing mfs when LAN MTU is changed if NETIF_F_FCOE_MTU is supported. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: initialize return value in fcoe_destroyMike Christie1-1/+1
When doing echo ethX > /sys..../destroy I am getting errors when the tear down succeeds. It looks like the reason for this is because the rc var is not getting set when the destruction works. This just sets it to zero. Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] fcoe: remove redundant checking of netdev->netdev_opsYi Zou1-2/+2
Remove the redundant checking of netdev->netdev_ops as it will never be NULL. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-10[SCSI] fcoe: flush per-cpu thread work when destroying interfaceJoe Eykholt1-2/+40
This fixes one cause of an occational problem when unloading libfc where the exchange manager pool doesn't have all items freed. The existing WARN_ON(mp->total_exches <= 0) isn't hit. However, note that total_exches is decremented when the exchange is completed, and it can be held with a refcnt for a while after that. I'm not sure what the offending exchange is, but I suspect it is an incoming request, because outgoing state machines should be all stopped at this point. Note that although receive is stopped before the exchange manager is freed, there could still be active threads handling received frames. This patch flushes the queues by allocating a new skb and sending it through, and have the thread handle this new skb specially. This is similar to the way the work queues are flushed now by putting work items in them and waiting until they make it through the queue. An skb->destructor function is used to inform us of the completion of the flush, and the fr_dev() is left NULL to indicate to fcoe_percpu_receive_thread() that the skb should be just freed. There's already a check for the lp being NULL which prints a message. We skip printing the message if the destructor is for flushing. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-10[SCSI] fcoe: use rtnl mutex in place of hostlist lockChris Leech1-26/+11
This just cuts down on the number of locks we're dealing with, and eliminates the need to take another lock in the netdev notifier. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-10[SCSI] fcoe: Fix module ref count bug by adding NETDEV UNREGISTER handlingChris Leech1-121/+65
Fixes reference counting on fcoe_instance and net_device, and adds NETDEV_UNREGISTER notifier handling so that you can unload network drivers. FCoE no longer increments the module use count for the network driver. On an NETDEV_UNREGISTER event, destroying the FCoE instance is deferred to a workqueue context to avoid RTNL deadlocks. Based in part by an earlier patch from John Fastabend John's patch description: Currently, the netdev module ref count is not decremented with module_put() when the module is unloaded while fcoe instances are present. To fix this removed reference count on netdev module completely and added functionality to netdev event handling for NETDEV_UNREGISTER events. This allows fcoe to remove devices cleanly when the netdev module is unloaded so we no longer need to hold a reference count for the netdev module. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-10[SCSI] fcoe: move the host-list add/remove to keep out VN_PortsChris Leech1-12/+19
We only want the FCoE create and destroy routines to deal with top level N_Ports, the VN_Ports are tracked on the vport list (see scsi_transport_fc). Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-10[SCSI] fcoe: add mutex to protect create and destroyChris Leech1-1/+39
Rather than rely on the hostlist_lock to be held while creating exchange managers, serialize fcoe instance creation and destruction with a mutex. This will allow the hostlist addition to be moved out of fcoe_if_create(), which will simplify NPIV support. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-10[SCSI] fcoe: split out per interface setupChris Leech1-119/+148
fcoe_netdev_config() is called during initialization of a libfc instance. Much of what was there only needs to be done once for each net_device. The same goes for the corresponding cleanup. The FIP controller initialization is moved to interface creation time. Otherwise it will keep getting re-initialized for every VN_Port once NPIV is enabled. fcoe_if_destroy() has some reordering to deal with the changes. Receives are not stopped until after fcoe_interface_put() is called, but transmits must be stopped before. So there is some care to stop libfc transmits and the transmit backlog timer, then call fcoe_interface_put which will stop receives and cleanup the FIP controller, then the receive queues can be cleaned and the port freed. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-10[SCSI] fcoe: fcoe_interface create, destroy and refcountingChris Leech1-19/+78
Up to this point the fcoe_instance structure was simply kzalloc/kfreed. This patch introduces create and destroy functions as well as kref based reference counting. The create function will grow as the initialization code is moved there. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-10[SCSI] fcoe: remove fcoe_interface->priv pointerChris Leech1-2/+0
The priv pointer is no longer needed, and once NPIV is enabled fcoe_interface:fc_lport becomes a one-to-many relationship. Remove the single pointer. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>