Move the definition of the global variable fcoe_debug_logging
from fcoe.h to fcoe.c. Avoid that sparse complains about missing
declarations for local functions or variables by declaring these
static.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Reviewed-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This is a regression introduced by commit
1ff9918b The else statement here is breaking
the initiator logic of allocating xid from the offloaded em xid pool for READ
I/O only to use DDP, as shown by the snippet of trace below, where the WRITE
is using xid 0x5 from the offloaded em xid pool:

Protocol VID Len S_ID        D_ID     OX_ID  RX_ID  Summary
..
*FCP     228 96  0b.08.01 -> 01.0f.00 0x0005 0xffff SCSI: Write(10) LUN: 0x00
 FCP     228 76  01.0f.00 -> 0b.08.01 0x0005 0x828d XFER_RDY
...

The bug is in the else statement, for both initiator and target, the
new command will have FC frame header bit 23 (FC_FC_EX_CTX) cleared as it was
originated from the initiator. Also, this is assuming the frame header is
already filled up, which is only true for target since for initiator, this is a
new frame and oem_match gets called when em tries get xid for this i/o before
it is filled up and sent out.

The fix is to check if there is a fc_fcp_pkt associated w/ this frame from
fr_fsp(fp), since fr_fsp(fp) is NULL for tcm_fc target and non-I/O frame in
initiator. This should also return true for target only if it is an
FC_RCTL_DD_UNSOL_CMD and rx_id is not allocated.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

skb_linearize already has a check for skb_is_nonlinear,
there is no need to duplicate the check in fcoe.c. This
patch simply removes the unnecessary check and calls
skb_linearize unconditionally.
Reported-by: Npatrick kelle <patrick.kelle81@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Acked-by: Npatrick kelle <patrick.kelle81@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use DCB notifiers to set the skb priority to allow packets
to be steered and tagged correctly over DCB enabled drivers
that setup traffic classes.

This allows queue_mapping() routines to be removed in these
drivers that were previously inspecting the ethertype of
every skb to mark FCoE/FIP frames.
Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The error exit path leaks preempt count. Add the missing put_cpu().
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NYi Zou <yi.zou@intel.com>
Cc: stable@kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Adds more cases to do flogi retry, now also retry
on getting bad response due to either no ELS response
or flogi response payload length not large enough.
In those cases flogi was not retried and that
was leaving lport offline.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Except for obtaining the netdev from lport, fcoe_get_lesb is the common code
for the LLDs.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Acked-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Currently fcoe_ddp_min doesn't have default value
so by default not used, so setting up default value
as 4k as this works better by avoiding overhead
of programing DDP for small IOs.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use real dev in case it has HW vlan acceleration
support since in this case the real dev would
do needed vlan processing, this way unnecessary
vlan layer processing avoided and it gives
slightly better IOPS with 512B size IOs.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Since fcoe_percpu_thread_create() creates percpu kthread, it makes sense
to use kthread_create_on_node() to get proper NUMA affinity for kthread
stack.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch does several things:
- introduces __ethtool_get_settings which is called from ethtool code and
  from drivers as well. Put ASSERT_RTNL there.
- dev_ethtool_get_settings() is replaced by __ethtool_get_settings()
- changes calling in drivers so rtnl locking is respected. In
  iboe_get_rate was previously ->get_settings() called unlocked. This
  fixes it. Also prb_calc_retire_blk_tmo() in af_packet.c had the same
  problem. Also fixed by calling __dev_get_by_index() instead of
  dev_get_by_index() and holding rtnl_lock for both calls.
- introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create()
  so bnx2fc_if_create() and fcoe_if_create() are called locked as they
  are from other places.
- use __ethtool_get_settings() in bonding code
Signed-off-by: NJiri Pirko <jpirko@redhat.com>

v2->v3:
	-removed dev_ethtool_get_settings()
	-added ASSERT_RTNL into __ethtool_get_settings()
	-prb_calc_retire_blk_tmo - use __dev_get_by_index() and lock
	 around it and __ethtool_get_settings() call
