1. 28 7月, 2010 19 次提交
  2. 25 5月, 2010 1 次提交
  3. 17 5月, 2010 8 次提交
    • 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
    • K
      [SCSI] libfcoe: FIP Keep-Alive messages for VPorts are sent with incorrect port_id and wwn · fb83153d
      Kaladhar Musunuru 提交于
      All VNports are sending FIP Keep-Alive messages with port_id and wwpn of the parent host instead of it's own port_id and wwpn. Standard FIP descriptor type 11 indicates to send own port_id and port_name.
      Signed-off-by: NKaladhar Musunuru <kmusunuru@juniper.net>
      Acked-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>
      fb83153d
    • K
      [SCSI] libfcoe: Fix incorrect MAC address clearing · 8b889e4f
      Kaladhar Musunuru 提交于
      Fix typo in memset. Incorrect length parameter to memset resulting non-zero MAC address in FPMA messages.
      Signed-off-by: NKaladhar Musunuru <kmusunuru@juniper.net>
      Acked-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>
      8b889e4f
    • 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] libfc: Move the port_id into lport · 7b2787ec
      Robert Love 提交于
      This patch creates a port_id member in struct fc_lport.
      This allows libfc to just deal with fc_lport instances
      instead of calling into the fc_host to get the port_id.
      
      This change helps in only using symbols necessary for
      operation from the libfc structures. libfc still needs
      to change the fc_host_port_id() if the port_id changes
      so the presentation layer (scsi_transport_fc) can provide
      the user with the correct value, but libfc shouldn't
      rely on the presentation layer for operational values.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      7b2787ec
    • 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
    • R
      [SCSI] libfc: Remove extra pointer check · d29510a2
      Robert Love 提交于
      The fcf pointer is checked again after this verification
      making the first check redundant. Remote the first check.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      d29510a2
    • 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
  4. 12 4月, 2010 6 次提交
  5. 11 4月, 2010 6 次提交