Re: Why newstate handler runs IEEE80211_LOCK/UNLOCK?
- Reply: Farhan Khan: "Re: Why newstate handler runs IEEE80211_LOCK/UNLOCK?"
- In reply to: Farhan Khan: "Why newstate handler runs IEEE80211_LOCK/UNLOCK?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 30 Nov 2023 06:24:36 UTC
On Wed, 29 Nov 2023 at 22:12, Farhan Khan <farhan@farhan.codes> wrote: > Hi all, > > I'm studying the implementations of net80211 and noticed that in all > newstate handlers the code begins by running IEEE80211_UNLOCK(ic) and ends > with IEEE80211_LOCK(ic). I was not clear on why this was, I would have > expected the opposite order. Also, why not just use the softc device-wide > mutex over one for ieee80211com. Overall, I do not seem to understand the > intent of the unlock and am seeking clarification. > That part of the net80211 locking handling is ... unfortunately unfun. Without doing that, there'd be lots of lock order inversion issues and sleeping whilst lock held issues (since it's a mutex, not a sleep lock.) The newstate code in net80211 at least (now?) runs in a taskqueue, so whenever something changes state, it isn't happening in a random drivers rx/tx/ioctl path. That way newstate transitions are at hopefully serialised and not running in overlapping/concurrent threads. However, since drivers do a /lot/ of potentially sleeping work in the newstate path - think all the sleeping that goes on when things wait for firmware commands to complete - you can't hold a mutex across those. I tried cleaning that up years ago but it was .. very tricky to try and change. The wireless drivers would need to make sure they do /no/ blocking activity in the newstate routines, which is .. tricky. -adrian > > Thank you, > -- > Farhan Khan > PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE > > >