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

[Jeff Johnson]

On 9/10/2025 11:37 PM, Nithyanantham Paramasivam wrote:
> 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

Reminder:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#use-trimmed-interleaved-replies-in-email-discussions

> 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
>