| Message ID | 20170302163834.2273519-8-arnd@arndb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 > 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. Regards, Arend > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c > index b3aab2fe96eb..42dc8e1f483d 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c > @@ -14157,7 +14157,7 @@ static void wlc_phy_bphy_init_nphy(struct brcms_phy *pi) > write_phy_reg(pi, NPHY_TO_BPHY_OFF + BPHY_STEP, 0x668); > } > > -void > +noinline_for_kasan void > wlc_phy_table_write_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset, > u32 width, const void *data) > { > @@ -14171,7 +14171,7 @@ wlc_phy_table_write_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset, > wlc_phy_write_table_nphy(pi, &tbl); > } > > -void > +noinline_for_kasan void > wlc_phy_table_read_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset, > u32 width, void *data) > { >
On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel <arend.vanspriel@broadcom.com> 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? >> 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. Arnd
On 6-3-2017 11:38, Arnd Bergmann wrote: > On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel > <arend.vanspriel@broadcom.com> 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. >>> 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. Regards, Arend
On Mon, Mar 6, 2017 at 12:02 PM, Arend Van Spriel <arend.vanspriel@broadcom.com> wrote: > On 6-3-2017 11:38, Arnd Bergmann wrote: >> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel >> <arend.vanspriel@broadcom.com> 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
On Mon, Mar 6, 2017 at 12:16 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Mon, Mar 6, 2017 at 12:02 PM, Arend Van Spriel > <arend.vanspriel@broadcom.com> wrote: >> On 6-3-2017 11:38, Arnd Bergmann wrote: >>> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel >>> <arend.vanspriel@broadcom.com> wrote: >> 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. Note that David Laight alread suggested renaming noinline_for_kasan to noinline_if_stackbloat, which makes it a little more obvious what is going on. Would that address your concern as well? Arnd
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c index b3aab2fe96eb..42dc8e1f483d 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c @@ -14157,7 +14157,7 @@ static void wlc_phy_bphy_init_nphy(struct brcms_phy *pi) write_phy_reg(pi, NPHY_TO_BPHY_OFF + BPHY_STEP, 0x668); } -void +noinline_for_kasan void wlc_phy_table_write_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset, u32 width, const void *data) { @@ -14171,7 +14171,7 @@ wlc_phy_table_write_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset, wlc_phy_write_table_nphy(pi, &tbl); } -void +noinline_for_kasan void wlc_phy_table_read_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset, u32 width, void *data) {
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=] This marks the two functions as noinline_for_kasan, avoiding the problem entirely. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)