linux-toradex.git/drivers/scsi/fcoe/fcoe.c, branch v3.11

Merge tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2013-07-14T00:41:21+00:00

Pull final round of SCSI updates from James Bottomley:
 "This is the remaining set of SCSI patches for the merge window.  It's
  mostly driver updates (scsi_debug, qla2xxx, storvsc, mp3sas).  There
  are also several bug fixes in fcoe, libfc, and megaraid_sas.  We also
  have a couple of core changes to try to make device destruction more
  deterministic"

* tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (46 commits)
  [SCSI] scsi constants: command, sense key + additional sense strings
  fcoe: Reduce number of sparse warnings
  fcoe: Stop fc_rport_priv structure leak
  libfcoe: Fix meaningless log statement
  libfc: Differentiate echange timer cancellation debug statements
  libfc: Remove extra space in fc_exch_timer_cancel definition
  fcoe: fix the link error status block sparse warnings
  fcoe: Fix smatch warning in fcoe_fdmi_info function
  libfc: Reject PLOGI from nodes with incompatible role
  [SCSI] enable destruction of blocked devices which fail LUN scanning
  [SCSI] Fix race between starved list and device removal
  [SCSI] megaraid_sas: fix a bug for 64 bit arches
  [SCSI] scsi_debug: reduce duplication between prot_verify_read and prot_verify_write
  [SCSI] scsi_debug: simplify offset calculation for dif_storep
  [SCSI] scsi_debug: invalidate protection info for unmapped region
  [SCSI] scsi_debug: fix NULL pointer dereference with parameters dif=0 dix=1
  [SCSI] scsi_debug: fix incorrectly nested kmap_atomic()
  [SCSI] scsi_debug: fix invalid address passed to kunmap_atomic()
  [SCSI] mpt3sas: Bump driver version to v02.100.00.00
  [SCSI] mpt3sas: when async scanning is enabled then while scanning, devices are removed but their transport layer entries are not removed
  ...

fcoe: Fix smatch warning in fcoe_fdmi_info function

2013-07-09T16:29:17+00:00

This patch fixes a smatch warning as below:

smatch warnings:
drivers/scsi/fcoe/fcoe.c:782 fcoe_fdmi_info() warn: 'fdmi' puts 896 bytes on
stack

Reported-by: Fengguang Wu 
Signed-off-by: Neerav Parikh 
Tested-by: Jack Morgan 
Signed-off-by: Robert Love

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2013-07-03T21:55:13+00:00

Conflicts:
	drivers/net/ethernet/freescale/fec_main.c
	drivers/net/ethernet/renesas/sh_eth.c
	net/ipv4/gre.c

The GRE conflict is between a bug fix (kfree_skb --> kfree_skb_list)
and the splitting of the gre.c code into seperate files.

The FEC conflict was two sets of changes adding ethtool support code
in an "!CONFIG_M5272" CPP protected block.

Finally the sh_eth.c conflict was between one commit add bits set
in the .eesr_err_check mask whilst another commit removed the
.tx_error_check member and assignments.

Signed-off-by: David S. Miller

fcoe: Use correct API to set vlan tag for FCoE Ethertype skbs

2013-06-25T19:23:19+00:00

fcoe_xmit was coded such that it would skip the vlan net device/layer
and instead set some vlan flags and transmit on the real net device.
The real net device has code that would add the vlan tag for fcoe skbs.
This avoids some extra processing for data frames and provides a small
performance improvement.

Since fcoe_xmit was not using the vlan net device, __vlan_put_tag
within the real net device's xmit routine was ultimately being
called to set the vlan tag.

With the below change the behavior of __vlan_put_tag changed slightly,
it now sets the skb->protocol = vlan_proto. vlan_proto was not a field
being set by fcoe_xmit, so the skb->protocol is now not being set to
ETH_P_8021Q, as it should be.

This patch converts fcoe_xmit to use the vlan_put_tag routine which
will tag the skb and fcoe will continue to transmit fcoe skbs on the
real net device.

For reference, the below change was the one that altered the
__vlan_put_tag behavior.

  commit 86a9bad3ab6b6f858fd4443b48738cabbb6d094c
  Author: Patrick McHardy 
  Date:   Fri Apr 19 02:04:30 2013 +0000

      net: vlan: add protocol argument to packet tagging functions

      Add a protocol argument to the VLAN packet tagging functions. In case of HW
      tagging, we need that protocol available in the ndo_start_xmit functions,
      so it is stored in a new field in the skb. The new field fits into a hole
      (on 64 bit) and doesn't increase the sks's size.

