Arnd Bergmann arnd@arndb.de writes:
On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo kvalo@codeaurora.org wrote:
Arend Van Spriel arend.vanspriel@broadcom.com writes:
On 2-3-2017 17:38, Arnd Bergmann wrote:
With KASAN and a couple of other patches applied, this driver is one of the few remaining ones that actually use more than 2048 bytes of kernel stack:
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl': broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=] broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy': broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Here, I'm reducing the stack size by marking as many local variables as 'static const' as I can without changing the actual code.
Acked-by: Arend van Spriel arend.vanspriel@broadcom.com
Arnd, via which tree are you planning to submit these? I'm not sure what I should do with the wireless drivers patches from this series.
I'm not quite sure myself yet. I'd probably want the first few patches that do most of the work get merged through Andrew's linux-mm tree once we have come to agreement on them. The driver specific patches like the brcmsmac ones depend on the introduction of noinline_for_kasan or noinline_if_stackbloat and could either go in along with the first set, or as a follow-up through the normal maintainer trees.
Either way is fine for me. Just mark clearly if you want the wireless drivers patches to go through via my tree, otherwise I'll ignore them.