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

libfcoe: Fix fcoe_sysfs VN2VN mode

2013-03-25T23:04:22+00:00

The libfc discovery layer is being initialized in the
'create' paths for both legacy libfcoe module parameters
and fcoe_sysfs control interfaces. The problem is that
for VN2VN mode the discovery layer is initialized as if
it were in 'fabric' mode and it is not re-configured when
the mode is changed to 'vn2vn'.

This patch splits out code that needs to be initialized
once and code that can, and should be, re-configured when
the mode changes. Additionally this patch makes that change
so that the discovery layer can be reconfigured to the
libfcoe implementation when in 'vn2vn' mode.

Signed-off-by: Robert Love 
Tested-by: Jack Morgan 
Reviewed-by: Bhanu Prakash Gollapudi

libfc, fcoe, bnx2fc: Split fc_disc_init into fc_disc_{init, config}

2013-03-25T23:03:03+00:00

Split discovery initialization in code that is setup once (fcoe_disc_init)
and code that can be re-configured (fcoe_disc_config).

Signed-off-by: Robert Love 
Tested-by: Jack Morgan 
Reviewed-by: Bhanu Prakash Gollapudi

libfc, fcoe, bnx2fc: Always use fcoe_disc_init for discovery layer initialization

2013-03-25T23:01:10+00:00

Currently libfcoe is doing some libfc discovery layer initialization outside of
libfc. This patch moves this code into libfc and sets up a split in discovery
(one time) initialization code and (re-configurable) settings that will come in
the next patch.

Signed-off-by: Robert Love 
Tested-by: Jack Morgan 
Reviewed-by: Bhanu Prakash Gollapudi

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

[SCSI] Merge tag 'fcoe-02-19-13' into for-linus

2013-03-01T09:10:08+00:00

FCoE Updates for 3.9

Signed-off-by: James Bottomley

libfcoe: Check for unusable FCFs before looking for conflicting FCFs

2013-02-19T20:23:07+00:00

When there are multiple FCFs in the fabric, and one of them becomes
unavailable, the fabric name for the unavailable FCF becomes 0 along
with FIP_FL_AVAIL getting reset. In this case, FCF selection logic does
not select any FCF as it first checks for conflicting FCFs (since fabric
name is 0, it fails the condition), instead of first checking if it is
usable or not. Fix it by first checking if FCF is usable and skip that
FCF, and go to the next one in the list to check if it can be selected.

Signed-off-by: Bhanu Prakash Gollapudi 
Signed-off-by: Robert Love

libfcoe: Handle CVL while waiting to select an FCF

2013-02-12T01:38:35+00:00

When a CVL is received while we wait to select best FCF, we drop it
without handling it. This causes initiator and the switch to go
out-of-sync. Initiator proceeds selecting one of the FCFs and tries to
send FIP FLOGI. However the switch may reject the FLOGI, as it has
cleared its internal state, and expects the initiator to start FIP
discovery protocol. Fix this condition by resetting the fcoe
controller.

Signed-off-by: Bhanu Prakash Gollapudi 
Reviewed-by: Yi Zou 
Signed-off-by: Robert Love

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

random32: rename random32 to prandom

2012-12-18T01:15:26+00:00

This renames all random32 functions to have 'prandom_' prefix as follows:

  void prandom_seed(u32 seed);	/* rename from srandom32() */
  u32 prandom_u32(void);		/* rename from random32() */
  void prandom_seed_state(struct rnd_state *state, u64 seed);
  				/* rename from prandom32_seed() */
  u32 prandom_u32_state(struct rnd_state *state);
  				/* rename from prandom32() */

The purpose of this renaming is to prevent some kernel developers from
assuming that prandom32() and random32() might imply that only
prandom32() was the one using a pseudo-random number generator by
prandom32's "p", and the result may be a very embarassing security
exposure.  This concern was expressed by Theodore Ts'o.

And furthermore, I'm going to introduce new functions for getting the
requested number of pseudo-random bytes.  If I continue to use both
prandom32 and random32 prefixes for these functions, the confusion
is getting worse.

As a result of this renaming, "prandom_" is the common prefix for
pseudo-random number library.

Currently, srandom32() and random32() are preserved because it is
difficult to rename too many users at once.

Signed-off-by: Akinobu Mita 
Cc: "Theodore Ts'o" 
Cc: Robert Love 
Cc: Michel Lespinasse 
Cc: Valdis Kletnieks 
Cc: David Laight 
Cc: Adrian Hunter 
Cc: Artem Bityutskiy 
Cc: David Woodhouse 
Cc: Eilon Greenstein 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds