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