On Wed, Jul 31, 2019 at 5:53 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> John Crispin (10):
> mac80211: add support for parsing ADDBA_EXT IEs
> mac80211: add xmit rate to struct ieee80211_tx_status
> mac80211: propagate struct ieee80211_tx_status into ieee80211_tx_monitor()
> mac80211: add struct ieee80211_tx_status support to ieee80211_add_tx_radiotap_header
> mac80211: HE: add Spatial Reuse element parsing support
Hi Johannes and John,
It looks like one of the last additions pushed the stack usage over
the 1024 byte limit
for 32-bit architectures:
net/mac80211/mlme.c:4063:6: error: stack frame size of 1032 bytes in
function 'ieee80211_sta_rx_queued_mgmt' [-Werror,-Wframe-larger-than=]
struct ieee802_11_elems is fairly large, and just grew another two pointers.
When ieee80211_rx_mgmt_assoc_resp() and ieee80211_assoc_success()
are inlined into ieee80211_sta_rx_queued_mgmt(), there are three copies
of this structure, which is slightly too much.
Marking any of those functions as __noinline_for_stack would shut up the
warning but not fix the underlying issue. Silencing the warning might
be enough if there is a fairly short call chain leading up to
ieee80211_sta_rx_queued_mgmt(). Another option would be a dynamic
allocation.
Thoughts?
Arnd