v1->v2:
        add missing export_symbol
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com> [except FCoE bits]
Acked-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It was pointed out by 'make versioncheck' that some includes of
linux/version.h are not needed in drivers/scsi/.
This patch removes them.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The rtnl cannot be held durrng the fcoe_interface_put.
If it is the last reference on the fcoe_interface the
fcoe_ctlr_destroy will be called as a part of the
cleanup, ultimately calling cancel_work_sync(&fip->recv_work);

If we are processing a flogi response we will be in
the recv_work context and we will lock the rtnl to
add a new unicast MAC address. This is how the deadlock
can occur.

The fix is simply to move the rtnl_lock/unlock into
fcoe_interface_cleanup so that it can be unlocked before
fcoe_interface_put is called.

Here is the lockdep report:

Jul 21 11:26:35 bubba [  223.870702]
ul 21 11:26:35 bubba [  223.870704] =======================================================
Jul 21 11:26:35 bubba [  223.871255] [ INFO: possible circular locking dependency detected ]
Jul 21 11:26:35 bubba [  223.871530] 3.0.0-rc7+ #1
Jul 21 11:26:35 bubba [  223.871797] -------------------------------------------------------
Jul 21 11:26:35 bubba [  223.872072] lockdeptest.sh/3464 is trying to acquire lock:
Jul 21 11:26:35 bubba [  223.872345]  ((&fip->recv_work)
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba , at:
Jul 21 11:26:35 bubba [<ffffffff810531f1>] wait_on_work+0x0/0xbd
Jul 21 11:26:35 bubba [  223.873022]
Jul 21 11:26:35 bubba [  223.873023] but task is already holding lock:
Jul 21 11:26:35 bubba [  223.873555]  (rtnl_mutex
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba , at:
Jul 21 11:26:35 bubba [<ffffffff813e8233>] rtnl_lock+0x12/0x14
Jul 21 11:26:35 bubba [  223.874229]
Jul 21 11:26:35 bubba [  223.874230] which lock already depends on the new lock.
Jul 21 11:26:35 bubba [  223.874231]
Jul 21 11:26:35 bubba [  223.875032]
Jul 21 11:26:35 bubba [  223.875033] the existing dependency chain (in reverse order) is:
Jul 21 11:26:35 bubba [  223.875573]
Jul 21 11:26:35 bubba [  223.875573] -> #1
Jul 21 11:26:35 bubba (rtnl_mutex
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba :
Jul 21 11:26:35 bubba [  223.876301]
Jul 21 11:26:35 bubba [<ffffffff8106c14a>] lock_acquire+0xd2/0xf7
Jul 21 11:26:35 bubba [  223.876645]
Jul 21 11:26:35 bubba [<ffffffff8151d975>] __mutex_lock_common+0x47/0x30d
Jul 21 11:26:35 bubba [  223.876991]
Jul 21 11:26:35 bubba [<ffffffff8151dd36>] mutex_lock_nested+0x3b/0x40
Jul 21 11:26:35 bubba [  223.877334]
Jul 21 11:26:35 bubba [<ffffffff813e8233>] rtnl_lock+0x12/0x14
Jul 21 11:26:35 bubba [  223.877675]
Jul 21 11:26:35 bubba [<ffffffffa003d5a0>] fcoe_update_src_mac+0x2b/0x80 [fcoe]
Jul 21 11:26:35 bubba [  223.878022]
Jul 21 11:26:35 bubba [<ffffffffa003d698>] fcoe_flogi_resp+0x5e/0x79 [fcoe]
Jul 21 11:26:35 bubba [  223.878366]
Jul 21 11:26:35 bubba [<ffffffffa001566f>] fc_exch_recv+0x7f5/0x9da [libfc]
Jul 21 11:26:35 bubba [  223.878713]
Jul 21 11:26:35 bubba [<ffffffffa00327d8>] fcoe_ctlr_recv_work+0x71f/0x10dc [libfcoe]
Jul 21 11:26:35 bubba [  223.879258]
Jul 21 11:26:35 bubba [<ffffffff81053761>] process_one_work+0x1d7/0x347
Jul 21 11:26:35 bubba [  223.879601]
Jul 21 11:26:35 bubba [<ffffffff81054ade>] worker_thread+0xf8/0x17c
Jul 21 11:26:35 bubba [  223.879944]
Jul 21 11:26:35 bubba [<ffffffff81058184>] kthread+0x7d/0x85
Jul 21 11:26:35 bubba [  223.880287]
Jul 21 11:26:35 bubba [<ffffffff81526414>] kernel_thread_helper+0x4/0x10
Jul 21 11:26:35 bubba [  223.880634]
Jul 21 11:26:35 bubba [  223.880635] -> #0
Jul 21 11:26:35 bubba ((&fip->recv_work)
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba :
Jul 21 11:26:35 bubba [  223.881357]
Jul 21 11:26:35 bubba [<ffffffff8106b93e>] __lock_acquire+0xb1d/0xe2c
Jul 21 11:26:35 bubba [  223.881695]
Jul 21 11:26:35 bubba [<ffffffff8106c14a>] lock_acquire+0xd2/0xf7
Jul 21 11:26:35 bubba [  223.882033]
Jul 21 11:26:35 bubba [<ffffffff81053241>] wait_on_work+0x50/0xbd
Jul 21 11:26:35 bubba [  223.882378]
Jul 21 11:26:35 bubba [<ffffffff81053b32>] __cancel_work_timer+0xb6/0xf4
Jul 21 11:26:35 bubba [  223.882718]
Jul 21 11:26:35 bubba [<ffffffff81053b8a>] cancel_work_sync+0xb/0xd
Jul 21 11:26:35 bubba [  223.883057]
Jul 21 11:26:35 bubba [<ffffffffa00317e6>] fcoe_ctlr_destroy+0x1d/0x67 [libfcoe]
Jul 21 11:26:35 bubba [  223.883399]
Jul 21 11:26:35 bubba [<ffffffffa003e51e>] fcoe_interface_release+0x21/0x45 [fcoe]
Jul 21 11:26:35 bubba [  223.883940]
Jul 21 11:26:35 bubba [<ffffffff811fbbe6>] kref_put+0x43/0x4d
Jul 21 11:26:35 bubba [  223.884280]
Jul 21 11:26:35 bubba [<ffffffffa003ebba>] fcoe_interface_put+0x17/0x19 [fcoe]
Jul 21 11:26:35 bubba [  223.884624]
Jul 21 11:26:35 bubba [<ffffffffa003f2a6>] fcoe_interface_cleanup+0x188/0x193 [fcoe]
Jul 21 11:26:35 bubba [  223.885163]
Jul 21 11:26:35 bubba [<ffffffffa003f303>] fcoe_destroy+0x52/0x72 [fcoe]
Jul 21 11:26:35 bubba [  223.885502]
Jul 21 11:26:35 bubba [<ffffffffa00340a4>] fcoe_transport_destroy+0xab/0x110 [libfcoe]
Jul 21 11:26:35 bubba [  223.886045]
Jul 21 11:26:35 bubba [<ffffffff81056153>] param_attr_store+0x43/0x62
Jul 21 11:26:35 bubba [  223.886385]
Jul 21 11:26:35 bubba [<ffffffff8105602d>] module_attr_store+0x21/0x25
Jul 21 11:26:35 bubba [  223.886728]
Jul 21 11:26:35 bubba [<ffffffff8114c23d>] sysfs_write_file+0x103/0x13f
Jul 21 11:26:35 bubba [  223.887068]
Jul 21 11:26:35 bubba [<ffffffff810f3e7b>] vfs_write+0xa7/0xfa
Jul 21 11:26:35 bubba [  223.887406]
Jul 21 11:26:35 bubba [<ffffffff810f4073>] sys_write+0x45/0x69
Jul 21 11:26:35 bubba [  223.887742]
Jul 21 11:26:35 bubba [<ffffffff815252bb>] system_call_fastpath+0x16/0x1b
Jul 21 11:26:35 bubba [  223.888083]
Jul 21 11:26:35 bubba [  223.888084] other info that might help us debug this:
Jul 21 11:26:35 bubba [  223.888085]
Jul 21 11:26:35 bubba [  223.888879]  Possible unsafe locking scenario:
Jul 21 11:26:35 bubba [  223.888881]
Jul 21 11:26:35 bubba [  223.889411]        CPU0                    CPU1
Jul 21 11:26:35 bubba [  223.889683]        ----                    ----
Jul 21 11:26:35 bubba [  223.889955]   lock(
Jul 21 11:26:35 bubba rtnl_mutex
Jul 21 11:26:35 bubba );
Jul 21 11:26:35 bubba [  223.890349]                                lock(
Jul 21 11:26:35 bubba (&fip->recv_work)
Jul 21 11:26:35 bubba );
Jul 21 11:26:35 bubba [  223.890751]                                lock(
Jul 21 11:26:35 bubba rtnl_mutex
Jul 21 11:26:35 bubba );
Jul 21 11:26:35 bubba [  223.891154]   lock(
Jul 21 11:26:35 bubba (&fip->recv_work)
Jul 21 11:26:35 bubba );
Jul 21 11:26:35 bubba [  223.891549]
Jul 21 11:26:35 bubba [  223.891550]  *** DEADLOCK ***
Jul 21 11:26:35 bubba [  223.891551]
Jul 21 11:26:35 bubba [  223.892347] 6 locks held by lockdeptest.sh/3464:
Jul 21 11:26:35 bubba [  223.892621]  #0:
Jul 21 11:26:35 bubba (&buffer->mutex
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba , at:
Jul 21 11:26:35 bubba [<ffffffff8114c171>] sysfs_write_file+0x37/0x13f
Jul 21 11:26:35 bubba [  223.893359]  #1:
Jul 21 11:26:35 bubba (s_active
Jul 21 11:26:35 bubba ){++++.+}
Jul 21 11:26:35 bubba , at:
Jul 21 11:26:35 bubba [<ffffffff8114c21c>] sysfs_write_file+0xe2/0x13f
Jul 21 11:26:35 bubba [  223.894094]  #2:
Jul 21 11:26:35 bubba (param_lock
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba , at:
Jul 21 11:26:35 bubba [<ffffffff81056146>] param_attr_store+0x36/0x62
Jul 21 11:26:35 bubba [  223.894835]  #3:
Jul 21 11:26:35 bubba (ft_mutex
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba , at:
Jul 21 11:26:35 bubba [<ffffffffa0034017>] fcoe_transport_destroy+0x1e/0x110 [libfcoe]
Jul 21 11:26:35 bubba [  223.895574]  #4:
Jul 21 11:26:35 bubba (fcoe_config_mutex
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba , at:
Jul 21 11:26:35 bubba [<ffffffffa003f2c9>] fcoe_destroy+0x18/0x72 [fcoe]
Jul 21 11:26:35 bubba [  223.896314]  #5:
Jul 21 11:26:35 bubba (rtnl_mutex
Jul 21 11:26:35 bubba ){+.+.+.}
Jul 21 11:26:35 bubba , at:
Jul 21 11:26:35 bubba [<ffffffff813e8233>] rtnl_lock+0x12/0x14
Jul 21 11:26:35 bubba [  223.897047]
Jul 21 11:26:35 bubba [  223.897048] stack backtrace:
Jul 21 11:26:35 bubba [  223.897578] Pid: 3464, comm: lockdeptest.sh Not tainted 3.0.0-rc7+ #1
Jul 21 11:26:35 bubba [  223.897853] Call Trace:
Jul 21 11:26:35 bubba [  223.898128]  [<ffffffff81068e16>] print_circular_bug+0x1f8/0x209
Jul 21 11:26:35 bubba [  223.898416]  [<ffffffff8106b93e>] __lock_acquire+0xb1d/0xe2c
Jul 21 11:26:35 bubba [  223.898699]  [<ffffffff810531f1>] ? wait_on_cpu_work+0xe6/0xe6
Jul 21 11:26:35 bubba [  223.898982]  [<ffffffff8106c14a>] lock_acquire+0xd2/0xf7
Jul 21 11:26:35 bubba [  223.899263]  [<ffffffff810531f1>] ? wait_on_cpu_work+0xe6/0xe6
Jul 21 11:26:35 bubba [  223.899547]  [<ffffffff8104a097>] ? mod_timer+0x8f/0x98
Jul 21 11:26:35 bubba [  223.899827]  [<ffffffff81053241>] wait_on_work+0x50/0xbd
Jul 21 11:26:35 bubba [  223.900108]  [<ffffffff810531f1>] ? wait_on_cpu_work+0xe6/0xe6
Jul 21 11:26:35 bubba [  223.900390]  [<ffffffff81053b32>] __cancel_work_timer+0xb6/0xf4
Jul 21 11:26:35 bubba [  223.900671]  [<ffffffff81053b8a>] cancel_work_sync+0xb/0xd
Jul 21 11:26:35 bubba [  223.900953]  [<ffffffffa00317e6>] fcoe_ctlr_destroy+0x1d/0x67 [libfcoe]
Jul 21 11:26:35 bubba [  223.901237]  [<ffffffffa003e51e>] fcoe_interface_release+0x21/0x45 [fcoe]
Jul 21 11:26:35 bubba [  223.901522]  [<ffffffffa003e4fd>] ? fcoe_enable+0x6b/0x6b [fcoe]
Jul 21 11:26:35 bubba [  223.901803]  [<ffffffff811fbbe6>] kref_put+0x43/0x4d
Jul 21 11:26:35 bubba [  223.902083]  [<ffffffffa003ebba>] fcoe_interface_put+0x17/0x19 [fcoe]
Jul 21 11:26:35 bubba [  223.902367]  [<ffffffffa003f2a6>] fcoe_interface_cleanup+0x188/0x193 [fcoe]
Jul 21 11:26:35 bubba [  223.902653]  [<ffffffff8151dd36>] ? mutex_lock_nested+0x3b/0x40
Jul 21 11:26:35 bubba [  223.902939]  [<ffffffffa003f303>] fcoe_destroy+0x52/0x72 [fcoe]
Jul 21 11:26:35 bubba [  223.903223]  [<ffffffffa00340a4>] fcoe_transport_destroy+0xab/0x110 [libfcoe]
Jul 21 11:26:35 bubba [  223.903508]  [<ffffffff81056153>] param_attr_store+0x43/0x62
Jul 21 11:26:35 bubba [  223.903792]  [<ffffffff8105602d>] module_attr_store+0x21/0x25
Jul 21 11:26:35 bubba [  223.904075]  [<ffffffff8114c23d>] sysfs_write_file+0x103/0x13f
Jul 21 11:26:35 bubba [  223.904357]  [<ffffffff810f3e7b>] vfs_write+0xa7/0xfa
Jul 21 11:26:35 bubba [  223.904642]  [<ffffffff810f51d6>] ? fget_light+0x35/0x96
Jul 21 11:26:35 bubba [  223.904923]  [<ffffffff810f4073>] sys_write+0x45/0x69
Jul 21 11:26:35 bubba [  223.905204]  [<ffffffff815252bb>] system_call_fastpath+0x16/0x1b
Jul 21 11:26:36 bubba [  223.964438] ixgbe 0000:05:00.0: eth3: detected SFP+: 5
Jul 21 11:26:37 bubba [  225.196702] ixgbe 0000:05:00.0: eth3: NIC Link is Up 10 Gbps, Flow Control: None
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Reviewed-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Export fcoe_get_wwn, fcoe_validate_vport_create and fcoe_wwn_to_str so that all
LLDs can use these common function.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Robert Love <robert.w.love@intel.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: devel@open-fcoe.org
Cc: linux-scsi@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Cleanup to:

- have selection for all types of frames, not just FCP.
- remove redundant cpu_online check once fcoe_select_cpu called
  as this is not required since later code flow check for offlined
  cpu.
- Simplify fcoe_select_cpu() by removing unnecessary checks to
  skip curr_cpu, this also fixes possibly infinite loop in case
  of curr_cpu is the only cpu while iterating in the loop.

This cleanup mainly applies to target as incoming request are
mostly for target, therefore Kiran has verified the patch
with target also.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NKiran Patil <kiran.patil@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use pending queue to retry FIP frame in case its tx
fails and use common pending queue for both fcoe
and fip frames using fcoe_port_send.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Drop the rx frame having xid with wrong cpu info
or received with xid  not matching to our xid.

Not dropping such frame is causing panic as
that causes accessing data struct beyond their
bounds.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

There is no need to cache the ptype in fcoe_rcv_info struct as it is never
used anywhere.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

When NPIV port destroy handler is called it does not do all the cleanup
required for the given NPIV port. This was happening as some of the
lport cleanup moved to fcoe_interface_cleanup() routine, which is not
called as part of the vport delete process.

This patch rearranges the sequence in which the fcoe_if_destory() and
fcoe_interface_cleanup() functions are being called from various places
in the code. It now matches the sequence they are constructed during the
create process for both N_Port as well as NPIV port.
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NNeerav Parikh <Neerav.Parikh@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

[SCSI] fcoe: Amends previous patch, Round-robin based selection of CPU for post processing of incoming request for FCoE target

Problem: Selection of RX queue on target is based on RX-ID. FCoE used
8 Net Rx queues.  HW post the packets based on rx_id %
num_rx_queue. Due to this has based filtering, only one CPU is busy
servicing incoming request including post-processing of incoming
request. This is gating factor because

1. Only one CPU is utilized 100% while others CPUs are not used at all.

2. CPU which received request assign "sequence' by selecting exchange
   from per CPU pool (num_ddp_context / num_online_cpus,
   approxi.). Due to which if if rate of incoming request is higher
   than rate of servicing request, existing code path end of sending
   "BUSY" response (SAM_STAT_BUSY because unable to allocate
   exchange).

Fix: Fan-out incoming request to all other CPUs excluding the CPU
which is receiving all incoiming request. This path also addresses,
selecting same CPU based on rx_id from received frame for completion
of the request such as "releasing exchange to the per CPU Pool". This
fix is applicable for FCoE target since initiator code path already
takes care of selecting CPU to complete post-processing of request
once OX_ID is assigned.

Notes: N/A

Dependencines: N/A
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Problem: Earlier mechanism of selection of CPU was, to select the same CPU
which has received incoming request. Hence in case of rx_id = 0xFFFF,
request was always posted to same NetRx queue, hence only 1 CPU is utilized
for handling the command. It was also causing problem of "running out of
exchanges from per CPU pool of exchanges (in case of DDP offload)

Fix: Implemented new algo. to select CPU for post-processing of
incoming commands when rx_id is unknown. This is simple Round robin
algo. for CPU selection.

Notes/Dependencies: N/A
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Problem: When initiator sends write command to target, target tries to
assign new sequence. It allocates new exchangeID (RX_ID)
always from non-offloaded pool (Non-offload EMA)

Fix: Enhanced fcoe_oem_match routine to look at F_CTL flags and if it
is exchange responder and command type is WRITEDATA, then function
returns TRUE instead of FALSE. This function is used to determine
which pool to use (offload pool of exchange is used only if this
function returns TRUE).

Technical Notes: N/A
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Add ddp_target() support to the Open-FCoE sw fcoe hba driver (fcoe.ko).
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch adds a validation step before allowing creation of a new NPIV port.
It checks whether the WWPN passed for the new NPIV port to be created is unique
for the given physical port.
Signed-off-by: NNeerav Parikh <Neerav.Parikh@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>

Currently fcoe interface cleanup is done after ndo_fcoe_disable
and that prevents logoff going out to the peer, so this patch
moves all netdev cleanup and its releasing inside
fcoe_interface_cleanup to have log off before ndo_fcoe_disable
disables the fcoe.

This patch also fixes asymmetric rtnl locking around fcoe_if_destroy,
as currently this function requires rtnl held by its caller
and then have this func drops the lock, instead now don't have
any processing under rtnl inside fcoe_if_destroy, this required
moving few func to get build working again.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

The check of module state being MODULE_STATE_LIVE is no longer needed for the
individual fcoe transport driver, e.g., fcoe.ko, as sysfs entries now go to
libfcoe now, if it reaches fcoe.ko, it has to be already registered. The module
state check for libfcoe will guard the possible race condition of sysfs being
writable before module_init function is called and after module_exit.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

These checks were initially added to avoid a lockdep
false positive when dealing with the s_active, rtnl
and fcoe_config_mutex mutexes. Recently the create,
destroy, enable and disable sysfs entries were moved
from fcoe.ko to libfcoe.ko. With this change the mutex
usage was shuffled around and the lockdep false
positive stopped happening. We can now remove these
checks.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

This makes sure that when a driver calls the ethtool's
get/set_settings() callback of another driver, the data passed to it
is clean. This guarantees that speed_hi will be zeroed correctly if
the called callback doesn't explicitely set it: we are sure we don't
get a corrupted speed from the underlying driver. We also take care of
setting the cmd field appropriately (ETHTOOL_GSET/SSET).

This applies to dev_ethtool_get_settings(), which now makes sure it
sets up that ethtool command parameter correctly before passing it to
drivers. This also means that whoever calls dev_ethtool_get_settings()
does not have to clean the ethtool command parameter. This function
also becomes an exported symbol instead of an inline.

All drivers visible to make allyesconfig under x86_64 have been
updated.
Signed-off-by: NDavid Decotigny <decot@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Check for bonding master and refuse to use that.
Signed-off-by: NJiri Pirko <jpirko@redhat.com>
Acked-by: NRobert Love <robert.w.love@intel.com>
Acked-by: NJames Bottomley <James.Bottomley@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reset using "fcoeadm -r" also needs to restart FIP before
doing libfc lport reset, this is needed for new switch firmware
requiring FIP solicitation before doing FLOGI again during reset.
So this patch does this by doing fcoe_ctlr_link_down and then
fcoe_ctlr_link_up to reset the interface.

The fcoe_ctlr_link_down call path also does lport reset
and then fcoe_ctlr_link_up re-starts the fabric login after
doing FIP solicitation first to get reset feature working
again.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Negate has higher precedence than bitwise AND.  FCPHF_CRC_UNCHECKED is
0x1 so the original code is equivalent to: if (!fr_flags(fp)) { ...
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

EM anchors list initialization for only master port was not enough to
keep npiv working as described here:-
https://lists.open-fcoe.org/pipermail/devel/2011-January/011063.html

So this patch moves fc_exch_mgr_list_clone to update npiv ports
EMs once EM anchors list initialized.

Also some cleanup, no need to set lport = NULL as that always
get initialized later.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

To facilitate LLDDs to reuse the code, skb queue related functions are moved to
libfcoe, so that both fcoe and bnx2fc drivers can use them. The common structures
fcoe_port, fcoe_percpu_s are moved to libfcoe. fcoe_port will now have an
opaque pointer that points to corresponding driver's interface structure.
Also, fcoe_start_io and fcoe_fc_crc are moved to libfcoe.

As part of this change, fixed fcoe_start_io to return ENOMEM if
skb_clone fails.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

fcoe uses the system_wq to destroy ports and the work items need to be
flushed before the driver is unloaded.  As the work items free the
containing data structure, they can't be flushed directly.  The
workqueue should be flushed instead.

Also, the destruction works can be chained - ie. destruction of a port
may lead to destruction of another port where the work item for the
former queues the work for the latter.  Currently, the depth of chain
can be at most two and fcoe_exit() makes sure everything is complete
by calling flush_scheduled_work() twice.

With commit c8efcc25 (workqueue: allow chained queueing during
destruction), destroy_workqueue() can take care of chained works on
workqueue destruction.  Add and use fcoe_wq instead.  Simply
destroying fcoe_wq on driver unload takes care of flushing.
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Remove the existing sysfs entry points of the fcoe.ko module parameters that
are used to create/destroy/enable/disable an FCoE instance, rather, use the
newly added fcoe transport code to attach itself as an FCoE transport provider
when fcoe.ko gets loaded. There is no functionality change on the logic of
fcoe interacts with upper libfc and lower netdev. The fcoe transport only acts
as thin layer to provide a unified interface for all fcoe transport providers
so all FCoE instances on any network interfaces from all vendors can be
managed through the same Open-FCoE.org's user space tool package, which also
has full DCB support.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Prepare the fcoe to convert it to use the newly added fcoe transport, making
it as the default fcoe transport provider for libfcoe. This patch is to rename
some of the variables to avoid any confusing names later as now there are
several transports in the same file.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Allowing FCoE LOGO followed by CVL in this case prevents
FIP login back to the FCF and then keeps lport offline,
only FIP LOGO and CLV needs to be processed while in
FIP mode, therefore this patch drops FCoE LOGO in FIP mode.

Added fcoe_filter_frames() to filter out above mentioned LOGO
in fcoe rx path along with other existing filtering in code
for bad CRC frames. Adding separate fcoe_filter_frames function
helped with better code indentations and if needed then same
will allow adding more filters at one place in future.

This LOGO drop is added after FCP frames passed up to avoid
any additional checks on fast path for this.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

vports are not grabbing module references but are
releasing them. This causes the module reference count
to decrement too many times and it wraps around past 0.

The solution is to do a module_put() in
fcoe_interface_release() so that the reference is only
released when the fcoe_interface is released. There is a
one-to-one relationship between the N_Port and the
fcoe_interface, so the module reference will only be
dropped when the N_Port is destroyed

To create symetry in the code this patch moves the
try_module_get() call into fcoe_interface_create(). This
means that only the N_Port will grab a reference to the
module when its corresponding fcoe_interface is created.

This patch also makes it so that the fcoe_interface_create()
routine encodes any error codes in the fcoe_interface
pointer returned. This way its caller, fcoe_create(), can
return an accurate error code.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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:
 [<ffffffffa02c39ca>] ? fc_io_compl+0x10a/0x530 [libfc]
 [<ffffffffa02c4962>] fc_fcp_complete_locked+0x72/0x150 [libfc]
 [<ffffffff814c94ab>] ? _spin_unlock_bh+0x1b/0x20
 [<ffffffffa02b98ff>] ? fc_exch_done+0x3f/0x60 [libfc]
 [<ffffffffa02c4a8f>] fc_fcp_retry_cmd+0x4f/0x60 [libfc]
 [<ffffffffa02c6150>] fc_fcp_recv+0x9b0/0xc30 [libfc]
 [<ffffffff8106ba7a>] ? _call_console_drivers+0x4a/0x80
 [<ffffffff8107d5ec>] ? lock_timer_base+0x3c/0x70
 [<ffffffff8107e06b>] ? try_to_del_timer_sync+0x7b/0xe0
 [<ffffffffa02b9dcf>] fc_exch_mgr_reset+0x1df/0x250 [libfc]
 [<ffffffffa02c57a0>] ? fc_fcp_recv+0x0/0xc30 [libfc]
 [<ffffffffa02c1042>] fc_rport_work+0xf2/0x4e0 [libfc]
 [<ffffffff8109203e>] ? prepare_to_wait+0x4e/0x80
 [<ffffffffa02c0f50>] ? fc_rport_work+0x0/0x4e0 [libfc]
 [<ffffffff8108c6c0>] worker_thread+0x170/0x2a0
 [<ffffffff81091d50>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8108c550>] ? worker_thread+0x0/0x2a0
 [<ffffffff810919e6>] kthread+0x96/0xa0
 [<ffffffff810141ca>] child_rip+0xa/0x20
 [<ffffffff81091950>] ? kthread+0x0/0xa0
 [<ffffffff810141c0>] ? child_rip+0x0/0x20
 Code:
 Bad RIP value.

 RIP
 [<(null)>] (null)
 RSP <ffff8803270f7b88>
 CR2: 0000000000000000
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>