[PATCH wireless] wifi: cfg80211: Fix "no buffer space available" error in nl80211_get_station() for MLO

[Nithyanantham Paramasivam]

Hi Johannes,

I agree with your thoughts.

>From what I observed, a large sk_buff around 32 KB is allocated and
passed to nl80211_dump_station(). However, this buffer size isn’t
sufficient to accommodate all 16 links(max) when full station
statistics are included.

I also agree that splitting the dump per link within a station is a
good approach. I’ll explore this further and come back.

Thanks again for the feedback.

Best regards,
Nithy



On Wed, Sep 10, 2025 at 2:04 PM Johannes Berg <johannes at sipsolutions.net> wrote:
>
> On Fri, 2025-09-05 at 18:18 +0530, Nithyanantham Paramasivam wrote:
> > Currently, nl80211_get_station() allocates a fixed buffer size using
> > NLMSG_DEFAULT_SIZE. In multi-link scenarios - particularly when the
> > number of links exceeds two - this buffer size is often insufficient
> > to accommodate complete station statistics, resulting in "no buffer
> > space available" errors.
> >
> > To address this, modify nl80211_get_station() to return only
> > accumulated station statistics and exclude per link stats.
> >
> > Pass a new flag (link_stats) to nl80211_send_station() to control
> > the inclusion of per link statistics. This allows retaining
> > detailed output with per link data in dump commands, while
> > excluding it from other commands where it is not needed.
>
> I guess I'll apply the patch for now since it makes things _better_, but
> I'm really not convinced that it's actually sufficient, and I'm very
> tempted to throw in another patch to make it always false for 6.17.
> Convince me not to? I'll reason below:
>
> It seems to me that with many links, even for dump you could easily need
> more space than the size available for a single dump message just like
> with get, since there's no fundamental difference between the two. So it
> seems to me that not only should it be opt-in from userspace to retrieve
> the data during dump, but also there should be the ability to split the
> dump not only on a per-STA basis but also per-link within the STA, which
> requires some logic adjustments on both sides (hence the opt-in.)
>
> Especially if we start seeing more links and/or more data for each link,
> this will otherwise become an issue even in dumps.
>
> johannes