Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 9月, 2016 2 次提交
  3. 14 7月, 2016 1 次提交
  5. 13 7月, 2016 1 次提交
    • S
      fcoe: convert to kworker · 4b9bc86d
      由 Sebastian Andrzej Siewior 提交于 
      The driver creates its own per-CPU threads which are updated based on
CPU hotplug events. It is also possible to use kworkers and remove some
of the kthread infrastrucure.

The code checked ->thread to decide if there is an active per-CPU
thread. By using the kworker infrastructure this is no longer
possible (or required). The thread pointer is saved in `kthread' instead
of `thread' so anything trying to use thread is caught by the
compiler. Currently only the bnx2fc driver is using struct fcoe_percpu_s
and the kthread member.

After a CPU went offline, we may still enqueue items on the "offline"
CPU. This isn't much of a problem. The work will be done on a random
CPU. The allocated crc_eof_page page won't be cleaned up. It is probably
expected that the CPU comes up at some point so it should not be a
problem. The crc_eof_page memory is released of course once the module
is removed.

This patch was only compile-tested due to -ENODEV.

Cc: Vasu Dev <vasu.dev@intel.com>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: fcoe-devel@open-fcoe.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: NJohannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      4b9bc86d
  7. 16 4月, 2016 3 次提交
  9. 24 2月, 2016 1 次提交
  11. 10 11月, 2015 5 次提交
  13. 27 10月, 2015 1 次提交
  15. 07 8月, 2015 1 次提交
  17. 04 12月, 2014 1 次提交
  19. 24 11月, 2014 2 次提交
  21. 21 11月, 2014 1 次提交
    • M
      bnx2fc: do not add shared skbs to the fcoe_rx_list · 01a4cc4d
      由 Maurizio Lombardi 提交于 
      In some cases, the fcoe_rx_list may contains multiple instances
of the same skb (the so called "shared skbs").

the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list,
modifies (and destroys) its content and then proceed to the next one.
The problem is that if the skb is shared, the remaining instances will
be corrupted.

The solution is to use skb_share_check() before adding the skb to the
fcoe_rx_list.

