#
a53b59ec |
|
29-Sep-2020 |
Thomas Gleixner <tglx@linutronix.de> |
net: enic: Cure the enic api locking trainwreck enic_dev_wait() has a BUG_ON(in_interrupt()). Chasing the callers of enic_dev_wait() revealed the gems of enic_reset() and enic_tx_hang_reset() which are both invoked through work queues in order to be able to call rtnl_lock(). So far so good. After locking rtnl both functions acquire enic::enic_api_lock which serializes against the (ab)use from infiniband. This is where the trainwreck starts. enic::enic_api_lock is a spin_lock() which implicitly disables preemption, but both functions invoke a ton of functions under that lock which can sleep. The BUG_ON(in_interrupt()) does not trigger in that case because it can't detect the preempt disabled condition. This clearly has never been tested with any of the mandatory debug options for 7+ years, which would have caught that for sure. Cure it by adding a enic_api_busy member to struct enic, which is modified and evaluated with enic::enic_api_lock held. If enic_api_devcmd_proxy_by_index() observes enic::enic_api_busy as true, it drops enic::enic_api_lock and busy waits for enic::enic_api_busy to become false. It would be smarter to wait for a completion of that busy period, but enic_api_devcmd_proxy_by_index() is called with other spin locks held which obviously can't sleep. Remove the BUG_ON(in_interrupt()) check as well because it's incomplete and with proper debugging enabled the problem would have been caught from the debug checks in schedule_timeout(). Fixes: 0b038566c0ea ("drivers/net: enic: Add an interface for USNIC to interact with firmware") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d0ea5cbd |
|
25-Sep-2020 |
Jesse Brandeburg <jesse.brandeburg@intel.com> |
drivers/net/ethernet: clean up mis-targeted comments As part of the W=1 cleanups for ethernet, a million [*] driver comments had to be cleaned up to get the W=1 compilation to succeed. This change finally makes the drivers/net/ethernet tree compile with W=1 set on the command line. NOTE: The kernel uses kdoc style (see Documentation/process/kernel-doc.rst) when documenting code, not doxygen or other styles. After this patch the x86_64 build has no warnings from W=1, however scripts/kernel-doc says there are 1545 more warnings in source files, that I need to develop a script to fix in a followup patch. The errors fixed here are all kdoc of a few classes, with a few outliers: In file included from drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c:10: drivers/net/ethernet/qlogic/netxen/netxen_nic.h:1193:18: warning: ‘FW_DUMP_LEVELS’ defined but not used [-Wunused-const-variable=] 1193 | static const u32 FW_DUMP_LEVELS[] = { 0x3, 0x7, 0xf, 0x1f, 0x3f, 0x7f, 0xff }; | ^~~~~~~~~~~~~~ ... repeats 4 times... drivers/net/ethernet/sun/cassini.c:2084:24: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body] 2084 | RX_USED_ADD(page, i); drivers/net/ethernet/natsemi/ns83820.c: In function ‘phy_intr’: drivers/net/ethernet/natsemi/ns83820.c:603:6: warning: variable ‘tbisr’ set but not used [-Wunused-but-set-variable] 603 | u32 tbisr, tanar, tanlpar; | ^~~~~ drivers/net/ethernet/natsemi/ns83820.c: In function ‘ns83820_get_link_ksettings’: drivers/net/ethernet/natsemi/ns83820.c:1207:11: warning: variable ‘tanar’ set but not used [-Wunused-but-set-variable] 1207 | u32 cfg, tanar, tbicr; | ^~~~~ drivers/net/ethernet/packetengines/yellowfin.c:1063:18: warning: variable ‘yf_size’ set but not used [-Wunused-but-set-variable] 1063 | int data_size, yf_size; | ^~~~~~~ Normal kdoc fixes: warning: Function parameter or member 'x' not described in 'y' warning: Excess function parameter 'x' description in 'y' warning: Cannot understand <string> on line <NNN> - I thought it was a doc line [*] - ok it wasn't quite a million, but it felt like it. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8e091340 |
|
23-Jun-2014 |
Tony Camuso <tcamuso@redhat.com> |
enic: fix lockdep around devcmd_lock We were experiencing occasional "BUG: scheduling while atomic" splats in our testing. Enabling DEBUG_SPINLOCK and DEBUG_LOCKDEP in the kernel exposed a lockdep in the enic driver. enic 0000:0b:00.0 eth2: Link UP ====================================================== [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] 3.12.0-rc1.x86_64-dbg+ #2 Tainted: GF W ------------------------------------------------------ NetworkManager/4209 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire: (&(&enic->devcmd_lock)->rlock){+.+...}, at: [<ffffffffa026b7e4>] enic_dev_packet_filter+0x44/0x90 [enic] The fix was to replace spin_lock with spin_lock_bh for the enic devcmd_lock, so that soft irqs would be disabled while the lock is held. Signed-off-by: Sujith Sankar <ssujith@cisco.com> Signed-off-by: Tony Camuso <tcamuso@redhat.com> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|