On Mon, Mar 6, 2017 at 12:02 PM, Arend Van Spriel
<arend.vanspriel@xxxxxxxxxxxx> wrote:
> On 6-3-2017 11:38, Arnd Bergmann wrote:
>> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel
>> <arend.vanspriel@xxxxxxxxxxxx> wrote:
>>> On 2-3-2017 17:38, Arnd Bergmann wrote:
>>>> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an object
>>>> on the stack, which will each require a redzone with KASAN and lead to possible
>>>> stack overflow:
>>>>
>>>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
>>>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: warning: the frame size of 6312 bytes is larger than 1000 bytes [-Wframe-larger-than=]
>>>
>>> Looks like this warning text ended up in the wrong commit message. Got
>>> me confused for a sec :-p
>>
>> What's wrong about the warning?
>
> The warning is about the function 'wlc_phy_workarounds_nphy' (see PATCH
> 9/26) and not about wlc_phy_table_write_nphy/wlc_phy_table_read_nphy
> functions.
The warning only shows up for wlc_phy_workarounds_nphy, and we have to
fix both issues to get the size down enough. If we split it up without
uninlining the register access functions, we end up with two or three smaller
functions that still exceed the limit.
>>>> This marks the two functions as noinline_for_kasan, avoiding the problem entirely.
>>>
>>> Frankly I seriously dislike annotating code for the sake of some
>>> (dynamic) memory analyzer. To me the whole thing seems rather
>>> unnecessary. If the code passes the 2048 stack limit without KASAN it
>>> would seem the limit with KASAN should be such that no warning is given.
>>> I suspect that it is rather difficult to predict the additional size of
>>> the instrumentation code and on some systems there might be a real issue
>>> with increased stack usage.
>>
>> The frame sizes don't normally change that much. There are a couple of
>> drivers like brcmsmac that repeatedly call an inline function which has
>> a local variable that it passes by reference to an extern function.
>>
>> While normally those variables share a stack location, KASAN forces
>> each instance to its own location and adds (in this case) 80 bytes of
>> redzone around it to detect out-of-bounds access.
>>
>> While most drivers are fine with a 1500 byte warning limit, increasing
>> the limit to 7kb would silence brcmsmac (unless more registers
>> are accessed from wlc_phy_workarounds_nphy) but also risk a
>> stack overflow to go unnoticed.
>
> Given the amount of local variables maybe just tag the functions with
> noinline instead.
But that would result in less efficient object code without KASAN,
as inlining these by default is a good idea when the stack variables
all get folded.
Arnd