Signed-off-by: Robert Love 
Acked-by: Neil Horman 
Acked-by: John Fastabend

net: pass info struct via netdevice notifier

2013-05-28T20:11:01+00:00

So far, only net_device * could be passed along with netdevice notifier
event. This patch provides a possibility to pass custom structure
able to provide info that event listener needs to know.

Signed-off-by: Jiri Pirko 

v2->v3: fix typo on simeth
	shortened dev_getter
	shortened notifier_info struct name
v1->v2: fix notifier_call parameter in call_netdevice_notifier()
Signed-off-by: David S. Miller

net: vlan: rename NETIF_F_HW_VLAN_* feature flags to NETIF_F_HW_VLAN_CTAG_*

2013-04-19T18:45:26+00:00

Rename the hardware VLAN acceleration features to include "CTAG" to indicate
that they only support CTAGs. Follow up patches will introduce 802.1ad
server provider tagging (STAGs) and require the distinction for hardware not
supporting acclerating both.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

fcoe: Fix deadlock between create and destroy paths

2013-03-25T22:55:56+00:00

We can deadlock (s_active and fcoe_config_mutex) if a
port is being destroyed at the same time one is being created.

[ 4200.503113] ======================================================
[ 4200.503114] [ INFO: possible circular locking dependency detected ]
[ 4200.503116] 3.8.0-rc5+ #8 Not tainted
[ 4200.503117] -------------------------------------------------------
[ 4200.503118] kworker/3:2/2492 is trying to acquire lock:
[ 4200.503119]  (s_active#292){++++.+}, at: [] sysfs_addrm_finish+0x3b/0x70
[ 4200.503127]
but task is already holding lock:
[ 4200.503128]  (fcoe_config_mutex){+.+.+.}, at: [] fcoe_destroy_work+0xe8/0x120 [fcoe]
[ 4200.503133]
which lock already depends on the new lock.

[ 4200.503135]
the existing dependency chain (in reverse order) is:
[ 4200.503136]
-> #1 (fcoe_config_mutex){+.+.+.}:
[ 4200.503139]        [] lock_acquire+0xa1/0x140
[ 4200.503143]        [] mutex_lock_nested+0x6e/0x360
[ 4200.503146]        [] fcoe_enable+0x1d/0xb0 [fcoe]
[ 4200.503148]        [] fcoe_ctlr_enabled+0x2d/0x50 [fcoe]
[ 4200.503151]        [] store_ctlr_enabled+0x38/0x90 [libfcoe]
[ 4200.503154]        [] dev_attr_store+0x18/0x30
[ 4200.503157]        [] sysfs_write_file+0xe0/0x150
[ 4200.503160]        [] vfs_write+0xac/0x180
[ 4200.503162]        [] sys_write+0x52/0xa0
[ 4200.503164]        [] system_call_fastpath+0x16/0x1b
[ 4200.503167]
-> #0 (s_active#292){++++.+}:
[ 4200.503170]        [] __lock_acquire+0x135f/0x1c90
[ 4200.503172]        [] lock_acquire+0xa1/0x140
[ 4200.503174]        [] sysfs_deactivate+0x116/0x160
[ 4200.503176]        [] sysfs_addrm_finish+0x3b/0x70
[ 4200.503178]        [] sysfs_hash_and_remove+0x5b/0xb0
[ 4200.503180]        [] sysfs_remove_group+0x61/0x100
[ 4200.503183]        [] device_remove_groups+0x3b/0x60
[ 4200.503185]        [] device_remove_attrs+0x44/0x80
[ 4200.503187]        [] device_del+0x127/0x1c0
[ 4200.503189]        [] device_unregister+0x22/0x60
[ 4200.503191]        [] fcoe_ctlr_device_delete+0xe0/0xf0 [libfcoe]
[ 4200.503194]        [] fcoe_interface_cleanup+0x6c/0xa0 [fcoe]
[ 4200.503196]        [] fcoe_destroy_work+0x105/0x120 [fcoe]
[ 4200.503198]        [] process_one_work+0x1a1/0x580
[ 4200.503203]        [] worker_thread+0x15e/0x440
[ 4200.503205]        [] kthread+0xea/0xf0
[ 4200.503207]        [] ret_from_fork+0x7c/0xb0

[ 4200.503209]
other info that might help us debug this:

[ 4200.503211]  Possible unsafe locking scenario:

[ 4200.503212]        CPU0                    CPU1
[ 4200.503213]        ----                    ----
[ 4200.503214]   lock(fcoe_config_mutex);
[ 4200.503215]                                lock(s_active#292);
[ 4200.503218]                                lock(fcoe_config_mutex);
[ 4200.503219]   lock(s_active#292);
[ 4200.503221]
 *** DEADLOCK ***

[ 4200.503223] 3 locks held by kworker/3:2/2492:
[ 4200.503224]  #0:  (fcoe){.+.+.+}, at: [] process_one_work+0x13b/0x580
[ 4200.503228]  #1:  ((&port->destroy_work)){+.+.+.}, at: [] process_one_work+0x13b/0x580
[ 4200.503232]  #2:  (fcoe_config_mutex){+.+.+.}, at: [] fcoe_destroy_work+0xe8/0x120 [fcoe]
[ 4200.503236]
stack backtrace:
[ 4200.503238] Pid: 2492, comm: kworker/3:2 Not tainted 3.8.0-rc5+ #8
[ 4200.503240] Call Trace:
[ 4200.503243]  [] print_circular_bug+0x1fb/0x20c
[ 4200.503246]  [] __lock_acquire+0x135f/0x1c90
[ 4200.503248]  [] ? debug_check_no_locks_freed+0x9a/0x180
[ 4200.503250]  [] lock_acquire+0xa1/0x140
[ 4200.503253]  [] ? sysfs_addrm_finish+0x3b/0x70
[ 4200.503255]  [] sysfs_deactivate+0x116/0x160
[ 4200.503258]  [] ? sysfs_addrm_finish+0x3b/0x70
[ 4200.503260]  [] sysfs_addrm_finish+0x3b/0x70
[ 4200.503262]  [] sysfs_hash_and_remove+0x5b/0xb0
[ 4200.503265]  [] sysfs_remove_group+0x61/0x100
[ 4200.503273]  [] device_remove_groups+0x3b/0x60
[ 4200.503275]  [] device_remove_attrs+0x44/0x80
[ 4200.503277]  [] device_del+0x127/0x1c0
[ 4200.503279]  [] device_unregister+0x22/0x60
[ 4200.503282]  [] fcoe_ctlr_device_delete+0xe0/0xf0 [libfcoe]
[ 4200.503285]  [] fcoe_interface_cleanup+0x6c/0xa0 [fcoe]
[ 4200.503287]  [] fcoe_destroy_work+0x105/0x120 [fcoe]
[ 4200.503290]  [] process_one_work+0x1a1/0x580
[ 4200.503292]  [] ? process_one_work+0x13b/0x580
[ 4200.503295]  [] ? fcoe_if_destroy+0x230/0x230 [fcoe]
[ 4200.503297]  [] worker_thread+0x15e/0x440
[ 4200.503299]  [] ? busy_worker_rebind_fn+0x100/0x100
[ 4200.503301]  [] kthread+0xea/0xf0
[ 4200.503304]  [] ? kthread_create_on_node+0x160/0x160
[ 4200.503306]  [] ret_from_fork+0x7c/0xb0
[ 4200.503308]  [] ? kthread_create_on_node+0x160/0x160

Signed-off-by: Robert Love 
Tested-by: Jack Morgan

fcoe: Fix deadlock while deleting FCoE interface with NPIV ports

2013-01-28T19:36:51+00:00

This patch fixes following deadlock caused by destroying of
an FCoE interface with active NPIV ports on that interface.

    Call Trace:
    [] schedule+0x64/0x66
    [] schedule_timeout+0x36/0xe3
    [] ? update_curr+0xd6/0x110
    [] ? hrtick_update+0x1b/0x4d
    [] ? dequeue_task_fair+0x1ca/0x1d9
    [] ? need_resched+0x1e/0x28
    [] wait_for_common+0x9b/0xf1
    [] ? try_to_wake_up+0x1e0/0x1e0
    [] wait_for_completion+0x1d/0x1f
    [] flush_workqueue+0x116/0x2a1
    [] drain_workqueue+0x66/0x14c
    [] destroy_workqueue+0x1a/0xcf
    [] fc_remove_host+0x154/0x17f [scsi_transport_fc]
    [] fcoe_if_destroy+0x184/0x1c9 [fcoe]
    [] fcoe_destroy_work+0x2b/0x44 [fcoe]
    [] process_one_work+0x1a8/0x2a4
    [] ? fcoe_if_destroy+0x1c9/0x1c9 [fcoe]
    [] worker_thread+0x1db/0x268
    [] ? wake_up_bit+0x2a/0x2a
    [] ? manage_workers.clone.16+0x1f6/0x1f6
    [] kthread+0x6f/0x77
    [] kernel_thread_helper+0x4/0x10
    [] ? kthread_freezable_should_stop+0x4b/0x4b

    Call Trace:
    [] schedule+0x64/0x66
    [] schedule_preempt_disabled+0xe/0x10
    [] __mutex_lock_common.clone.5+0x117/0x17a
    [] __mutex_lock_slowpath+0x13/0x15
    [] mutex_lock+0x23/0x37
    [] ? list_del+0x11/0x30
    [] fcoe_vport_destroy+0x43/0x5f [fcoe]
    [] fc_vport_terminate+0x48/0x110 [scsi_transport_fc]
    [] fc_vport_sched_delete+0x1d/0x79 [scsi_transport_fc]
    [] process_one_work+0x1a8/0x2a4
    [] ? fc_vport_terminate+0x110/0x110 [scsi_transport_fc]
    [] worker_thread+0x1db/0x268
    [] ? manage_workers.clone.16+0x1f6/0x1f6
    [] kthread+0x6f/0x77
    [] kernel_thread_helper+0x4/0x10
    [] ? kthread_freezable_should_stop+0x4b/0x4b
    [] ? gs_change+0x13/0x13

A prior attempt to fix this issue is posted here:
http://lists.open-fcoe.org/pipermail/devel/2012-October/012318.html
or
http://article.gmane.org/gmane.linux.scsi.open-fcoe.devel/11924

Based on feedback and discussion with Neil Horman it seems that the above patch
may have a case where the fcoe_vport_destroy() and fcoe_destroy_work() can
race; hence that patch has been withdrawn with this patch that is trying to
solve the same problem in a different way.

In the current approach instead of removing the fcoe_config_mutex from the
vport_delete callback function; I've chosen to delete all the NPIV ports first
on a given root lport before continuing with the removal of the root lport.

Signed-off-by: Neerav Parikh 
Tested-by: Marcus Dennis 
Acked-by: Neil Horman 
Signed-off-by: Robert Love

fcoe: close race on link speed detection in fcoe code

2013-01-28T19:13:01+00:00

When creating an fcoe interfce, we call fcoe_link_speed_update before we add the
lports fcoe interface to the fc_hostlist.  Since network device events like
NETDEV_CHANGE are only processed if an fcoe interface is found with an
underlying netdev that matches the netdev of the event.  Since this processing
in fcoe_device_notification is how link_speed changes get communicated to the
libfc  code (via fcoe_link_speed_update), we have a race condition - if a
NETDEV_CHANGE event is sent after the call to fcoe_link_speed_update in
fcoe_netdev_config, but before we add the interface to the fc_hostlist, we will
loose the event and attributes like /sys/class/fc_host/hostX/speed will not get
updated properly.

Fix this by moving the add to the fc_hostlist above the serialized call to
fcoe_netdev_config, ensuring that we catch netdev envents before we make a
direct call to fcoe_link_speed_update.

Also use this opportunity to clean up access to the fc_hostlist a bit by
creating a fcoe_hostlist_del accessor and replacing the cleanup in fcoe_exit to
use it properly.

Tested by myself successfully

[ Comment over 80 chars broken into multi-line by Robert Love to
  satisfy checkpatch.pl ]

Signed-off-by: Neil Horman 
Reviewed-by: Yi Zou 
Signed-off-by: Robert Love

libfcoe, fcoe: consolidate the fcoe_ctlr_get_lesb/fcoe_get_lesb

2012-12-14T18:38:55+00:00

Similarly they can be moved into libfcoe instead of being private to fcoe now.
Also add comments particularly on the term LESB to the corresponding function.

Signed-off-by: Yi Zou 
Cc: Bhanu Prakash Gollapudi 
Tested-by: Marcus Dennis 
Signed-off-by: Robert Love