[ 6286.808725] ------------[ cut here ]------------
[ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]()
[ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio]
[ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1
[ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
[ 6286.808752]  0000000000000000 000000000b36e715 ffff8800deba1e00 ffffffff815ec0ba
[ 6286.808753]  ffff8800deba1e38 ffffffff8105dee1 ffffffffa05618c0 ffff8801e4c81888
[ 6286.808754]  ffffe8ffff663868 ffff8801f402b180 ffff8801f56bc000 ffff8800deba1e48
[ 6286.808754] Call Trace:
[ 6286.808759]  [<ffffffff815ec0ba>] dump_stack+0x19/0x1b
[ 6286.808762]  [<ffffffff8105dee1>] warn_slowpath_common+0x61/0x80
[ 6286.808763]  [<ffffffff8105e00a>] warn_slowpath_null+0x1a/0x20
[ 6286.808765]  [<ffffffffa054f415>] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]
[ 6286.808767]  [<ffffffffa054eff0>] ? bnx2fc_disable+0x90/0x90 [bnx2fc]
[ 6286.808769]  [<ffffffff81085aef>] kthread+0xcf/0xe0
[ 6286.808770]  [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
[ 6286.808772]  [<ffffffff815fc76c>] ret_from_fork+0x7c/0xb0
[ 6286.808773]  [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
[ 6286.808774] ---[ end trace c6cdb939184ccb4e ]---
Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com>
Acked-by: NChad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
      01a4cc4d
  23. 12 11月, 2014 4 次提交
  25. 26 7月, 2014 1 次提交
  27. 25 6月, 2014 1 次提交
    • N
      bnx2fc: Improve stats update mechanism · d576a5e8
      由 Neil Horman 提交于 
      Recently had this warning reported:

[  290.489047] Call Trace:
[  290.489053]  [<ffffffff8169efec>] dump_stack+0x19/0x1b
[  290.489055]  [<ffffffff810ac7a9>] __might_sleep+0x179/0x230
[  290.489057]  [<ffffffff816a4ad5>] mutex_lock_nested+0x55/0x520
[  290.489061]  [<ffffffffa01b9905>] ? bnx2fc_l2_rcv_thread+0xc5/0x4c0 [bnx2fc]
[  290.489065]  [<ffffffffa0174c1a>] fc_vport_id_lookup+0x3a/0xa0 [libfc]
[  290.489068]  [<ffffffffa01b9a6c>] bnx2fc_l2_rcv_thread+0x22c/0x4c0 [bnx2fc]
[  290.489070]  [<ffffffffa01b9840>] ? bnx2fc_vport_destroy+0x110/0x110 [bnx2fc]
[  290.489073]  [<ffffffff8109e0cd>] kthread+0xed/0x100
[  290.489075]  [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80
[  290.489077]  [<ffffffff816b2fec>] ret_from_fork+0x7c/0xb0
[  290.489078]  [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80

Its due to the fact that we call a potentially sleeping function from the bnx2fc
rcv path with preemption disabled (via the get_cpu call embedded in the per-cpu
variable stats lookup in bnx2fc_l2_rcv_thread.

Easy enough fix, we can just move the stats collection later in the function
where we are sure we won't preempt or sleep.  This also allows us to not have to
enable pre-emption when doing a per-cpu lookup, since we're certain not to get
rescheduled.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Acked-by: NEddie Wai <eddie.wai@broadcom.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      d576a5e8
  29. 18 4月, 2014 1 次提交
  31. 20 3月, 2014 1 次提交
    • S
      scsi, bnx2fc: Fix CPU hotplug callback registration · 7229b6d0
      由 Srivatsa S. Bhat 提交于 
      Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:

	get_online_cpus();

	for_each_online_cpu(cpu)
		init_cpu(cpu);

	register_cpu_notifier(&foobar_cpu_notifier);

	put_online_cpus();

This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).

Instead, the correct and race-free way of performing the callback
registration is:

	cpu_notifier_register_begin();

	for_each_online_cpu(cpu)
		init_cpu(cpu);

	/* Note the use of the double underscored version of the API */
	__register_cpu_notifier(&foobar_cpu_notifier);

	cpu_notifier_register_done();

Fix the bnx2fc code in scsi by using this latter form of callback
registration.

Cc: Eddie Wai <eddie.wai@broadcom.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7229b6d0
  33. 16 3月, 2014 2 次提交
    • E
      [SCSI] bnx2fc: Updated version to 2.4.2 · 38e83bff
      由 Eddie Wai 提交于 
      Old version: 2.4.1
New version: 2.4.2
Signed-off-by: NEddie Wai <eddie.wai@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      38e83bff
    • E
      [SCSI] bnx2fc: Fixed scsi_remove_target soft lockup when rmmod bnx2x · 06c4f20d
      由 Eddie Wai 提交于 
      The problem has been identified to be a change in the scsi_remove_device
path where a call to the pm_runtime_set_memalloc_noio was added when
del_gendisk is called in this path.  Note that the new pm routine
attempts to cycle through all parent devices from the FC target device
to set the memalloc_noio flag.  Because of this new change, a dependency
was created between the FC target device and the parent netdev device
in the destroy path.

In order to synchronized the destroy paths, bnx2fc has been modified
to flush all destroy workqueues in the NETDEV_UNREGISTER return path.

[    4.123584] BUG: soft lockup - CPU#8 stuck for 22s! [kworker/8:3:8082]
[    4.123713] Call Trace:
[    4.123719]  [<ffffffff815dfbe0>] klist_next+0x20/0xf0
[    4.123725]  [<ffffffff813e9220>] ? pm_save_wakeup_count+0x70/0x70
[    4.123731]  [<ffffffff813d9e4e>] device_for_each_child+0x4e/0x70
[    4.123735]  [<ffffffff813e9554>] pm_runtime_set_memalloc_noio+0x94/0xf0
[    4.123740]  [<ffffffff812d4d74>] del_gendisk+0x264/0x2a0
[    4.123747]  [<ffffffffa00c6dc9>] sd_remove+0x69/0xb0 [sd_mod]
[    4.123751]  [<ffffffff813de24f>] __device_release_driver+0x7f/0xf0
[    4.123754]  [<ffffffff813de2e3>] device_release_driver+0x23/0x30
[    4.123757]  [<ffffffff813ddab4>] bus_remove_device+0xf4/0x170
[    4.123760]  [<ffffffff813da475>] device_del+0x135/0x1d0
[    4.123765]  [<ffffffff81411b75>] __scsi_remove_device+0xc5/0xd0
[    4.123768]  [<ffffffff81411ba6>] scsi_remove_device+0x26/0x40
[    4.123770]  [<ffffffff81411d40>] scsi_remove_target+0x160/0x210
[    4.123775]  [<ffffffffa0420e4c>] fc_rport_final_delete+0xac/0x1f0 [scsi_transport_fc]
[    4.123780]  [<ffffffff810774ab>] process_one_work+0x17b/0x460
[    4.123783]  [<ffffffff8107825b>] worker_thread+0x11b/0x400
[    4.123786]  [<ffffffff81078140>] ? rescuer_thread+0x3e0/0x3e0
[    4.123791]  [<ffffffff8107e9c0>] kthread+0xc0/0xd0
[    4.123794]  [<ffffffff8107e900>] ? kthread_create_on_node+0x110/0x110
[    4.123798]  [<ffffffff8160ceec>] ret_from_fork+0x7c/0xb0
[    4.123801]  [<ffffffff8107e900>] ? kthread_create_on_node+0x110/0x110
Signed-off-by: NEddie Wai <eddie.wai@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      06c4f20d
  35. 25 10月, 2013 2 次提交
    • E
      [SCSI] bnx2fc: Bump version from 1.0.14 to 2.4.1 · aa106202
      由 Eddie Wai 提交于 
      Signed-off-by: NEddie Wai <eddie.wai@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      aa106202
    • E
      [SCSI] BNX2FC: hung task timeout warning observed when rmmod bnx2x with active FCoE targets · 0680810c
      由 Eddie Wai 提交于 
      [v2] - removed the interface->enabled flag setting which prevented the
       fcoe ctlr link from being brought back up after a MTU change

A rtnl_lock deadlock was observed from the rmmod thread where it
tries to unregister the fcoe_ctlr device.  This unregistration
triggered a flush of the sysfs queue of the associated ctlr and led to
a call to the set_fcoe_ctlr_enabled routine.  This will eventually propagate
down to call the bnx2fc_disable routine and contented for the rtnl_lock
in the same context.

This patch creates a subset of the bnx2fc_enable/disable routine which
removes the unnecesary rtnl_lock and the bnx2fc_dev_lock acquisition from
the set_fcoe_ctlr_enabled path.

 kernel: INFO: task rmmod:7874 blocked for more than 120 seconds.
 kernel:      Tainted: G        W  ---------------    2.6.32-415.0.1.el6.x86_64 #1
 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 kernel: rmmod         D 000000000000000f     0  7874   6518 0x00000080
 kernel: ffff88022158f7d8 0000000000000086 0000000000000000 0000000000000000
 kernel: ffff88023fe72600 ffff88043c74d410 ffff88043c74d400 ffff88043c74d000
 kernel: ffff88021ecbe5f8 ffff88022158ffd8 000000000000fbc8 ffff88021ecbe5f8
 kernel: Call Trace:
 kernel: [<ffffffff81525985>] schedule_timeout+0x215/0x2e0
 kernel: [<ffffffff810680c0>] ? pick_next_task_fair+0xd0/0x130
 kernel: [<ffffffff81524858>] ? schedule+0x178/0x3b2
 kernel: [<ffffffff81525603>] wait_for_common+0x123/0x180
 kernel: [<ffffffff81066b40>] ? default_wake_function+0x0/0x20
 kernel: [<ffffffff811a486e>] ? ifind_fast+0x5e/0xb0
 kernel: [<ffffffff8152571d>] wait_for_completion+0x1d/0x20
 kernel: [<ffffffff81203868>] sysfs_addrm_finish+0x228/0x270
 kernel: [<ffffffff812014ab>] sysfs_hash_and_remove+0x5b/0x90
 kernel: [<ffffffff812056af>] sysfs_remove_group+0x5f/0x100
 kernel: [<ffffffff81367e8b>] device_remove_groups+0x3b/0x60
 kernel: [<ffffffff8136811d>] device_remove_attrs+0x3d/0x90
 kernel: [<ffffffff81368295>] device_del+0x125/0x1e0
 kernel: [<ffffffff81368372>] device_unregister+0x22/0x60
 kernel: [<ffffffffa038ead2>] fcoe_ctlr_device_delete+0xe2/0xf4 [libfcoe]
 kernel: [<ffffffffa03c43cb>] bnx2fc_interface_release+0x5b/0x90 [bnx2fc]
 kernel: [<ffffffffa03c4370>] ? bnx2fc_interface_release+0x0/0x90 [bnx2fc]
 kernel: [<ffffffff812835e7>] kref_put+0x37/0x70
 kernel: [<ffffffffa03c4192>] __bnx2fc_destroy+0x72/0xa0 [bnx2fc]
 kernel: [<ffffffffa03c5265>] bnx2fc_ulp_exit+0xf5/0x160 [bnx2fc]    <- got bnx2fc_dev_lock mutex_lock
 kernel: [<ffffffffa03b03c6>] cnic_ulp_exit+0xb6/0xc0 [cnic]
 kernel: [<ffffffffa03b5418>] cnic_netdev_event+0x368/0x370 [cnic]
 kernel: [<ffffffffa038c56c>] ? fcoe_del_netdev_mapping+0x8c/0xa0 [libfcoe]
 kernel: [<ffffffff8152a6e5>] notifier_call_chain+0x55/0x80
 kernel: [<ffffffff810a0a46>] raw_notifier_call_chain+0x16/0x20
 kernel: [<ffffffff81459beb>] call_netdevice_notifiers+0x1b/0x20
 kernel: [<ffffffff8145ab34>] rollback_registered_many+0x154/0x280
 kernel: [<ffffffff8145ad08>] rollback_registered+0x38/0x50
 kernel: [<ffffffff8145ad78>] unregister_netdevice_queue+0x58/0xa0
 kernel: [<ffffffff8145add0>] unregister_netdevice+0x10/0x20
 kernel: [<ffffffff8145adfe>] unregister_netdev+0x1e/0x30                  <- got rtnl_lock!!!!!!!!!
 kernel: [<ffffffffa0122278>] __bnx2x_remove+0x48/0x270 [bnx2x] <- got & rel rtnl_lock
 kernel: [<ffffffffa0122554>] bnx2x_remove_one+0x44/0x80 [bnx2x]
 kernel: [<ffffffff812a3af7>] pci_device_remove+0x37/0x70
 kernel: [<ffffffff8136b2ef>] __device_release_driver+0x6f/0xe0
 kernel: [<ffffffff8136b428>] driver_detach+0xc8/0xd0
 kernel: [<ffffffff8136a22e>] bus_remove_driver+0x8e/0x110
 kernel: [<ffffffff8136bc12>] driver_unregister+0x62/0xa0
 kernel: [<ffffffff812a3e04>] pci_unregister_driver+0x44/0xb0
 kernel: [<ffffffffa0191954>] bnx2x_cleanup+0x18/0x73 [bnx2x]
 kernel: [<ffffffff810b8be4>] sys_delete_module+0x194/0x260
 kernel: [<ffffffff810e1347>] ? audit_syscall_entry+0x1d7/0x200
 kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
Signed-off-by: NEddie Wai <eddie.wai@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      0680810c
  37. 14 10月, 2013 1 次提交
    • J
      scsi: Convert uses of compare_ether_addr to ether_addr_equal · 6942df7f
      由 Joe Perches 提交于 
      Preliminary to removing compare_ether_addr altogether:

Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.

Done via cocci script:

$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
-	!compare_ether_addr(a, b)
+	ether_addr_equal(a, b)

@@
expression a,b;
@@
-	compare_ether_addr(a, b)
+	!ether_addr_equal(a, b)

@@
expression a,b;
@@
-	!ether_addr_equal(a, b) == 0
+	ether_addr_equal(a, b)

@@
expression a,b;
@@
-	!ether_addr_equal(a, b) != 0
+	!ether_addr_equal(a, b)

@@
expression a,b;
@@
-	ether_addr_equal(a, b) == 0
+	!ether_addr_equal(a, b)

@@
expression a,b;
@@
-	ether_addr_equal(a, b) != 0
+	ether_addr_equal(a, b)

@@
expression a,b;
@@
-	!!ether_addr_equal(a, b)
+	ether_addr_equal(a, b)
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
      6942df7f
  39. 12 10月, 2013 1 次提交
    • R
      libfcoe: Make fcoe_sysfs optional / fix fnic NULL exception · 9d34876f
      由 Robert Love 提交于 
      fnic doesn't use any of the create/destroy/enable/disable interfaces
either from the (legacy) module paramaters or the (new) fcoe_sysfs
interfaces. When fcoe_sysfs was introduced fnic wasn't changed since
it wasn't using the interfaces. libfcoe incorrectly assumed that that
all of its users were using fcoe_sysfs and when adding and deleting
FCFs would assume the existance of a fcoe_ctlr_device. fnic was not
allocating this structure because it doesn't care about the standard
user interfaces (fnic starts on link only). If/When libfcoe tried to use
the fcoe_ctlr_device's lock for the first time a NULL pointer exception
would be triggered.

Since fnic doesn't care about sysfs or user interfaces, the solution
is to drop libfcoe's assumption that all drivers are using fcoe_sysfs.

This patch accomplishes this by changing some of the structure
relationships.

We need a way to determine when a LLD is using fcoe_sysfs or not and
we can do that by checking for the existance of the fcoe_ctlr_device.
Prior to this patch, it was assumed that the fcoe_ctlr structure was
allocated with the fcoe_ctlr_device and immediately followed it in
memory. To reach the fcoe_ctlr_device we would simply go back in memory
from the fcoe_ctlr to get the fcoe_ctlr_device.

Since fnic doesn't allocate the fcoe_ctlr_device, we cannot keep that
assumption. This patch adds a pointer from the fcoe_ctlr to the
fcoe_ctlr_device. For bnx2fc and fcoe we will continue to allocate the
two structures together, but then we'll set the ctlr->cdev pointer
to point at the fcoe_ctlr_device. fnic will not change and will continue
to allocate the fcoe_ctlr itself, and ctlr->cdev will remain NULL.

When libfcoe adds fcoe_fcf's to the fcoe_ctlr it will check if ctlr->cdev
is set and only if so will it continue to interact with fcoe_sysfs.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Tested-by: NHiral Patel <hiralpat@cisco.com>
      9d34876f
  41. 02 5月, 2013 3 次提交
  43. 25 4月, 2013 1 次提交
  45. 26 3月, 2013 3 次提交