BSS TREE LIST STRUCTURE(9)

🦋 BSS tree/list structure 🦋

okay bestie, welcome to the BSS tree/list structure(9) page from the Kernel API Manual — no cap, this is the whole tea on how the BSS tree/list keeps track of stuff 💅

At the top level, the BSS list is kept in both a list in each registered device (bss_list) and an RB-tree for faster lookup. In the RB-tree, entries can be looked up using their channel, MESHID, MESHCONF (for MBSSes), or their channel, BSSID, SSID for other BSSes. ✨

Because hidden SSIDs are a whole thing 😭, there’s a second level structure: the hidden_list and the hidden_beacon_bss pointer. The hidden_list connects all BSSes belonging to a single AP that has a hidden SSID, and it connects beacon and probe response entries. For a probe response entry for a hidden SSID, the hidden_beacon_bss pointer points to the BSS struct holding the beacon’s information. 🎀

Reference counting is done for all these references except for the hidden_list, so that a beacon BSS struct that is otherwise not referenced has one reference for being on the bss_list and one for each probe response entry that points to it using the hidden_beacon_bss pointer. When a BSS struct that has such a pointer is get/put, the refcount update is also propagated to the referenced struct — this ensures that it cannot get removed while somebody is using the probe response version. 🔥

Note note note: the hidden_beacon_bss pointer never changes, due to the reference counting. Therefore, no locking is needed for it. periodt. 💅

Also note that the hidden_beacon_bss pointer is only relevant if the driver uses something other than the IEs, e.g. private data stored in the BSS struct, since the beacon IEs are also linked into the probe response struct. 👑

🌈 SEE ALSO 🌈

• Kernel file ./net/wireless/scan.c enum bss_compare_mode(9)

mwah 💋 this little lore drop comes from ./net/wireless, dated October 2026, and it’s the BSS tree/list structure(9) page — catch you in the group chat 🫶