Hi Johannes,
We’re encountering some challenges with memory size when including
per-link information. The size of per-link info or accumulated station
statistics is exceeding 3 KB, and with a station having 3
links(example), the total memory usage becomes approximately (3(link
info) + 1(accumulated station stats)) × 3 KB, i.e., around 12 KB .
Approaches we’ve considered:
Dynamically calculating nlmsg size for all link info
– This introduces a lot of additional code complexity.
Allocating one page (4 KB) per link
– If multiple links are configured, this could result in significant
memory usage.
– It’s also unclear how user space would handle such allocations efficiently.
Given these constraints, I’m planning to explore message
fragmentation, though it may not be trivial and could take time to
implement.
For now, I will modify the code to return only the accumulated station
statistics, excluding per-link stats, when executing the iw station
get <mac_addr> command.
Best Regards,
Nithy.
On Thu, Aug 28, 2025 at 4:23 PM Nithyanantham Paramasivam
<nithyanantham.paramasivam@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Aug 25, 2025 at 1:41 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, 2025-08-22 at 10:32 +0530, Sarika Sharma wrote:
> > > Currently, the buffer size allocated for the get_station command in
> > > nl80211_get_station is NLMSG_DEFAULT_SIZE, which, in some cases, is
> > > insufficient to send complete output to user space and results in
> > > "no buffer space available" error. This is especially evident in
> > > setups with 3 links, where the amount of station info exceeds the
> > > default allocation, leading to underflows and incomplete netlink
> > > messages.
> > >
> > > To fix this, increase the buffer size to 4096 bytes. This ensures
> > > that the nl80211_get_station() command can return complete station
> > > information for up to 3 links without allocation failure.
> > >
> > > Fixes: 82d7f841d9bd ("wifi: cfg80211: extend to embed link level statistics in NL message")
> > > Signed-off-by: Sarika Sharma <quic_sarishar@xxxxxxxxxxx>
> > > ---
> > > While this static increase is a practical short-term solution
> >
> > We haven't released this code, so we don't really need a short-term
> > solution? We could even just disable it from 6.17 instead.
> >
> > So please let's see how big a real fix would be, or maybe we revert
> > 82d7f841d9bd in 6.17 and do some other fixes for 6.18?
> >
> > johannes
> >
>
> Sure Johanes. Will allow user space to optionally request link-level statistics.
> If this option is provided, we calculate the maximum message size and include
> link-specific stats along with the existing station information. Otherwise,
> we use the standard message size to return only the default accumulated
> station stats.
>
> Best Regards,
> Nithy.
