[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877f414e1n.fsf@codeaurora.org>
Date: Tue, 07 Mar 2017 11:44:04 +0200
From: Kalle Valo <kvalo@...eaurora.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Arend Van Spriel <arend.vanspriel@...adcom.com>,
kasan-dev <kasan-dev@...glegroups.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Networking <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-media@...r.kernel.org,
linux-wireless <linux-wireless@...r.kernel.org>,
kernel-build-reports@...ts.linaro.org,
"David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size
Arnd Bergmann <arnd@...db.de> writes:
> On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo <kvalo@...eaurora.org> wrote:
>> Arend Van Spriel <arend.vanspriel@...adcom.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@...adcom.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
Powered by blists - more mailing lists