Re: Request for architectural review: experimental net80211/LinuxKPI HE station support

On Sun, 8 Nov 2026 at 13:37, Bjoern A. Zeeb <bz@freebsd.org> wrote:

> On Fri, 6 Nov 2026, Adrian Chadd wrote:
>
> > It's mostly telling that early up I gotta figure out really why the
> locking
> > is showing up in the he state in the node and if so, maybe I should go
> > create a formal node lock for node state and mark it appropriately.
>
> No!  Please not more of a mess.
>
>
We don't have a choice in /not/ figuring out locking. net80211's locking is
from a different time with non-preemptable kernel threads and mostly
non-SMP machines. Its locking against ioctl vs RX / interrupt thread based
stuff.

A lot of the weird bss races and configuration issues stem from TX, RX,
taskqueue and ioctl paths all existing now with no clearly defined locking
and operations. It is VERY possible to have a node will be modified both
via all of the above all at the same time.


>
> > I'm also going to review the he definitions it brought into the header
> > files as the first pass to see what's good as is, what needs tweaking and
> > how it intersects with the rest of linuxkpi.
>
> All definitions used by LinuxKPI based wireless drivers that compiled at
> some
> point are in there.  If we need to fill gaps then that is most likely due
> to
> the fact that we want them in the mgmt code to handle other cases (fields,
> flags, ..) for the fullness of spec.  But that is then likely easily done
> along with writing such code as needed and the spec next to it.
>
>
Right, and the original submitter has at least enumerated some of those
places which need things to happen.



-adrian