* [DESIGN RFC] Critical Update handling in the kernel
@ 2025-07-17 4:55 Aditya Kumar Singh
2025-07-22 14:42 ` Johannes Berg
0 siblings, 1 reply; 8+ messages in thread
From: Aditya Kumar Singh @ 2025-07-17 4:55 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, ath12k, Aditya Kumar Singh
Hi,
Some time ago, an approach was proposed [1] where all aspects of critical
update handling—including BPCC management, element propagation, and
timing-sensitive updates—were delegated entirely to the vendor's firmware.
While this design offers tight timing control and efficiency, one of the
key concerns raised was:
"What about vendors whose firmware does not support this functionality?"
"What about mac80211_hwsim? How this is supposed to work with
mac80211_hwsim?"
[1]: https://lore.kernel.org/linux-wireless/20240403162225.3096228-1-quic_rrchinan@quicinc.com/
To address this, a fallback mechanism in the kernel (mac80211) is being
proposed. This kernel-side implementation ensures that the feature remains
functional even when firmware support is absent, albeit with some
limitations in timing precision and certification readiness.
===========================================================================
OPEN QUESTIONS
===========================================================================
Before we move forward with implementation, we'd like to confirm whether
the proposed design looks sound. Are there any concerns or potential issues
we should be aware of?
Out of curiosity, we're also interested in understanding how other vendors
are currently handling this feature in their downstream drivers. Is it
typically offloaded to firmware, or is the logic implemented in the kernel?
Just want to confirm whether all this will be used only by mac80211_hwsim
or will there be any actual users?
===========================================================================
BACKGROUND
===========================================================================
Critical Update is a mechanism where, if a BSS parameter changes on one of
the links within a Multi-Link Device (MLD), that change is also signaled in
the beacons/probe response of its partner links. This allows the multi-link
client to be proactively informed of the update through any of the partner
links, rather than waiting to receive the updated beacon/probe responses
from the affected link itself.
For instance, if Link A initiates a channel switch, it will include the
Channel Switch Announcement (CSA) element in its own beacon.
Simultaneously, Link B will reflect this change by embedding the same CSA
element within Link A’s per-STA profile inside the Basic Multi-Link Element
(BMLE) of its own beacon.
This ensures that multi-link clients monitoring Link B can be promptly
informed of the change on Link A, without needing to wait for Link A’s next
beacon.
The below diagrams tries to depict the above said behavior:
Link A and Link B (part of MLD) originally beaconing just fine:
┌──────────────────────────────┐ ┌───────────────────────────────┐
│ Link A's beacon │ │ Link B's beacon │
│ │ │ │
│...... │ │...... │
│┌────────────────────────────┐│ │┌─────────────────────────────┐│
││RNR Element: ││ ││RNR Element: ││
││ TBTT INFO: ││ ││ TBTT INFO: ││
││ MLD INFO: ││ ││ MLD INFO: ││
││ LINK ID: B ││ ││ LINK ID: A ││
││ BPCC: 1 ││ ││ BPCC: 1 ││
│└────────────────────────────┘│ │└─────────────────────────────┘│
│...... │ │...... │
│┌────────────────────────────┐│ │┌─────────────────────────────┐│
││MULTI LINK Element: ││ ││MULTI LINK Element: ││
││ COMMON INFO: ││ ││ COMMON INFO: ││
││ LINK ID: A ││ ││ LINK ID: B ││
││ BPCC: 1 ││ ││ BPCC: 1 ││
││ ││ ││ ││
││ Basic STA profile count: 0││ ││ Basic STA profile count: 0 ││
│└────────────────────────────┘│ │└─────────────────────────────┘│
└──────────────────────────────┘ └───────────────────────────────┘
Link A started CSA and during CSA, the beaconing would look like -
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Link A's beacon │ │ Link B's beacon │
│ │ │ │
│┌────────────────────────────┐│ │┌────────────────────────────┐│
││Capabilities Info: ││ ││Capabilities Info: ││
││ BIT 6: CU Bit: True ││ ││ BIT 6: CU Bit: True ││
│└────────────────────────────┘│ │└────────────────────────────┘│
│┌────────────────────────────┐│ │ ...... │
││CSA: ││ │┌────────────────────────────┐│
││ CS Count: 5 ││ ││RNR Element: ││
│└────────────────────────────┘│ ││ TBTT INFO: ││
│...... │ ││ MLD INFO: ││
│┌────────────────────────────┐│ ││ LINK ID: A ││
││RNR Element: ││ ││ BPCC: 2 ││
││ TBTT INFO: ││ │└────────────────────────────┘│
││ MLD INFO: ││ │...... │
││ LINK ID: B ││ │┌────────────────────────────┐│
││ BPCC: 1 ││ ││MULTI LINK Element: ││
│└────────────────────────────┘│ ││ COMMON INFO: ││
│...... │ ││ LINK ID: B ││
│┌────────────────────────────┐│ ││ BPCC: 1 ││
││MULTI LINK Element: ││ ││ ││
││ COMMON INFO: ││ ││ Basic STA profile count: 1││
││ LINK ID: A ││ ││ Per STA Profile: ││
││ BPCC: 2 ││ ││ Link ID: A ││
││ ││ ││ ┌─────────────────────┐││
││ Basic STA profile count: 0││ ││ │CSA: │││
│└────────────────────────────┘│ ││ │ CS Count: 5 │││
└──────────────────────────────┘ ││ └─────────────────────┘││
│└────────────────────────────┘│
│...... │
└──────────────────────────────┘
===========================================================================
DESIGN PROPOSAL
===========================================================================
Assumptions:
------------
The critical update procedure is highly timing-sensitive. Ideally, this
should be handled by the firmware to ensure precise synchronization with
DTIM beacons. However, since not all firmware implementations support this
capability, the proposed kernel-side handling serves as a fallback
mechanism.
That said, due to inherent limitations in kernel-level timing
accuracy—especially in offloaded beacon scenarios—this approach may not
fully meet the strict timing requirements expected in certification
processes. It provides a best-effort solution but may not be suitable for
deployments where certification compliance is mandatory.
Extended feature flag:
----------------------
This design introduces additional computational overhead, which could
potentially delay beacon processing. Since not all mac80211 drivers may
prefer this behavior, introduce a new extended feature flag -
CRITICAL_UPDATE_SELF_MANAGED. mac80211 will NOT perform these extra
computations if the driver advertises this feature support.
Parsing the beacon update:
--------------------------
During the ieee80211_assign_beacon() call (where link->u.ap.beacon is
updated whenever the beacon content is initially set using
ieee80211_start_ap(), modified through ieee80211_change_beacon(), or
changed as a result of channel or color switch events) -
1. Store the new beacon data in a new pointer, following the usual flow.
2. Parse the beacon (using the head and tail pointers) and record the
starting offsets of each required Element (earlier referred to as IE i.e
Information element) in an array, indexed by element id or extended
element id. This is done per link object.
3. If a previous beacon exists:
3.1 For each element related to the critical update, perform a memcmp()
to detect changes compared to the previous contents.
3.2 If any such element has changed, set the critical update flag in
some link-level object (e.g., link_conf). (this is for the affected
link)
3.2.1 At the same time, set the critical update flag for all
partner links as well in the same object.
3.3 Increment the BPCC[2] value (modulo 256 excluding 255) for the
current link.
4. If critical update flag got set in previous step for partner links, call
link_info_changed() with CHANGED_BEACON to notify lower layer that
beacon has changed. This applies only in case when beacon is offloaded
to firmware. In case beacon is given to driver at every TBTT, there is
no need to notify since at next TBTT, driver will fetch the latest
beacon anyways.
Forming the new beacon:
-----------------------
In the __ieee80211_beacon_get() function, where the beacon SKBs are
constructed:
1. Allow the existing logic to generate all beacon SKBs (including multiple
SKBs in the case of MBSSID-EMA).
2. For each beacon SKB:
2.1 Parse the RNR (Reduced Neighbor Report) element.
2.1.1 For each TBTT Info entry:
2.1.1.1 Extract the BSSID
2.1.1.2 Retrieve the corresponding link sdata from BSSID
2.1.1.3 fetch the latest BPCC value.
2.1.1.4 Update the frame with this latest BPCC value.
2.2 Parse the MBSSID profile element.
2.2.1 For each non-Tx profile:
2.2.1.1 Extract the BSSID
2.2.1.2 Retrieve the corresponding link sdata from BSSID
2.2.1.3 If the critical update flag is set in link object, set
the CU (Critical Update) bit in the capability element.
2.2.1.4 Set non_tx_update = true.
2.3 Parse the multi-link element.
2.3.1 For the self link (already known), fetch the latest BPCC
value.
2.3.2 Update the frame with this BPCC value.
2.4 Update the capability element in the SKB:
2.4.1 If the critical update flag is set, set the CU bit.
2.4.2 If non_tx_update == true, also set the non-Tx CU bit.
This mechanism sufficiently handles critical updates due to modifications
of existing elements (elements related to the critical update which are
already present in the beacon and just one or more field is/are changing
its value). However, in the case of new element inclusion (elements related
to the critical update which are not alread present in the beacon, but is
getting added from next beacon), additional handling is required.
Specifically, the newly included elements related to the critical update
must be added to the per-STA profile within the Basic Multi-Link Element
(BMLE) [3].
To achieve this:
3. Allow the existing logic to form the beacon SKB as previously defined
(this already handles modification updates).
4. Maintain an extra_len variable to track any additional space required
for including additional elements.
5. While parsing:
5.1 If critical update is going on in partner link due to inclusion of
elements, increment extra_len accordingly.
5.2 The required length is determined using the eid/ext eid based
offset maintained in each beacon data structure.
5.3 Since the element offset is known, and the next byte is the tag
length, the total length is tag_len + 2 (for EID and length
fields).
5.4 Account for any additional fields that may be needed (e.g.,
sub-element ID and length in the Multi-Link IE).
6. Compute the new beacon size:
new_size = current_size + extra_len
7. Allocate a new SKB with the updated size.
8. Copy the existing contents and insert the new or updated elements at the
appropriate offsets.
9. Since IE offsets are cached in the beacon data structure, the entire IE
can be copied directly without re-parsing the full beacon from other
links.
10. Free the original beacon SKB.
11. Return the newly constructed beacon SKB.
DTIM beacon handling:
---------------------
As per requirement [4], the Critical Update (CU) bit in the capability
field must be cleared in the DTIM beacon.
For Non-Offloaded Beacon Handling:
1. The function __ieee80211_beacon_add_tim() is responsible for
updating the DTIM count.
2. When the DTIM count reaches 1 (indicating that the next beacon will
be a DTIM beacon), the critical update flag in the corresponding
link object should be reset.
For Offloaded Beacon Handling:
1. If precise control is required:
1.1 Since DTIM updates are managed by the lower layer (typically
the firmware or driver), an API will be provided to explicitly
reset the critical update flag.
1.2 The driver, upon detecting that a DTIM beacon is about to be
transmitted, can invoke this API to perform the reset.
2. If some timing inaccuracy is acceptable:
2.1 mac80211 can maintain a timer to reset the critical update
flag after a DTIM interval.
2.2 However, this approach may lead to synchronization issues, as
mac80211 cannot guarantee the exact timing of beacon
transmission handled by the hardware.
Update BPCC back to NL:
-----------------------
After the kernel increments the BPCC value, it can emit a netlink event
containing the updated BPCC value. This allows hostapd to receive the
latest BPCC and include it in probe/association response frames, as
required by the specification.
This coordination ensures that all - beacon, probe response, and
association response frames reflect consistent BPCC values, maintaining
compliance with spec-defined behavior for multi-link and critical update
handling.
Counter offset handling of partner links:
-----------------------------------------
Note: This applies only in case of offloaded beacon case.
Since not all links operate with the same beacon interval, the firmware
cannot simply decrement the counter on every self-beacon transmission.
To handle this correctly:
Each BPCC counter will be associated with:
* An offset (location in the frame where the counter resides), and
* A periodicity value, indicating how often the counter should be
decremented.
The firmware is expected to:
* Track the number of self-beacon transmissions per link.
* Decrement the counter only after the specified number of
transmissions, as defined by the periodicity value.
* This ensures that counter updates are aligned with each link’s
individual beacon schedule, maintaining spec compliance in multi-link
scenarios.
Complexities:
-------------
When adding elements in per STA profile, the element length might exceed
hence fragmentation needs to be handled properly.
Max Channel Switch Time element handling is still tricky since this field's
value starts decrementing once counter reaches 0 and before beacon comes up
in next new channel.
Alternative approach:
---------------------
memcmp vs hashing
=================
In the section where memcmp() is used to detect changes in beacon elements
(to determine if a critical update is needed), this logic could
alternatively be handled at the hostapd level.
Since hostapd does not retain the previous beacon frame, it cannot perform
a direct memory comparison. However, it can compute and store hashes of the
required elements during beacon formation. On subsequent updates, it can
compare the new hashes with the previously stored ones to detect changes.
If any element's content has changed, hostapd can:
1. Include this information in a new netlink attribute, indicating which
elements have changed.
2. Pass this to the kernel, allowing mac80211 to make informed decisions
about setting the Critical Update (CU) bit.
This approach offloads the comparison logic from the kernel and leverages
hostapd’s control over beacon generation, while still respecting the timing
and structural constraints of the beacon update process.
Only this comparison—and consequently the signaling of the critical update
can be offloaded to hostapd if needed. All other operations must remain in
the kernel to meet strict timing requirements.
References:
-----------
Spec: IEEE P802.11be/D7.0, August 2024
[1]: The elements which are considered for critical update are classified
in section 11.2.3.14 TIM Broadcast.
[2]: BPCC stands for BSS Parameters Change Count
[3]: AH.7 Example of critical update operation and AH.8 Example of
advertising quieting or channel switching information of a link on
another link.
[4]: 9.4.1.4 Capability Information field
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC] Critical Update handling in the kernel
2025-07-17 4:55 [DESIGN RFC] Critical Update handling in the kernel Aditya Kumar Singh
@ 2025-07-22 14:42 ` Johannes Berg
2025-07-23 4:34 ` Aditya Kumar Singh
2025-07-24 8:48 ` Ping-Ke Shih
0 siblings, 2 replies; 8+ messages in thread
From: Johannes Berg @ 2025-07-22 14:42 UTC (permalink / raw)
To: Aditya Kumar Singh
Cc: linux-wireless, ath12k, Ping-Ke Shih, Lorenzo Bianconi, Ryder Lee
Hi,
Thanks for writing this up! I really think Realtek and Mediatek should
comment - CC'ing some folks.
> "What about vendors whose firmware does not support this functionality?"
> "What about mac80211_hwsim? How this is supposed to work with
> mac80211_hwsim?"
I really like the hwsim part because we really can't even test the
client side right now ...
> ===========================================================================
> OPEN QUESTIONS
> ===========================================================================
> Before we move forward with implementation, we'd like to confirm whether
> the proposed design looks sound. Are there any concerns or potential issues
> we should be aware of?
>
> Out of curiosity, we're also interested in understanding how other vendors
> are currently handling this feature in their downstream drivers. Is it
> typically offloaded to firmware, or is the logic implemented in the kernel?
> Just want to confirm whether all this will be used only by mac80211_hwsim
> or will there be any actual users?
I think Ping-Ke previously indicated that they were planning to do
things host side? I'm not super familiar with the timing constraints
though, so I'm not sure what that might imply.
> Critical Update is a mechanism where, if a BSS parameter changes on one of
> the links within a Multi-Link Device (MLD), that change is also signaled in
> the beacons/probe response of its partner links. This allows the multi-link
> client to be proactively informed of the update through any of the partner
> links, rather than waiting to receive the updated beacon/probe responses
> from the affected link itself.
FWIW we also have some client side code for it already. It's probably
broken ;-)
> This ensures that multi-link clients monitoring Link B can be promptly
> informed of the change on Link A, without needing to wait for Link A’s next
> beacon.
Btw, you make this a lot about "without needing to wait" and the whole
timing, but another, I'd maybe even argue more important, aspect of this
is that they don't have to be receiving the beacon at all. For example
for EMLSR clients, or clients that aren't even active at all on a given
link, they might not/cannot see the beacons for all links at all, even
if they're nominally connected on those links.
> ===========================================================================
> DESIGN PROPOSAL
> ===========================================================================
>
> Assumptions:
> ------------
> The critical update procedure is highly timing-sensitive.
There are two aspects here that I feel maybe you're conflating a bit. On
the one hand, yes, some of it needs to have the precise information for
the counters. OTOH, some of it is really not _that_ timing critical,
e.g. whether or not you actually get the information live at exactly the
right time. Though of course a frame that's transmitted after a beacon
that advertised CSA should not suddenly _not_ advertise it even cross-
link.
> This design introduces additional computational overhead, which could
> potentially delay beacon processing. Since not all mac80211 drivers may
> prefer this behavior, introduce a new extended feature flag -
> CRITICAL_UPDATE_SELF_MANAGED. mac80211 will NOT perform these extra
> computations if the driver advertises this feature support.
Fair.
> Parsing the beacon update:
> --------------------------
> During the ieee80211_assign_beacon() call (where link->u.ap.beacon is
> updated whenever the beacon content is initially set using
> ieee80211_start_ap(), modified through ieee80211_change_beacon(), or
> changed as a result of channel or color switch events) -
>
> 1. Store the new beacon data in a new pointer, following the usual flow.
> 2. Parse the beacon (using the head and tail pointers) and record the
> starting offsets of each required Element (earlier referred to as IE i.e
> Information element) in an array, indexed by element id or extended
> element id. This is done per link object.
> 3. If a previous beacon exists:
> 3.1 For each element related to the critical update, perform a memcmp()
> to detect changes compared to the previous contents.
> 3.2 If any such element has changed, set the critical update flag in
> some link-level object (e.g., link_conf). (this is for the affected
> link)
> 3.2.1 At the same time, set the critical update flag for all
> partner links as well in the same object.
> 3.3 Increment the BPCC[2] value (modulo 256 excluding 255) for the
(as an aside, I think this is really funny - it's obviously the same as
"modulo 255", but I guess I can also see why they worded it that way...)
> current link.
Wouldn't it be far simpler to have hostapd indicate the critical update,
and even the BPCC value? It also has to include BPCC in RNR and other
fields, do we really want to _parse_ all of that and update all those
values?! Seems iffy at best.
> 4. If critical update flag got set in previous step for partner links, call
> link_info_changed() with CHANGED_BEACON to notify lower layer that
> beacon has changed. This applies only in case when beacon is offloaded
> to firmware. In case beacon is given to driver at every TBTT, there is
> no need to notify since at next TBTT, driver will fetch the latest
> beacon anyways.
Sure.
> Forming the new beacon:
> -----------------------
> In the __ieee80211_beacon_get() function, where the beacon SKBs are
> constructed:
>
> 1. Allow the existing logic to generate all beacon SKBs (including multiple
> SKBs in the case of MBSSID-EMA).
> 2. For each beacon SKB:
> 2.1 Parse the RNR (Reduced Neighbor Report) element.
> 2.1.1 For each TBTT Info entry:
> 2.1.1.1 Extract the BSSID
> 2.1.1.2 Retrieve the corresponding link sdata from BSSID
> 2.1.1.3 fetch the latest BPCC value.
> 2.1.1.4 Update the frame with this latest BPCC value.
Yeah, I really don't like that... Do you really do that in firmware
today? That sounds all really painful.
> 2.2 Parse the MBSSID profile element.
> 2.2.1 For each non-Tx profile:
> 2.2.1.1 Extract the BSSID
> 2.2.1.2 Retrieve the corresponding link sdata from BSSID
> 2.2.1.3 If the critical update flag is set in link object, set
> the CU (Critical Update) bit in the capability element.
> 2.2.1.4 Set non_tx_update = true.
> 2.3 Parse the multi-link element.
> 2.3.1 For the self link (already known), fetch the latest BPCC
> value.
> 2.3.2 Update the frame with this BPCC value.
> 2.4 Update the capability element in the SKB:
> 2.4.1 If the critical update flag is set, set the CU bit.
> 2.4.2 If non_tx_update == true, also set the non-Tx CU bit.
How much of that can we let hostapd do?
> This mechanism sufficiently handles critical updates due to modifications
> of existing elements (elements related to the critical update which are
> already present in the beacon and just one or more field is/are changing
> its value). However, in the case of new element inclusion (elements related
> to the critical update which are not alread present in the beacon, but is
> getting added from next beacon), additional handling is required.
> Specifically, the newly included elements related to the critical update
> must be added to the per-STA profile within the Basic Multi-Link Element
> (BMLE) [3].
That seems almost like an over-optimisation? If I'm reading this
correctly, this is basically describing a situation like this
(x indicates a beacon TX)
link 1 x x x x x x x
link 2 x x x x x x x
^ link 1 starts channel switching
(after its own bcn, before the next link 2 bcn)
and saying that really the next link 2 beacon will already indicate the
link 1 beacon will be switching channel.
But is that really actually a case worth worrying about? You can always
consider it as if this had happened:
link 1 x x x x x x x
link 2 x x x x x x x
^ link 1 starts channel switching
i.e. as if link 1 had decided to do channel switch just _after_ link 2's
beacon instead.
Does that really significantly change anything? I'm not so sure?
> To achieve this:
>
> 3. Allow the existing logic to form the beacon SKB as previously defined
> (this already handles modification updates).
> 4. Maintain an extra_len variable to track any additional space required
> for including additional elements.
> 5. While parsing:
> 5.1 If critical update is going on in partner link due to inclusion of
> elements, increment extra_len accordingly.
> 5.2 The required length is determined using the eid/ext eid based
> offset maintained in each beacon data structure.
> 5.3 Since the element offset is known, and the next byte is the tag
> length, the total length is tag_len + 2 (for EID and length
> fields).
> 5.4 Account for any additional fields that may be needed (e.g.,
> sub-element ID and length in the Multi-Link IE).
> 6. Compute the new beacon size:
> new_size = current_size + extra_len
> 7. Allocate a new SKB with the updated size.
> 8. Copy the existing contents and insert the new or updated elements at the
> appropriate offsets.
> 9. Since IE offsets are cached in the beacon data structure, the entire IE
> can be copied directly without re-parsing the full beacon from other
> links.
> 10. Free the original beacon SKB.
> 11. Return the newly constructed beacon SKB.
That kind of also seems like hostapd could just update the beacons?
> DTIM beacon handling:
> ---------------------
> As per requirement [4], the Critical Update (CU) bit in the capability
> field must be cleared in the DTIM beacon.
>
> For Non-Offloaded Beacon Handling:
> 1. The function __ieee80211_beacon_add_tim() is responsible for
> updating the DTIM count.
> 2. When the DTIM count reaches 1 (indicating that the next beacon will
> be a DTIM beacon), the critical update flag in the corresponding
> link object should be reset.
>
> For Offloaded Beacon Handling:
> 1. If precise control is required:
> 1.1 Since DTIM updates are managed by the lower layer (typically
> the firmware or driver), an API will be provided to explicitly
> reset the critical update flag.
> 1.2 The driver, upon detecting that a DTIM beacon is about to be
> transmitted, can invoke this API to perform the reset.
> 2. If some timing inaccuracy is acceptable:
> 2.1 mac80211 can maintain a timer to reset the critical update
> flag after a DTIM interval.
> 2.2 However, this approach may lead to synchronization issues, as
> mac80211 cannot guarantee the exact timing of beacon
> transmission handled by the hardware.
I guess I can see where this is needed, yeah. I think I'd probably go
for 1, it's simpler for mac80211 and worst case drivers can have a
counter or something themselves and do that after pulling the DTIM
beacon from mac80211.
> Update BPCC back to NL:
> -----------------------
> After the kernel increments the BPCC value, it can emit a netlink event
> containing the updated BPCC value. This allows hostapd to receive the
> latest BPCC and include it in probe/association response frames, as
> required by the specification.
>
> This coordination ensures that all - beacon, probe response, and
> association response frames reflect consistent BPCC values, maintaining
> compliance with spec-defined behavior for multi-link and critical update
> handling.
Yeah not liking this too much I guess... Why can't hostapd maintain
BPCC?
> Counter offset handling of partner links:
> -----------------------------------------
> Note: This applies only in case of offloaded beacon case.
>
> Since not all links operate with the same beacon interval, the firmware
> cannot simply decrement the counter on every self-beacon transmission.
>
> To handle this correctly:
> Each BPCC counter will be associated with:
> * An offset (location in the frame where the counter resides), and
> * A periodicity value, indicating how often the counter should be
> decremented.
>
> The firmware is expected to:
> * Track the number of self-beacon transmissions per link.
> * Decrement the counter only after the specified number of
> transmissions, as defined by the periodicity value.
> * This ensures that counter updates are aligned with each link’s
> individual beacon schedule, maintaining spec compliance in multi-link
> scenarios.
True. Although I expect some devices might simply prevent different
beacon intervals.
> Complexities:
> -------------
> When adding elements in per STA profile, the element length might exceed
> hence fragmentation needs to be handled properly.
We have fragmentation but all this parsing means also we need
_defragmentation_ first, which is awkward?
> memcmp vs hashing
> =================
> In the section where memcmp() is used to detect changes in beacon elements
> (to determine if a critical update is needed), this logic could
> alternatively be handled at the hostapd level.
Yeah sounds better to me :P
> Since hostapd does not retain the previous beacon frame, it cannot perform
> a direct memory comparison. However, it can compute and store hashes of the
> required elements during beacon formation. On subsequent updates, it can
> compare the new hashes with the previously stored ones to detect changes.
It doesn't necessarily even have to do that - it could also track
internally when it made changes. Like when something actually starts a
channel switch. Or color switch maybe, or something.
johannes
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC] Critical Update handling in the kernel
2025-07-22 14:42 ` Johannes Berg
@ 2025-07-23 4:34 ` Aditya Kumar Singh
2025-07-23 10:33 ` Johannes Berg
2025-07-24 8:48 ` Ping-Ke Shih
1 sibling, 1 reply; 8+ messages in thread
From: Aditya Kumar Singh @ 2025-07-23 4:34 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, ath12k, Ping-Ke Shih, Lorenzo Bianconi, Ryder Lee
On 7/22/2025 8:12 PM, Johannes Berg wrote:
> Hi,
>
> Thanks for writing this up! I really think Realtek and Mediatek should
> comment - CC'ing some folks.
>
>> "What about vendors whose firmware does not support this functionality?"
>> "What about mac80211_hwsim? How this is supposed to work with
>> mac80211_hwsim?"
>
> I really like the hwsim part because we really can't even test the
> client side right now ...
>
>> ===========================================================================
>> OPEN QUESTIONS
>> ===========================================================================
>> Before we move forward with implementation, we'd like to confirm whether
>> the proposed design looks sound. Are there any concerns or potential issues
>> we should be aware of?
>>
>> Out of curiosity, we're also interested in understanding how other vendors
>> are currently handling this feature in their downstream drivers. Is it
>> typically offloaded to firmware, or is the logic implemented in the kernel?
>> Just want to confirm whether all this will be used only by mac80211_hwsim
>> or will there be any actual users?
>
> I think Ping-Ke previously indicated that they were planning to do
> things host side? I'm not super familiar with the timing constraints
> though, so I'm not sure what that might imply.
>
>> Critical Update is a mechanism where, if a BSS parameter changes on one of
>> the links within a Multi-Link Device (MLD), that change is also signaled in
>> the beacons/probe response of its partner links. This allows the multi-link
>> client to be proactively informed of the update through any of the partner
>> links, rather than waiting to receive the updated beacon/probe responses
>> from the affected link itself.
>
> FWIW we also have some client side code for it already. It's probably
> broken ;-)
Yes, I’ve seen that. I’m not entirely sure if it’s broken, but it does
seem related to CSA parsing from the link—there is code handling that.
If anything turns out to be broken, we can fix it.
>
>> This ensures that multi-link clients monitoring Link B can be promptly
>> informed of the change on Link A, without needing to wait for Link A’s next
>> beacon.
>
> Btw, you make this a lot about "without needing to wait" and the whole
> timing, but another, I'd maybe even argue more important, aspect of this
> is that they don't have to be receiving the beacon at all. For example
> for EMLSR clients, or clients that aren't even active at all on a given
> link, they might not/cannot see the beacons for all links at all, even
> if they're nominally connected on those links.
Yes, that's true as well! I just wanted to keep the context
straightforward and avoid bringing in another feature that might cause
confusion. But you're absolutely right.
>
>> ===========================================================================
>> DESIGN PROPOSAL
>> ===========================================================================
>>
>> Assumptions:
>> ------------
>> The critical update procedure is highly timing-sensitive.
>
> There are two aspects here that I feel maybe you're conflating a bit. On
> the one hand, yes, some of it needs to have the precise information for
> the counters. OTOH, some of it is really not _that_ timing critical,
> e.g. whether or not you actually get the information live at exactly the
> right time. Though of course a frame that's transmitted after a beacon
> that advertised CSA should not suddenly _not_ advertise it even cross-
> link.
Absolutely! We acknowledge that achieving the ideal case may not be
possible. Keeping the logic in the kernel brings us closer to the
expected behavior, whereas shifting it to hostapd would likely result in
a much larger deviation.
>
>> This design introduces additional computational overhead, which could
>> potentially delay beacon processing. Since not all mac80211 drivers may
>> prefer this behavior, introduce a new extended feature flag -
>> CRITICAL_UPDATE_SELF_MANAGED. mac80211 will NOT perform these extra
>> computations if the driver advertises this feature support.
>
> Fair.
>
>> Parsing the beacon update:
>> --------------------------
>> During the ieee80211_assign_beacon() call (where link->u.ap.beacon is
>> updated whenever the beacon content is initially set using
>> ieee80211_start_ap(), modified through ieee80211_change_beacon(), or
>> changed as a result of channel or color switch events) -
>>
>> 1. Store the new beacon data in a new pointer, following the usual flow.
>> 2. Parse the beacon (using the head and tail pointers) and record the
>> starting offsets of each required Element (earlier referred to as IE i.e
>> Information element) in an array, indexed by element id or extended
>> element id. This is done per link object.
>> 3. If a previous beacon exists:
>> 3.1 For each element related to the critical update, perform a memcmp()
>> to detect changes compared to the previous contents.
>> 3.2 If any such element has changed, set the critical update flag in
>> some link-level object (e.g., link_conf). (this is for the affected
>> link)
>> 3.2.1 At the same time, set the critical update flag for all
>> partner links as well in the same object.
>> 3.3 Increment the BPCC[2] value (modulo 256 excluding 255) for the
>
> (as an aside, I think this is really funny - it's obviously the same as
> "modulo 255", but I guess I can also see why they worded it that way...)
>
>
>> current link.
>
> Wouldn't it be far simpler to have hostapd indicate the critical update,
> and even the BPCC value? It also has to include BPCC in RNR and other
> fields, do we really want to _parse_ all of that and update all those
> values?! Seems iffy at best.
The challenge is that if hostapd takes on this task, it would need to
send updates for all partner links. Theoretically, this could result in
up to 15 beacon NLs being transmitted. Processing these NLs and updating
the beacons would already be time-consuming. On top of that, managing
the additional offsets required to update the counters adds another
layer of complexity.
OTOH, the proposed design just takes 1 NL update and rest it does
automatically what is needed which will be less time consuming than
multiple NL commands flow.
>
>> 4. If critical update flag got set in previous step for partner links, call
>> link_info_changed() with CHANGED_BEACON to notify lower layer that
>> beacon has changed. This applies only in case when beacon is offloaded
>> to firmware. In case beacon is given to driver at every TBTT, there is
>> no need to notify since at next TBTT, driver will fetch the latest
>> beacon anyways.
>
> Sure.
>
>
>> Forming the new beacon:
>> -----------------------
>> In the __ieee80211_beacon_get() function, where the beacon SKBs are
>> constructed:
>>
>> 1. Allow the existing logic to generate all beacon SKBs (including multiple
>> SKBs in the case of MBSSID-EMA).
>> 2. For each beacon SKB:
>> 2.1 Parse the RNR (Reduced Neighbor Report) element.
>> 2.1.1 For each TBTT Info entry:
>> 2.1.1.1 Extract the BSSID
>> 2.1.1.2 Retrieve the corresponding link sdata from BSSID
>> 2.1.1.3 fetch the latest BPCC value.
>> 2.1.1.4 Update the frame with this latest BPCC value.
>
> Yeah, I really don't like that... Do you really do that in firmware
> today? That sounds all really painful.
Not exactly this way, but yeah firmware does all this in offloaded case.
>
>> 2.2 Parse the MBSSID profile element.
>> 2.2.1 For each non-Tx profile:
>> 2.2.1.1 Extract the BSSID
>> 2.2.1.2 Retrieve the corresponding link sdata from BSSID
>> 2.2.1.3 If the critical update flag is set in link object, set
>> the CU (Critical Update) bit in the capability element.
>> 2.2.1.4 Set non_tx_update = true.
>> 2.3 Parse the multi-link element.
>> 2.3.1 For the self link (already known), fetch the latest BPCC
>> value.
>> 2.3.2 Update the frame with this BPCC value.
>> 2.4 Update the capability element in the SKB:
>> 2.4.1 If the critical update flag is set, set the CU bit.
>> 2.4.2 If non_tx_update == true, also set the non-Tx CU bit.
>
> How much of that can we let hostapd do?
hostapd forms beacon so it can do all of this. The only bottleneck is
communicating all link's beacon update sequentially via NL. And if
another update happens in the meantime - for example link A started CSA
and then link B also started CSA, these will pile up the NL socket queue
with beacon updates.
>
>> This mechanism sufficiently handles critical updates due to modifications
>> of existing elements (elements related to the critical update which are
>> already present in the beacon and just one or more field is/are changing
>> its value). However, in the case of new element inclusion (elements related
>> to the critical update which are not alread present in the beacon, but is
>> getting added from next beacon), additional handling is required.
>> Specifically, the newly included elements related to the critical update
>> must be added to the per-STA profile within the Basic Multi-Link Element
>> (BMLE) [3].
>
> That seems almost like an over-optimisation? If I'm reading this
> correctly, this is basically describing a situation like this
>
> (x indicates a beacon TX)
>
> link 1 x x x x x x x
> link 2 x x x x x x x
>
> ^ link 1 starts channel switching
> (after its own bcn, before the next link 2 bcn)
>
> and saying that really the next link 2 beacon will already indicate the
> link 1 beacon will be switching channel.
>
> But is that really actually a case worth worrying about? You can always
> consider it as if this had happened:
>
> link 1 x x x x x x x
> link 2 x x x x x x x
>
> ^ link 1 starts channel switching
>
> i.e. as if link 1 had decided to do channel switch just _after_ link 2's
> beacon instead.
>
> Does that really significantly change anything? I'm not so sure?
You're right, but that's not quite what the original text is trying to
convey.
There are generally two types of critical updates:
1. Adding a new element, such as CSA or CCA.
2. Modifying an existing element, like VHT/HE/EHT Operation IE, TWT, etc.
In the second case, forming the beacon is relatively
straightforward—only the BPCC and the critical update flag need to be
set. However, in the first case, it's more complex. You need to insert
the new elements (e.g., CSA IE) into the per-STA profile of the affected
link within the reporting link, as shown in the earlier diagram.
-----
Link A started CSA and during CSA, the beaconing would look like -
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Link A's beacon │ │ Link B's beacon │
│ │ │ │
│┌────────────────────────────┐│ │┌────────────────────────────┐│
││Capabilities Info: ││ ││Capabilities Info: ││
││ BIT 6: CU Bit: True ││ ││ BIT 6: CU Bit: True ││
│└────────────────────────────┘│ │└────────────────────────────┘│
│┌────────────────────────────┐│ │ ...... │
││CSA: ││ │┌────────────────────────────┐│
││ CS Count: 5 ││ ││RNR Element: ││
│└────────────────────────────┘│ ││ TBTT INFO: ││
│...... │ ││ MLD INFO: ││
│┌────────────────────────────┐│ ││ LINK ID: A ││
││RNR Element: ││ ││ BPCC: 2 ││
││ TBTT INFO: ││ │└────────────────────────────┘│
││ MLD INFO: ││ │...... │
││ LINK ID: B ││ │┌────────────────────────────┐│
││ BPCC: 1 ││ ││MULTI LINK Element: ││
│└────────────────────────────┘│ ││ COMMON INFO: ││
│...... │ ││ LINK ID: B ││
│┌────────────────────────────┐│ ││ BPCC: 1 ││
││MULTI LINK Element: ││ ││ ││
││ COMMON INFO: ││ ││ Basic STA profile count: 1││
││ LINK ID: A ││ ││ Per STA Profile: ││
││ BPCC: 2 ││ ││ Link ID: A ││
││ ││ ││ ┌─────────────────────┐││
││ Basic STA profile count: 0││ ││ │CSA: *THIS ONE* │││
│└────────────────────────────┘│ ││ │ CS Count: 5 │││
└──────────────────────────────┘ ││ └─────────────────────┘││
│└────────────────────────────┘│
│...... │
└──────────────────────────────┘
(See the CSA element (marked with *THIS ONE* ) in link B's beacon due to
link A doing CSA).
-------
So to handle this case (additional of new element), the below steps are
additionally required on top of what was already explained above.
Does this make sense now?
>> To achieve this:
>>
>> 3. Allow the existing logic to form the beacon SKB as previously defined
>> (this already handles modification updates).
>> 4. Maintain an extra_len variable to track any additional space required
>> for including additional elements.
>> 5. While parsing:
>> 5.1 If critical update is going on in partner link due to inclusion of
>> elements, increment extra_len accordingly.
>> 5.2 The required length is determined using the eid/ext eid based
>> offset maintained in each beacon data structure.
>> 5.3 Since the element offset is known, and the next byte is the tag
>> length, the total length is tag_len + 2 (for EID and length
>> fields).
>> 5.4 Account for any additional fields that may be needed (e.g.,
>> sub-element ID and length in the Multi-Link IE).
>> 6. Compute the new beacon size:
>> new_size = current_size + extra_len
>> 7. Allocate a new SKB with the updated size.
>> 8. Copy the existing contents and insert the new or updated elements at the
>> appropriate offsets.
>> 9. Since IE offsets are cached in the beacon data structure, the entire IE
>> can be copied directly without re-parsing the full beacon from other
>> links.
>> 10. Free the original beacon SKB.
>> 11. Return the newly constructed beacon SKB.
>
> That kind of also seems like hostapd could just update the beacons?
Yes it can. Only thing is multiple NL beacon updates.
>
>> DTIM beacon handling:
>> ---------------------
>> As per requirement [4], the Critical Update (CU) bit in the capability
>> field must be cleared in the DTIM beacon.
>>
>> For Non-Offloaded Beacon Handling:
>> 1. The function __ieee80211_beacon_add_tim() is responsible for
>> updating the DTIM count.
>> 2. When the DTIM count reaches 1 (indicating that the next beacon will
>> be a DTIM beacon), the critical update flag in the corresponding
>> link object should be reset.
>>
>> For Offloaded Beacon Handling:
>> 1. If precise control is required:
>> 1.1 Since DTIM updates are managed by the lower layer (typically
>> the firmware or driver), an API will be provided to explicitly
>> reset the critical update flag.
>> 1.2 The driver, upon detecting that a DTIM beacon is about to be
>> transmitted, can invoke this API to perform the reset.
>> 2. If some timing inaccuracy is acceptable:
>> 2.1 mac80211 can maintain a timer to reset the critical update
>> flag after a DTIM interval.
>> 2.2 However, this approach may lead to synchronization issues, as
>> mac80211 cannot guarantee the exact timing of beacon
>> transmission handled by the hardware.
>
> I guess I can see where this is needed, yeah. I think I'd probably go
> for 1, it's simpler for mac80211 and worst case drivers can have a
> counter or something themselves and do that after pulling the DTIM
> beacon from mac80211.
sure.
>
>> Update BPCC back to NL:
>> -----------------------
>> After the kernel increments the BPCC value, it can emit a netlink event
>> containing the updated BPCC value. This allows hostapd to receive the
>> latest BPCC and include it in probe/association response frames, as
>> required by the specification.
>>
>> This coordination ensures that all - beacon, probe response, and
>> association response frames reflect consistent BPCC values, maintaining
>> compliance with spec-defined behavior for multi-link and critical update
>> handling.
>
> Yeah not liking this too much I guess... Why can't hostapd maintain
> BPCC?
It can only when everything is fully handled by hostapd. Otherwise
kernel should be owner of having the latest value. It can report the
latest value to hostap upon any change.
>
>> Counter offset handling of partner links:
>> -----------------------------------------
>> Note: This applies only in case of offloaded beacon case.
>>
>> Since not all links operate with the same beacon interval, the firmware
>> cannot simply decrement the counter on every self-beacon transmission.
>>
>> To handle this correctly:
>> Each BPCC counter will be associated with:
>> * An offset (location in the frame where the counter resides), and
>> * A periodicity value, indicating how often the counter should be
>> decremented.
>>
>> The firmware is expected to:
>> * Track the number of self-beacon transmissions per link.
>> * Decrement the counter only after the specified number of
>> transmissions, as defined by the periodicity value.
>> * This ensures that counter updates are aligned with each link’s
>> individual beacon schedule, maintaining spec compliance in multi-link
>> scenarios.
>
> True. Although I expect some devices might simply prevent different
> beacon intervals.
True, but in case if not, still it can be handled I guess.
>
>> Complexities:
>> -------------
>> When adding elements in per STA profile, the element length might exceed
>> hence fragmentation needs to be handled properly.
>
> We have fragmentation but all this parsing means also we need
> _defragmentation_ first, which is awkward?
I think de-fragmentation is already supported ? If not, we will have to
add it to support it.
>
>> memcmp vs hashing
>> =================
>> In the section where memcmp() is used to detect changes in beacon elements
>> (to determine if a critical update is needed), this logic could
>> alternatively be handled at the hostapd level.
>
> Yeah sounds better to me :P
Okay so only the link which is undergoing a change, hostapd will signal
to kernel about critical update? Rest kernel will handled parsing and
updating the partner links as per the need?
>
>> Since hostapd does not retain the previous beacon frame, it cannot perform
>> a direct memory comparison. However, it can compute and store hashes of the
>> required elements during beacon formation. On subsequent updates, it can
>> compare the new hashes with the previously stored ones to detect changes.
>
> It doesn't necessarily even have to do that - it could also track
> internally when it made changes. Like when something actually starts a
> channel switch. Or color switch maybe, or something.
True when adding, it can do easily. But when modifying, it has to have
some older value to compare with.
--
Aditya
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC] Critical Update handling in the kernel
2025-07-23 4:34 ` Aditya Kumar Singh
@ 2025-07-23 10:33 ` Johannes Berg
2025-07-25 10:28 ` Aditya Kumar Singh
2025-08-22 4:53 ` Aditya Kumar Singh
0 siblings, 2 replies; 8+ messages in thread
From: Johannes Berg @ 2025-07-23 10:33 UTC (permalink / raw)
To: Aditya Kumar Singh
Cc: linux-wireless, ath12k, Ping-Ke Shih, Lorenzo Bianconi, Ryder Lee
On Wed, 2025-07-23 at 10:04 +0530, Aditya Kumar Singh wrote:
> > FWIW we also have some client side code for it already. It's probably
> > broken ;-)
>
> Yes, I’ve seen that. I’m not entirely sure if it’s broken, but it does
> seem related to CSA parsing from the link—there is code handling that.
> If anything turns out to be broken, we can fix it.
We just never tested it well, that's why I said that. Sure, if it's
broken we'll fix it.
> > > Assumptions:
> > > ------------
> > > The critical update procedure is highly timing-sensitive.
> >
> > There are two aspects here that I feel maybe you're conflating a bit. On
> > the one hand, yes, some of it needs to have the precise information for
> > the counters. OTOH, some of it is really not _that_ timing critical,
> > e.g. whether or not you actually get the information live at exactly the
> > right time. Though of course a frame that's transmitted after a beacon
> > that advertised CSA should not suddenly _not_ advertise it even cross-
> > link.
>
> Absolutely! We acknowledge that achieving the ideal case may not be
> possible. Keeping the logic in the kernel brings us closer to the
> expected behavior, whereas shifting it to hostapd would likely result in
> a much larger deviation.
Fully in hostapd I would agree, but not sure it should be fully in the
kernel as you propose either? We have some middle ground for CSA today
with just the counter updates, rather than creating the elements and all
that. Not sure we couldn't/shouldn't replicate that?
> > Wouldn't it be far simpler to have hostapd indicate the critical update,
> > and even the BPCC value? It also has to include BPCC in RNR and other
> > fields, do we really want to _parse_ all of that and update all those
> > values?! Seems iffy at best.
>
> The challenge is that if hostapd takes on this task, it would need to
> send updates for all partner links. Theoretically, this could result in
> up to 15 beacon NLs being transmitted. Processing these NLs and updating
> the beacons would already be time-consuming.
Is it though? I mean, where do you see the bottleneck? Locking wise it's
just the wiphy lock that shouldn't be contended, netlink isn't the most
inefficient API ... sure there are roundtrips involved, but this seems a
bit "handwavy" to me.
We could also always have new per-link attributes for the beacon
template updates for other links so it doesn't require full commands but
just updates the beacon tail (probably only that?) of other links in the
same operation?
> On top of that, managing
> the additional offsets required to update the counters adds another
> layer of complexity.
>
> OTOH, the proposed design just takes 1 NL update and rest it does
> automatically what is needed which will be less time consuming than
> multiple NL commands flow.
I still don't buy the "time consuming" thing, but I agree that managing
the counter locations would be more difficult. OTOH, that's a list of
counters per link, so it's not _that_ much complexity?
I really don't like the parsing in kernel for two reasons:
1) it's a lot of complexity that would never exist at all when hostapd
gives the data because it's building it, it doesn't need to parse
2) less importantly, I also think it ossifies things since the kernel
would need updates for even minor changes in the layout or elements
(this of course already being true for FW based solutions)
> > > 2.2 Parse the MBSSID profile element.
> > > 2.2.1 For each non-Tx profile:
> > > 2.2.1.1 Extract the BSSID
> > > 2.2.1.2 Retrieve the corresponding link sdata from BSSID
> > > 2.2.1.3 If the critical update flag is set in link object, set
> > > the CU (Critical Update) bit in the capability element.
> > > 2.2.1.4 Set non_tx_update = true.
> > > 2.3 Parse the multi-link element.
> > > 2.3.1 For the self link (already known), fetch the latest BPCC
> > > value.
> > > 2.3.2 Update the frame with this BPCC value.
> > > 2.4 Update the capability element in the SKB:
> > > 2.4.1 If the critical update flag is set, set the CU bit.
> > > 2.4.2 If non_tx_update == true, also set the non-Tx CU bit.
> >
> > How much of that can we let hostapd do?
>
> hostapd forms beacon so it can do all of this. The only bottleneck is
> communicating all link's beacon update sequentially via NL. And if
> another update happens in the meantime - for example link A started CSA
> and then link B also started CSA, these will pile up the NL socket queue
> with beacon updates.
I do wonder if this is a practical concern? And if you have seen this in
practice then where does the bottleneck come from?
But it can also be side-stepped by batching the operations and not doing
a full update like I wrote above.
So I'm not sure from a design perspective for mac80211 we should let it
be constrained by this. That doesn't mean there aren't other reasons for
the design to go either way, but we can work around this one (if it even
is an issue.)
> > > This mechanism sufficiently handles critical updates due to modifications
> > > of existing elements (elements related to the critical update which are
> > > already present in the beacon and just one or more field is/are changing
> > > its value). However, in the case of new element inclusion (elements related
> > > to the critical update which are not alread present in the beacon, but is
> > > getting added from next beacon), additional handling is required.
> > > Specifically, the newly included elements related to the critical update
> > > must be added to the per-STA profile within the Basic Multi-Link Element
> > > (BMLE) [3].
[snip timing explanation]
> You're right, but that's not quite what the original text is trying to
> convey.
OK, sorry, I misunderstood then.
> There are generally two types of critical updates:
> 1. Adding a new element, such as CSA or CCA.
> 2. Modifying an existing element, like VHT/HE/EHT Operation IE, TWT, etc.
>
> In the second case, forming the beacon is relatively
> straightforward—only the BPCC and the critical update flag need to be
> set. However, in the first case, it's more complex. You need to insert
> the new elements (e.g., CSA IE) into the per-STA profile of the affected
> link within the reporting link, as shown in the earlier diagram.
Right, of course.
> So to handle this case (additional of new element), the below steps are
> additionally required on top of what was already explained above.
>
> Does this make sense now?
Maybe more? I really wasn't reading it well before, I thought it was
more about when the new elements were added, rather than the fact _that_
they need to be added.
I guess to me that was really almost the same, the beacon changes.
> > That kind of also seems like hostapd could just update the beacons?
>
> Yes it can. Only thing is multiple NL beacon updates.
OK so if you're really so worried about that, and that's the main thing,
we can add the per-link updates into a nested element in the switching-
link's nl80211 message :)
>
> > > Update BPCC back to NL:
> > > -----------------------
> > > After the kernel increments the BPCC value, it can emit a netlink event
> > > containing the updated BPCC value. This allows hostapd to receive the
> > > latest BPCC and include it in probe/association response frames, as
> > > required by the specification.
> > >
> > > This coordination ensures that all - beacon, probe response, and
> > > association response frames reflect consistent BPCC values, maintaining
> > > compliance with spec-defined behavior for multi-link and critical update
> > > handling.
> >
> > Yeah not liking this too much I guess... Why can't hostapd maintain
> > BPCC?
>
> It can only when everything is fully handled by hostapd. Otherwise
> kernel should be owner of having the latest value. It can report the
> latest value to hostap upon any change.
When is it not fully handled by hostapd though? It always decides to do
updates, no? Are you thinking there are cases where the driver
(firmware?) unilaterally changes some things (say the puncturing bitmap)
and never handshakes that with hostapd, just starts overwriting the
beacons? Maybe we have a broader architecture discussion to be had here.
> > > Complexities:
> > > -------------
> > > When adding elements in per STA profile, the element length might exceed
> > > hence fragmentation needs to be handled properly.
> >
> > We have fragmentation but all this parsing means also we need
> > _defragmentation_ first, which is awkward?
>
> I think de-fragmentation is already supported ? If not, we will have to
> add it to support it.
It is, generally, but it's completely separate in terms of memory
handling etc. so it's not that simple.
> > > memcmp vs hashing
> > > =================
> > > In the section where memcmp() is used to detect changes in beacon elements
> > > (to determine if a critical update is needed), this logic could
> > > alternatively be handled at the hostapd level.
> >
> > Yeah sounds better to me :P
>
> Okay so only the link which is undergoing a change, hostapd will signal
> to kernel about critical update? Rest kernel will handled parsing and
> updating the partner links as per the need?
I still don't like the parsing though. Like I said above, that's a lot
of complexity that simply doesn't even exist when hostapd controls all
the updates.
I really would have envisioned this much more along the lines of having
hostapd start the channel switch (WLOG on link 1 out of links 1 and 2)
with an nl80211 message that has:
- post-switch beacon for link 1
- during-switch beacon for link 1
- CSA counter offsets for CSA, eCSA, etc. elements
- post-switch beacon for link 2 (?)
- during-switch beacon for link 2
- CSA counter offsets for link 1's CSA counter
(for all the per-STA profile link 1 elements)
isn't that pretty much it? All the BPCC is well-contained within that
and maintained by hostapd.
I'll agree that this limits to only doing a single channel switch at a
time across the whole MLD, but maybe that's not the most problematic
thing?
OK I guess I'll have to think about this more ...
johannes
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [DESIGN RFC] Critical Update handling in the kernel
2025-07-22 14:42 ` Johannes Berg
2025-07-23 4:34 ` Aditya Kumar Singh
@ 2025-07-24 8:48 ` Ping-Ke Shih
2025-09-04 14:24 ` Jeff Johnson
1 sibling, 1 reply; 8+ messages in thread
From: Ping-Ke Shih @ 2025-07-24 8:48 UTC (permalink / raw)
To: Johannes Berg, Aditya Kumar Singh
Cc: linux-wireless@vger.kernel.org, ath12k@lists.infradead.org,
Lorenzo Bianconi, Ryder Lee
Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > ===========================================================================
> > OPEN QUESTIONS
> > ===========================================================================
> > Before we move forward with implementation, we'd like to confirm whether
> > the proposed design looks sound. Are there any concerns or potential issues
> > we should be aware of?
> >
> > Out of curiosity, we're also interested in understanding how other vendors
> > are currently handling this feature in their downstream drivers. Is it
> > typically offloaded to firmware, or is the logic implemented in the kernel?
> > Just want to confirm whether all this will be used only by mac80211_hwsim
> > or will there be any actual users?
>
> I think Ping-Ke previously indicated that they were planning to do
> things host side? I'm not super familiar with the timing constraints
> though, so I'm not sure what that might imply.
Yes, Realtek vendor driver handles the feature in host driver. Having not
tested CSA and ML procedure mentioned in this discussion thread, we
are also not sure how timing constraint to evaluate if we have to implement
the feature in firmware.
Ping-Ke
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC] Critical Update handling in the kernel
2025-07-23 10:33 ` Johannes Berg
@ 2025-07-25 10:28 ` Aditya Kumar Singh
2025-08-22 4:53 ` Aditya Kumar Singh
1 sibling, 0 replies; 8+ messages in thread
From: Aditya Kumar Singh @ 2025-07-25 10:28 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, ath12k, Ping-Ke Shih, Lorenzo Bianconi, Ryder Lee
On 7/23/2025 4:03 PM, Johannes Berg wrote:
> On Wed, 2025-07-23 at 10:04 +0530, Aditya Kumar Singh wrote:
>>> FWIW we also have some client side code for it already. It's probably
>>> broken ;-)
>>
>> Yes, I’ve seen that. I’m not entirely sure if it’s broken, but it does
>> seem related to CSA parsing from the link—there is code handling that.
>> If anything turns out to be broken, we can fix it.
>
> We just never tested it well, that's why I said that. Sure, if it's
> broken we'll fix it.
>
>>>> Assumptions:
>>>> ------------
>>>> The critical update procedure is highly timing-sensitive.
>>>
>>> There are two aspects here that I feel maybe you're conflating a bit. On
>>> the one hand, yes, some of it needs to have the precise information for
>>> the counters. OTOH, some of it is really not _that_ timing critical,
>>> e.g. whether or not you actually get the information live at exactly the
>>> right time. Though of course a frame that's transmitted after a beacon
>>> that advertised CSA should not suddenly _not_ advertise it even cross-
>>> link.
>>
>> Absolutely! We acknowledge that achieving the ideal case may not be
>> possible. Keeping the logic in the kernel brings us closer to the
>> expected behavior, whereas shifting it to hostapd would likely result in
>> a much larger deviation.
>
> Fully in hostapd I would agree, but not sure it should be fully in the
> kernel as you propose either? We have some middle ground for CSA today
> with just the counter updates, rather than creating the elements and all
> that. Not sure we couldn't/shouldn't replicate that?
Replication is do able but skeptical about its scaling. Discussed below
more on this.
>
>>> Wouldn't it be far simpler to have hostapd indicate the critical update,
>>> and even the BPCC value? It also has to include BPCC in RNR and other
>>> fields, do we really want to _parse_ all of that and update all those
>>> values?! Seems iffy at best.
>>
>> The challenge is that if hostapd takes on this task, it would need to
>> send updates for all partner links. Theoretically, this could result in
>> up to 15 beacon NLs being transmitted. Processing these NLs and updating
>> the beacons would already be time-consuming.
>
> Is it though? I mean, where do you see the bottleneck? Locking wise it's
> just the wiphy lock that shouldn't be contended, netlink isn't the most
> inefficient API ... sure there are roundtrips involved, but this seems a
> bit "handwavy" to me.
>
> We could also always have new per-link attributes for the beacon
> template updates for other links so it doesn't require full commands but
> just updates the beacon tail (probably only that?) of other links in the
> same operation?
Correct. Okay so two things here -
1. Considering single beacon update with tail update for partner links.
-----------------------------------------------------------------------
In this case, the NL size is bottle neck. During MLO MBSSID, already we
are reaching around 2k bytes. Sending all tail data for all partner
links for this MLD might not fix in 4k NL buffer size.
2. Considering separate beacon update for all links
---------------------------------------------------
So here assuming 1 MLD or a few MLDs will work. But assume max MLD like
typically 16 or multiple of 16. In this case NL commands will flood.
For instance 16 3 link MLDs. Link A, B, and C. Link A started CSA.
Then,
for each MLD (0, 15):
beacon update for link A
beacon update for link B
beacon update for link C
Now for the same link A, in MLD 0th and MLD 15th, this increases lot of
time delta for CSA. MLD 0's link A will finish CSA way before MLD 15th's
link A and due to synchronization (single channel context), it can not
move to next channel.
Agree that this issue exist now as well, but it is very small since for
same iface, back back to all links are sent.
If we say lets send for all interfaces in link A first and then link B,
then may be by the time we are coming to last link (link C), CSA might
have finished?
Also, each NL will go with current CSA beacon and after CSA beacon.
Assume now link B started CSA. Then again there will be beacon updates.
So too much interleaved updates?
And if you see list of critical updates -
Inclusion of a Channel Switch Announcement element
Inclusion of an Extended Channel Switch Announcement element
Inclusion of a Quiet element
Inclusion of a Wide Bandwidth Channel Switch element
Inclusion of a Channel Switch Wrapper element
Inclusion of an Operating Mode Notification element
Inclusion of a Quiet Channel element
Insertion of a Broadcast TWT element
Insertion or removal of a Broadcast TWT Parameter Set field in a
Broadcast TWT element
Inclusion of the BSS Color Change Announcement element
Insertion of an Index Adjustment Factor field in a Multiple BSSID
Configuration element
Modification of the EDCA parameters element
Modification of the DSSS Parameter Set
Modification of the HT Operation element
Modification of the VHT Operation element
Modification of the HE Operation element
Modification of the MU EDCA Parameter Set element
Modification of the Spatial Reuse Parameter Set element
Modification of the UORA Parameter Set element
Modification of the EHT Operation element
Inclusion, modification or removal of a Transmit Power Envelope element,
if the AP is an EHT AP.
Any of these will trigger beacon updates of almost all links available
in the system.
>
>> On top of that, managing
>> the additional offsets required to update the counters adds another
>> layer of complexity.
>>
>> OTOH, the proposed design just takes 1 NL update and rest it does
>> automatically what is needed which will be less time consuming than
>> multiple NL commands flow.
>
> I still don't buy the "time consuming" thing, but I agree that managing
> the counter locations would be more difficult. OTOH, that's a list of
> counters per link, so it's not _that_ much complexity?
In normal MLO case, still manageable. But with MLO MBSSID it complicates
further. Each non-Tx profiles BMLE can also have per STA profile of its
partner and there can be offset there too along with the per STA pofile
of the Tx profile. Also, assume link A and link B both are doing CSA and
link C is the reporting link. This fellow then will have 2 offsets and
if in MBSSID, then it will have 2 * non Tx profiles number of offsets.
>
> I really don't like the parsing in kernel for two reasons:
>
> 1) it's a lot of complexity that would never exist at all when hostapd
> gives the data because it's building it, it doesn't need to parse
Fair point. But in a way if you see, hostapd still forms the beacon (the
main part) of each link. The thing which can be taken from other link
due to MLO, kernel is helping to stitch that give to driver and as well
as updating the CU/BPCC counters like it does during CSA.
> 2) less importantly, I also think it ossifies things since the kernel
> would need updates for even minor changes in the layout or elements
> (this of course already being true for FW based solutions)
Not sure if I get this clearly, but how do you say so?
The main beacon content is still formed by hostapd. Only stitching some
additional elements from other links and putting the latest values in
the desired field kernel is going to do.
>>>> 2.2 Parse the MBSSID profile element.
>>>> 2.2.1 For each non-Tx profile:
>>>> 2.2.1.1 Extract the BSSID
>>>> 2.2.1.2 Retrieve the corresponding link sdata from BSSID
>>>> 2.2.1.3 If the critical update flag is set in link object, set
>>>> the CU (Critical Update) bit in the capability element.
>>>> 2.2.1.4 Set non_tx_update = true.
>>>> 2.3 Parse the multi-link element.
>>>> 2.3.1 For the self link (already known), fetch the latest BPCC
>>>> value.
>>>> 2.3.2 Update the frame with this BPCC value.
>>>> 2.4 Update the capability element in the SKB:
>>>> 2.4.1 If the critical update flag is set, set the CU bit.
>>>> 2.4.2 If non_tx_update == true, also set the non-Tx CU bit.
>>>
>>> How much of that can we let hostapd do?
>>
>> hostapd forms beacon so it can do all of this. The only bottleneck is
>> communicating all link's beacon update sequentially via NL. And if
>> another update happens in the meantime - for example link A started CSA
>> and then link B also started CSA, these will pile up the NL socket queue
>> with beacon updates.
>
> I do wonder if this is a practical concern? And if you have seen this in
> practice then where does the bottleneck come from?
>
> But it can also be side-stepped by batching the operations and not doing
> a full update like I wrote above.
hmm okay then I guess, need to experiment both approaches and see?
Unfortunately, I don't have real data at this moment.
> So I'm not sure from a design perspective for mac80211 we should let it
> be constrained by this. That doesn't mean there aren't other reasons for
> the design to go either way, but we can work around this one (if it even
> is an issue.)
Yeah true that.
>
>>>> This mechanism sufficiently handles critical updates due to modifications
>>>> of existing elements (elements related to the critical update which are
>>>> already present in the beacon and just one or more field is/are changing
>>>> its value). However, in the case of new element inclusion (elements related
>>>> to the critical update which are not alread present in the beacon, but is
>>>> getting added from next beacon), additional handling is required.
>>>> Specifically, the newly included elements related to the critical update
>>>> must be added to the per-STA profile within the Basic Multi-Link Element
>>>> (BMLE) [3].
>
> [snip timing explanation]
>
>> You're right, but that's not quite what the original text is trying to
>> convey.
>
> OK, sorry, I misunderstood then.
>
>> There are generally two types of critical updates:
>> 1. Adding a new element, such as CSA or CCA.
>> 2. Modifying an existing element, like VHT/HE/EHT Operation IE, TWT, etc.
>>
>> In the second case, forming the beacon is relatively
>> straightforward—only the BPCC and the critical update flag need to be
>> set. However, in the first case, it's more complex. You need to insert
>> the new elements (e.g., CSA IE) into the per-STA profile of the affected
>> link within the reporting link, as shown in the earlier diagram.
>
> Right, of course.
>
>> So to handle this case (additional of new element), the below steps are
>> additionally required on top of what was already explained above.
>>
>> Does this make sense now?
>
> Maybe more? I really wasn't reading it well before, I thought it was
> more about when the new elements were added, rather than the fact _that_
> they need to be added.
>
> I guess to me that was really almost the same, the beacon changes.
:) In second case, just some offset value needs to be altered (BPCC or
CU bit) but in first, beacon is stitched from top to bottom.
>
>>> That kind of also seems like hostapd could just update the beacons?
>>
>> Yes it can. Only thing is multiple NL beacon updates.
>
> OK so if you're really so worried about that, and that's the main thing,
> we can add the per-link updates into a nested element in the switching-
> link's nl80211 message :)
Netlink buffer size might be a problem as the beacon grows. But will
have to explore further and see more on this.
>>
>>>> Update BPCC back to NL:
>>>> -----------------------
>>>> After the kernel increments the BPCC value, it can emit a netlink event
>>>> containing the updated BPCC value. This allows hostapd to receive the
>>>> latest BPCC and include it in probe/association response frames, as
>>>> required by the specification.
>>>>
>>>> This coordination ensures that all - beacon, probe response, and
>>>> association response frames reflect consistent BPCC values, maintaining
>>>> compliance with spec-defined behavior for multi-link and critical update
>>>> handling.
>>>
>>> Yeah not liking this too much I guess... Why can't hostapd maintain
>>> BPCC?
>>
>> It can only when everything is fully handled by hostapd. Otherwise
>> kernel should be owner of having the latest value. It can report the
>> latest value to hostap upon any change.
>
> When is it not fully handled by hostapd though? It always decides to do
> updates, no? Are you thinking there are cases where the driver
> (firmware?) unilaterally changes some things (say the puncturing bitmap)
> and never handshakes that with hostapd, just starts overwriting the
> beacons? Maybe we have a broader architecture discussion to be had here.
No what I meant was, if BPCC is given to hostapd, then all beacon
updates should be done by hostapd only (including partner link update).
Since then the correct value of BPCC will go out in frames.
>
>>>> Complexities:
>>>> -------------
>>>> When adding elements in per STA profile, the element length might exceed
>>>> hence fragmentation needs to be handled properly.
>>>
>>> We have fragmentation but all this parsing means also we need
>>> _defragmentation_ first, which is awkward?
>>
>> I think de-fragmentation is already supported ? If not, we will have to
>> add it to support it.
>
> It is, generally, but it's completely separate in terms of memory
> handling etc. so it's not that simple.
Oh I see.
>
>>>> memcmp vs hashing
>>>> =================
>>>> In the section where memcmp() is used to detect changes in beacon elements
>>>> (to determine if a critical update is needed), this logic could
>>>> alternatively be handled at the hostapd level.
>>>
>>> Yeah sounds better to me :P
>>
>> Okay so only the link which is undergoing a change, hostapd will signal
>> to kernel about critical update? Rest kernel will handled parsing and
>> updating the partner links as per the need?
>
> I still don't like the parsing though. Like I said above, that's a lot
> of complexity that simply doesn't even exist when hostapd controls all
> the updates.
>
>
> I really would have envisioned this much more along the lines of having
> hostapd start the channel switch (WLOG on link 1 out of links 1 and 2)
> with an nl80211 message that has:
>
> - post-switch beacon for link 1
> - during-switch beacon for link 1
> - CSA counter offsets for CSA, eCSA, etc. elements
> - post-switch beacon for link 2 (?)
> - during-switch beacon for link 2
> - CSA counter offsets for link 1's CSA counter
> (for all the per-STA profile link 1 elements)
>
> isn't that pretty much it? All the BPCC is well-contained within that
> and maintained by hostapd.
>
> I'll agree that this limits to only doing a single channel switch at a
> time across the whole MLD, but maybe that's not the most problematic
> thing?
Oh, we can impose this restriction? But this won't be backed by spec right?
>
> OK I guess I'll have to think about this more ..
--
Aditya
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC] Critical Update handling in the kernel
2025-07-23 10:33 ` Johannes Berg
2025-07-25 10:28 ` Aditya Kumar Singh
@ 2025-08-22 4:53 ` Aditya Kumar Singh
1 sibling, 0 replies; 8+ messages in thread
From: Aditya Kumar Singh @ 2025-08-22 4:53 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, ath12k, Ping-Ke Shih, Lorenzo Bianconi, Ryder Lee
[snip]
>
> I still don't like the parsing though. Like I said above, that's a lot
> of complexity that simply doesn't even exist when hostapd controls all
> the updates.
>
>
> I really would have envisioned this much more along the lines of having
> hostapd start the channel switch (WLOG on link 1 out of links 1 and 2)
> with an nl80211 message that has:
>
> - post-switch beacon for link 1
> - during-switch beacon for link 1
> - CSA counter offsets for CSA, eCSA, etc. elements
> - post-switch beacon for link 2 (?)
> - during-switch beacon for link 2
> - CSA counter offsets for link 1's CSA counter
> (for all the per-STA profile link 1 elements)
>
> isn't that pretty much it? All the BPCC is well-contained within that
> and maintained by hostapd.
>
> I'll agree that this limits to only doing a single channel switch at a
> time across the whole MLD, but maybe that's not the most problematic
> thing?
>
>
> OK I guess I'll have to think about this more ...
I've also spent some time thinking through the idea of handling frame
formation at the hostapd level and simply notifying the kernel. Here are
the key points I arrived at:
1. Using a single Netlink (NL) command:
----------------------------------------
The average beacon size is around 500 bytes. During Channel Switch
Announcement (CSA), we need to send two beacons—one for CSA and one
post-CSA resulting in approximately 1000 bytes per link. If we apply
this across all 14 additional links (MLD can have max 15 links), the
total data sent via NL becomes roughly 15,000 bytes. This is quite large
and may exceed what the NL socket buffer can reasonably handle.
2. Using multiple NL command for each link:
-------------------------------------------
In the case of a 3-link AP MLD, where Link 1 initiates a Channel Switch
Announcement (CSA), the sequence would look like this:
Link 1 starts CSA via NL command:
* csa_beacon
* CSA and ECSA offsets
* after_beacon
Link 2 beacon update via NL:
* Beacon data
* Partner offsets
* CSA and ECSA offsets
Link 3 beacon update via NL:
* Beacon data
* Partner offsets
* CSA and ECSA offsets
Once CSA is completed on Link 1, both Link 2 and Link 3 will require
another beacon update via NL to reflect the new state.
The complexity increases when, during Link 1’s ongoing CSA, either Link
2 or Link 3 initiates a CSA or a Color Change Announcement (CCA). In
such cases, Link 1 must update its beacon to include elements from Link
2 or Link 3’s per-STA profile. However, since Link 1 is already
undergoing CSA, it cannot perform a beacon update at that time, leading
to a conflict in update handling.
To keep things simple, one might suggest allowing only one Channel
Switch Announcement (CSA) at a time within an MLD. However, this
approach isn't feasible. For instance, consider a 5 GHz link that's part
of an MLD. If another link is performing a CSA and the 5 GHz link
detects radar, it must immediately initiate its own CSA and vacate the
radar channel. In such scenarios, enforcing a single CSA per MLD is
impractical and could lead to regulatory non-compliance or operational
issues.
Even if we somehow manage to address the earlier issues, a new challenge
arises with managing moving offsets and tracking which offset
corresponds to which link relative to the reporting link.
For example, consider an AP MLD with three links. Suppose Link 3
initiates a CSA. As a result, Link 2 receives a beacon update that
includes a CSA element in Link 3’s per-STA profile. Let’s assume the
counter offset for this CSA is at position 200.
Now, if Link 1 also starts a CSA, the next time Link 2’s beacon is
updated, it will iterate through all partner links from Link 0 to the
maximum. Since Link 1 comes before Link 3, its CSA element will be added
first, followed by Link 3’s. This causes Link 3’s CSA element to shift
down in the beacon, and its counter offset may now move to position 400.
This dynamic shifting of offsets makes it difficult to reliably track
which offset belongs to which link, especially when multiple CSAs are
active and beacon contents are updated frequently.
Another challenge with handling multiple NL (non-link-specific) beacon
updates is the need to wait until all beacon updates are received by the
kernel. This requires implementing a "wait for completion" mechanism.
However, since waiting indefinitely isn't practical, there must be a
timeout or fallback threshold. This introduces a few critical questions:
* What happens if one of the links fails to send its beacon update
within the timeout?
* Should the CSA proceed with the updates received so far, or should
the entire CSA process be aborted?
These decisions are non-trivial. Continuing the CSA without all updates
might lead to inconsistent behavior across links, while aborting the CSA
could delay critical operations like radar avoidance. A well-defined
policy or fallback strategy is essential to handle such partial update
scenarios gracefully.
-------------
Considering all the challenges discussed, I still believe that handling
beacon manipulation at the kernel level is the most effective approach
especially for critical updates. This method offers the best possible
way to manage the critical update feature purely through software,
ensuring reliability and consistency across links.
Let me know your thoughts on this?
--
Aditya
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [DESIGN RFC] Critical Update handling in the kernel
2025-07-24 8:48 ` Ping-Ke Shih
@ 2025-09-04 14:24 ` Jeff Johnson
0 siblings, 0 replies; 8+ messages in thread
From: Jeff Johnson @ 2025-09-04 14:24 UTC (permalink / raw)
To: Ping-Ke Shih, Johannes Berg, Aditya Kumar Singh
Cc: linux-wireless@vger.kernel.org, ath12k@lists.infradead.org,
Lorenzo Bianconi, Ryder Lee
On 7/24/2025 1:48 AM, Ping-Ke Shih wrote:
> Johannes Berg <johannes@sipsolutions.net> wrote:
>>> Before we move forward with implementation, we'd like to confirm whether
>>> the proposed design looks sound. Are there any concerns or potential issues
>>> we should be aware of?
>>>
>>> Out of curiosity, we're also interested in understanding how other vendors
>>> are currently handling this feature in their downstream drivers. Is it
>>> typically offloaded to firmware, or is the logic implemented in the kernel?
>>> Just want to confirm whether all this will be used only by mac80211_hwsim
>>> or will there be any actual users?
>>
>> I think Ping-Ke previously indicated that they were planning to do
>> things host side? I'm not super familiar with the timing constraints
>> though, so I'm not sure what that might imply.
>
> Yes, Realtek vendor driver handles the feature in host driver. Having not
> tested CSA and ML procedure mentioned in this discussion thread, we
> are also not sure how timing constraint to evaluate if we have to implement
> the feature in firmware.
Ping-Ke (and Johannes),
Have you had a chance to review Aditya's August 21 follow-up?
We'd like to move forward with our firmware-based approach (since that logic
is already shipping in our OpenWrt-based systems). Perhaps Realtek can propose
alternative host-based logic, and there can be a flag to select either
host-based or firmware-based Critical Update handling?
Thanks,
/jeff
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-09-04 14:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-17 4:55 [DESIGN RFC] Critical Update handling in the kernel Aditya Kumar Singh
2025-07-22 14:42 ` Johannes Berg
2025-07-23 4:34 ` Aditya Kumar Singh
2025-07-23 10:33 ` Johannes Berg
2025-07-25 10:28 ` Aditya Kumar Singh
2025-08-22 4:53 ` Aditya Kumar Singh
2025-07-24 8:48 ` Ping-Ke Shih
2025-09-04 14:24 ` Jeff Johnson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).