search

o11s / open80211s

open80211s
Other
242 stars 55 forks source link

WARNING on ft-11aa #13

Closed jlopex closed 11 years ago

jlopex commented 11 years ago

Oct 28 01:13:28 garfield kernel: [ 206.960376] ------------[ cut here ]------------ Oct 28 01:13:28 garfield kernel: [ 206.961189] WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xaa/0xf0() Oct 28 01:13:28 garfield kernel: [ 206.961189] Hardware name: Bochs Oct 28 01:13:28 garfield kernel: [ 206.961189] Modules linked in: carl9170 mac80211 ath cfg80211 [last unloaded: cfg80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] Pid: 5, comm: kworker/u:0 Not tainted 3.5.0-cafb7b6+ #230 Oct 28 01:13:28 garfield kernel: [ 206.961189] Call Trace: Oct 28 01:13:28 garfield kernel: [ 206.961189] [] warn_slowpath_common+0x7f/0xc0 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? carl9170_op_tx+0x38b/0x910 [carl9170] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] warn_slowpath_null+0x1a/0x20 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] local_bh_enable_ip+0xaa/0xf0 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] _raw_spin_unlock_bh+0x34/0x40 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] carl9170_op_tx+0x38b/0x910 [carl9170] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211_tx+0x1d2/0x3b0 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? carl9170_tx_status+0x278/0x4c0 [carl9170] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211_tx+0x12e/0x160 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? ieee80211_tx+0x3e/0x160 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211_xmit+0xc6/0x160 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? ieee80211_tx+0x160/0x160 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211_tx_skb_tid+0x5f/0x70 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211aa_retransmit_frame+0xe0/0x100 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211aa_retransmit+0x5b/0xa0 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211aa_apply_ba_scoreboard+0x25/0x30 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211aa_handle_ba+0xea/0x110 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211_mesh_rx_queued_ctl+0x51/0x80 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ieee80211_iface_work+0x2fd/0x380 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? ieee80211_teardown_sdata+0xf0/0xf0 [mac80211] Oct 28 01:13:28 garfield kernel: [ 206.961189] [] process_one_work+0x18a/0x510 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? process_one_work+0x11e/0x510 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] worker_thread+0x15f/0x350 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? manage_workers.isra.27+0x230/0x230 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] kthread+0x93/0xa0 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] kernel_thread_helper+0x4/0x10 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? retint_restore_args+0xe/0xe Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? init_kthread_worker+0x70/0x70 Oct 28 01:13:28 garfield kernel: [ 206.961189] [] ? gs_change+0xb/0xb Oct 28 01:13:28 garfield kernel: [ 206.961189] ---[ end trace fde64eb4af4d4df1 ]---

jcard0na commented 11 years ago

The warning takes place in kernel/softirq.c:159:

static inline void _local_bh_enable_ip(unsigned long ip)
{
        WARN_ON_ONCE(in_irq() || irqs_disabled());

This function attempts to re-enable soft irqs, and the error is triggered when this happens inside an execution context where they should be disabled. This can happen with nested spin_lock_bh() calls: the inner lock will attept to re-enable soft irqs, but that is forbidden by the outer lock.

The above stack trace shows us where this is happening:

ieee80211aa_handle_ba()
  -> spin_lock_bh(&p->lock);   
      ieee80211aa_process_ba()
      -> ieee80211aa_apply_ba_scoreboard()
          -> ieee80211aa_retransmit()
             -> // eventually calls the driver tx function which takes another bh spinlock
      spin_unlock_bh();

I think there are ways to allow nested spinlocks_bh, but the real question is... do we really need to hold this spin lock all the way into the transmit path? Can't we just copy whatever information we need from the rmc entry (p) and release the lock right away. By the way, the same pattern occurs in ieee80211aa_handle_bar()