On Wed, 2018-01-31 at 16:53 -0800, Ben Greear wrote: > > Any idea why this might be complaining? > 30917 Jan 31 15:21:01 2u-6n kernel: ============================= > 30918 Jan 31 15:21:01 2u-6n kernel: WARNING: suspicious RCU usage well, that's why? :-) > 30933 stack backtrace: > 30934 Jan 31 15:21:01 2u-6n kernel: CPU: 1 PID: 19628 Comm: ip Tainted: G W O 4.13.16+ #2 > 30935 Jan 31 15:21:01 2u-6n kernel: Hardware name: Iron_Systems,Inc CS-CAD-2U-A02/X10SRL-F, BIOS 2.0b 05/02/2017 > 30936 Jan 31 15:21:01 2u-6n kernel: Call Trace: > 30937 Jan 31 15:21:01 2u-6n kernel: dump_stack+0x85/0xc7 > 30938 Jan 31 15:21:01 2u-6n kernel: lockdep_rcu_suspicious+0xc5/0x100 > 30939 Jan 31 15:21:01 2u-6n kernel: ieee80211_tx_h_select_key+0x1c9/0x4e0 [mac80211] > 30940 Jan 31 15:21:01 2u-6n kernel: ieee80211_tx_dequeue+0x376/0xca0 [mac80211] > 30941 Jan 31 15:21:01 2u-6n kernel: ath_tid_dequeue+0x9c/0x110 [ath9k] > 30942 Jan 31 15:21:01 2u-6n kernel: ath_tx_node_cleanup+0xa4/0x160 [ath9k] > 30943 Jan 31 15:21:01 2u-6n kernel: ath9k_sta_state+0x6b/0x1e0 [ath9k] > 30944 Jan 31 15:21:01 2u-6n kernel: drv_sta_state+0xad/0xa80 [mac80211] I'd argue your hacks are at fault - somewhere in your modifications around this call stack you lost the necessary rcu_read_lock() protection. joahnnes
