Messages in this thread | | | Subject | Re: ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] | From | Johannes Berg <> | Date | Wed, 08 Sep 2021 09:09:04 +0200 |
| |
On Tue, 2021-09-07 at 16:14 -0700, Linus Torvalds wrote: > > The mac802.11 one seems to be due to 'struct ieee802_11_elems' being > big, and allocated on the stack. I think it's probably made worse > there with inlining, ie > > - ieee80211_sta_rx_queued_mgmt() has one copy > > - ieee80211_rx_mgmt_beacon() is possibly inlined, and has its own copy > > but even if it isn't due to that kind of duplication due to inlining, > that code is dangerous. Exactly because it has two nested stack frames > with that big structure, and they are active at the same time in the > callchain whether inlined or not. > > And it's *pointlessly* dangerous, because the 'struct ieee802_11_elems > elems' in ieee80211_sta_rx_queued_mgmt() is only used for the > IEEE80211_STYPE_ACTION case, so it is entirely disjoint from the > IEEE80211_STYPE_BEACON case, and those stack allocations simply should > not nest like that in the first place. > > Making the IEEE80211_STYPE_ACTION case be its own function - like the > other cases - and moving the struct there should fix it. Possibly a > "noinline" or two necessary to make sure that the compiler doesn't > then undo the "these two cases are disjoint" thing.
Yeah, I'm aware, and I agree. We've been looking at it every now and then. This got made worse by us actually adding a fair amount of pointers to the struct recently (in this merge window).
Ultimately, every new spec addition ends up needing to add something there, so I think ultimately we'll probably want to either dynamically allocate it somewhere (perhaps in a data structure used here already), or possibly not have this at all and just find a way to return only the bits that are interesting. Even parsing a ~1k frame (typical, max ~2k) a handful of times is probably not even worse than having this large a structure that gets filled data that's probably useless in many cases (I think the different cases all just need a subset). But not sure, I'll take a look.
johannes
| |