Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

Arnd Bergmann [off-list ref] writes:

On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo [off-list ref] wrote:

quoted

Arend Van Spriel [off-list ref] writes:

quoted

On 2-3-2017 17:38, Arnd Bergmann wrote:

quoted

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.

-- 
Kalle Valo

On 7-3-2017 10:44, Kalle Valo wrote:

Arnd Bergmann [off-list ref] writes:

quoted

On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo [off-list ref] wrote:

quoted

Arend Van Spriel [off-list ref] writes:

quoted

On 2-3-2017 17:38, Arnd Bergmann wrote:

quoted

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.

That (dreaded) phy code does not get a lot of changes so I think it does
not matter which tree is will go through in terms of risk for conflicts.
So going through linux-mm is fine for me as well.

Regards,
Arend