summaryrefslogtreecommitdiffstats
path: root/net/rds/recv.c
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2022-10-13 20:15:59 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-10-15 07:59:05 +0200
commitfee48f3bdd7516bb63da507213916227cf147211 (patch)
tree19b6f2d56cc2c92cc95d52bd70b6d203b8028721 /net/rds/recv.c
parent630060f1175676b9cb3a032767f20dbce93616c9 (diff)
downloadlinux-stable-fee48f3bdd7516bb63da507213916227cf147211.tar.gz
linux-stable-fee48f3bdd7516bb63da507213916227cf147211.tar.bz2
linux-stable-fee48f3bdd7516bb63da507213916227cf147211.zip
mac80211: always allocate struct ieee802_11_elems
As the 802.11 spec evolves, we need to parse more and more elements. This is causing the struct to grow, and we can no longer get away with putting it on the stack. Change the API to always dynamically allocate and return an allocated pointer that must be kfree()d later. As an alternative, I contemplated a scheme whereby we'd say in the code which elements we needed, e.g. DECLARE_ELEMENT_PARSER(elems, SUPPORTED_CHANNELS, CHANNEL_SWITCH, EXT(KEY_DELIVERY)); ieee802_11_parse_elems(..., &elems, ...); and while I think this is possible and will save us a lot since most individual places only care about a small subset of the elements, it ended up being a bit more work since a lot of places do the parsing and then pass the struct to other functions, sometimes with multiple levels. Link: https://lore.kernel.org/r/20210920154009.26caff6b5998.I05ae58768e990e611aee8eca8abefd9d7bc15e05@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Cc: Felix Fietkau <nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net/rds/recv.c')
0 files changed, 0 insertions, 0 deletions