On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: > Arend Van Spriel <arend.vanspriel@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> > > 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. Arnd