Re: [Madwifi-devel] debugging soft lockups

[Brian E. <eat...@gm...>]

On 4/28/06, Brian Eaton <eat...@gm...> wrote:
> This is the deadlock scenario I see:
>
> user-context: user-context calls ieee80211_new_state, locks the spinlock
> tasklet: ieee80211_input tasklet starts, preempting the user-context call
> tasklet: ieee80211_input -> ieee80211_recv_mgmt -> ieee80211_new_state
> tasklet: blocked on spinlock in ieee80211_new_state
> user-context: blocked since the tasklet never gives up the CPU to user-co=
ntext

Actually it's a little worse than that.  ieee80211_new_state is called
from functions that are triggered by the timer APIs, such as
ieee80211_tx_timeout.  I believe those timers are run in hardIRQ
context.  So there are deadlock scenarios whether it's tasklet or
user-context that grabs the lock first.

I've attached a patch that disables IRQs around ieee80211_new_state to
ticket 570.  The patch works well for me, but I don't think it should
be submitted just yet.  I'd like to read over ieee80211_new_state a
bit to see if it follows the rules for code that has interrupts
disabled.

Regards,
Brian