On Thu, 2009-02-12 at 13:56 +0100, Gabor Juhos wrote:
> Johannes Berg írta:
> > On Thu, 2009-02-12 at 11:16 +0100, Johannes Berg wrote:
> >>> to a soft-irq-unsafe lock:
> >>> (todo_lock){--..}
> >>> ... which became soft-irq-unsafe at:
> >>> ... [<800b2248>] __lock_acquire+0x624/0x844
> >>> [<800b24c4>] lock_acquire+0x5c/0x84
> >>> [<8006b8c4>] _spin_lock+0x34/0x48
> >>> [<c0206d9c>] ieee80211_set_default_key+0x4b8/0x4f0 [mac80211]
> >> That seems to be incorrect. ieee80211_set_default_key will have
> >> _irqsave-locked the key lock, so the todo lock is here always locked in
> >> an irq-excluded section.
>
> Yes, seems to be incorrect.
>
> >>
> >> The lock is, however, possibly used that way in ieee80211_key_link,
> >> which can be fixed easily and we can remove the todo lock too.
> >
> > Not true, but the todo_lock should be made to _irqsave in some places,
> > it seems.
Actually that doesn't seem to be true either...
> Should we handle this as a false positive for now, because I have seen this only
> once, and the transfer has not been interrupted? I will do more tests on
> different platforms, and i will come back if this happens again.
Yes, I think we should, something seems to be messed up with this
report. All code paths are regularly executed on all platforms, so we
should be seeing this a lot more if there was a problem.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
