Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 28 7月, 2010 6 次提交
    • J
      [SCSI] fcoe: config via separate create_vn2vn module parameter · 1dd454d9
      由 Joe Eykholt 提交于 
      Add module parameter create_vn2vn that behaves like the create
parameter except that the new instance is created in FIP vn2vn mode.

This can be replaced once we change create to allow modifying
per-instance attributes before starting the instance.
Signed-off-by: NJoe Eykholt <jeykholt@cisco.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      1dd454d9
    • J
      [SCSI] fcoe libfcoe: use correct FC-MAP for VN2VN mode · cd229e42
      由 Joe Eykholt 提交于 
      In VN2VN mode, map_dest means to use the default VN2VN OUI.
Change code that uses the default FCoE OUI to use the one
set in the fcoe_ctlr struct.
Signed-off-by: NJoe Eykholt <jeykholt@cisco.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      cd229e42
    • J
      [SCSI] libfcoe: fcoe: fnic: add FIP VN2VN point-to-multipoint support · e10f8c66
      由 Joe Eykholt 提交于 
      The FC-BB-6 committee is proposing a new FIP usage model called
VN_port to VN_port mode.  It allows VN_ports to discover each other
over a loss-free L2 Ethernet without any FCF or Fibre-channel fabric
services.  This is point-to-multipoint.  There is also a variant
of this called point-to-point which provides for making sure there
is just one pair of ports operating over the Ethernet fabric.

We add these new states:  VNMP_START, _PROBE1, _PROBE2, _CLAIM, and _UP.
These usually go quickly in that sequence.  After waiting a random
amount of time up to 100 ms in START, we select a pseudo-random
proposed locally-unique port ID and send out probes in states PROBE1
and PROBE2, 100 ms apart.  If no probe responses are heard, we
proceed to CLAIM state 400 ms later and send a claim notification.
We wait another 400 ms to receive claim responses, which give us
a list of the other nodes on the network, including their FC-4
capabilities.  After another 400 ms we go to VNMP_UP state and
should start interoperating with any of the nodes for whic we
receivec claim responses.  More details are in the spec.j

Add the new mode as FIP_MODE_VN2VN.  The driver must specify
explicitly that it wants to operate in this mode.  There is
no automatic detection between point-to-multipoint and fabric
mode, and the local port initialization is affected, so it isn't
anticipated that there will ever be any such automatic switchover.

It may eventually be possible to have both fabric and VN2VN
modes on the same L2 network, which may be done by two separate
local VN_ports (lports).

When in VN2VN mode, FIP replaces libfc's fabric-oriented discovery
module with its own simple code that adds remote ports as they
are discovered from incoming claim notifications and responses.
These hooks are placed by fcoe_disc_init().

A linear list of discovered vn_ports is maintained under the
fcoe_ctlr struct.  It is expected to be short for now, and
accessed infrequently.  It is kept under RCU for lock-ordering
reasons.  The lport and/or rport mutexes may be held when we
need to lookup a fcoe_vnport during an ELS send.

Change fcoe_ctlr_encaps() to lookup the destination vn_port in
the list of peers for the destination MAC address of the
FIP-encapsulated frame.

Add a new function fcoe_disc_init() to initialize just the
discovery portion of libfcoe for VN2VN mode.
Signed-off-by: NJoe Eykholt <jeykholt@cisco.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      e10f8c66
    • J
      [SCSI] libfcoe: fcoe: fnic: change fcoe_ctlr_init interface to specify mode · 3d902ac0
      由 Joe Eykholt 提交于 
      There are three modes that libfcoe currently supports, and a new one
is coming.  Change the fcoe_ctlr_init() interface to add the mode
desired.  This should not change any functionality.
Signed-off-by: NJoe Eykholt <jeykholt@cisco.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      3d902ac0
    • V
      [SCSI] fcoe: adds src and dest mac address checking for fcoe frames · 519e5135
      由 Vasu Dev 提交于 
      This is  per FC-BB-5 Annex-D recommendation and per that
if address checking fails then drop the frame.

FIP code paths are already doing this so only needed for fcoe
frames.

The src address checking is limited to only fip mode since
this might break non-fip mode used in p2p due to used OUI
based addressing in some p2p code paths, going forward FIP
will be the only mode, therefore limited this to only FIP
mode so that it won't break non-fip p2p mode for now.

-v2
Removes FCOE packet type checking since fcoe_rcv is
registered to receive only FCoE type packets from netdev
and it is already checked by netdev.
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>
      519e5135
    • V
      [SCSI] fcoe: cleans up fcoe_disable and fcoe_enable · 9d4cbc05
      由 Vasu Dev 提交于 
      The fc_fabric_logoff and fc_fabric_login are redundant
here after recently added fcoe_ctlr_link_down/up to
these functions, therefore this patch removes logoff
and login to only use link down and up here. This works
best for their current usages with fcoe DCB link down or up.

This also works well to avoid EIO errors when fcoe DCB link
goes down as lport state moves out of ready quickly from
fcoe_ctlr_link_down and that allows re-queuing timed out IOs
for this case also.
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>
      9d4cbc05
  3. 25 5月, 2010 1 次提交
  5. 17 5月, 2010 4 次提交
    • V
      [SCSI] fcoe: fix fcoe module ref counting · 15af974d
      由 Vasu Dev 提交于 
      Currently fcoe module ref count is used for tracking
active fcoe instances, it means each fcoe instance create
increments the count while destroy dec the count.

The dec is done only if fcoe instance is destroyed from
/sysfs but not if destroyed due to NETDEV_UNREGISTER event.
So this patch moves only module_put doing dec to common
fcoe_if_destroy function, so that dec would occur on ever
fcoe instance destroy.
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>
      15af974d
    • V
      [SCSI] fcoe: fix a circular locking issue with rtnl and sysfs mutex · 34ce27bc
      由 Vasu Dev 提交于 
      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: 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>
      34ce27bc
    • R
      [SCSI] fcoe: move link speed checking into its own routine · 5e4f8fe7
      由 Robert Love 提交于 
      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: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      5e4f8fe7
    • V
      [SCSI] fcoe: fixes wrong error exit in fcoe_create · 721cafaf
      由 Vasu Dev 提交于 
      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: 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>
      721cafaf
  7. 12 4月, 2010 5 次提交
  9. 11 4月, 2010 4 次提交
  11. 04 4月, 2010 2 次提交
  13. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      由 Tejun Heo 提交于 
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking 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: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  15. 18 2月, 2010 1 次提交
    • R
      [SCSI] fcoe: Only rmmod fcoe.ko if there are no active connections · e9ee2cf4
      由 Robert Love 提交于 
      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: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      e9ee2cf4
  17. 17 2月, 2010 1 次提交
    • R
      [SCSI] fcoe: Only rmmod fcoe.ko if there are no active connections · 6409ea65
      由 Rob Love 提交于 
      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: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      6409ea65
  19. 17 12月, 2009 1 次提交
  21. 13 12月, 2009 1 次提交
    • V
      [SCSI] fcoe, libfc: adds enable/disable for fcoe interface · 55a66d3c
      由 Vasu Dev 提交于 
      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: 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>
      55a66d3c
  23. 10 12月, 2009 1 次提交
  25. 05 12月, 2009 12 次提交