Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591306 > unrolled thread

[PATCH 00/26] bring back stack frame warning with KASAN

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/26] bring back stack frame warning with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
    [PATCH 07/26] brcmsmac: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
      Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN Arend Van Spriel <arend.vanspriel@broadcom.com> - 2017-03-06 10:50 +0100
        Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-06 12:00 +0100
          Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN Arend Van Spriel <arend.vanspriel@broadcom.com> - 2017-03-06 12:20 +0100
            Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-06 12:20 +0100
              Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-06 12:40 +0100
    [PATCH 15/26] [media] tuners: i2c: reduce stack usage for tuner_i2c_xfer_* Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
    [PATCH 11/26] rtlwifi: reduce stack usage for KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
    [PATCH 04/26] tty: kbd: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
    [PATCH 12/26] wl3501_cs: reduce stack size for KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
    [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
      Re: [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy Arend Van Spriel <arend.vanspriel@broadcom.com> - 2017-03-06 10:40 +0100
    [PATCH 01/26] compiler: introduce noinline_for_kasan annotation Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
      Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation Alexander Potapenko <glider@google.com> - 2017-03-03 15:00 +0100
        Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation Alexander Potapenko <glider@google.com> - 2017-03-03 15:40 +0100
          Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation Arnd Bergmann <arnd@arndb.de> - 2017-03-03 16:10 +0100
        Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation Arnd Bergmann <arnd@arndb.de> - 2017-03-03 15:40 +0100
      RE: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation David Laight <David.Laight@ACULAB.COM> - 2017-03-03 18:10 +0100
    [PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
    [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:20 +0100
      Re: [PATCH 08/26] brcmsmac: make some local variables 'static const'  to reduce stack size Arend Van Spriel <arend.vanspriel@broadcom.com> - 2017-03-06 10:40 +0100
        Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size Kalle Valo <kvalo@codeaurora.org> - 2017-03-06 17:40 +0100
          Re: [PATCH 08/26] brcmsmac: make some local variables 'static const'  to reduce stack size Arnd Bergmann <arnd@arndb.de> - 2017-03-06 22:40 +0100
            Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size Kalle Valo <kvalo@codeaurora.org> - 2017-03-07 10:50 +0100
              Re: [PATCH 08/26] brcmsmac: make some local variables 'static const'  to reduce stack size Arend Van Spriel <arend.vanspriel@broadcom.com> - 2017-03-07 11:10 +0100
    [PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 18:40 +0100
    Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN Joe Perches <joe@perches.com> - 2017-03-02 19:00 +0100
      Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN Joe Perches <joe@perches.com> - 2017-03-02 23:50 +0100
        Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-03 00:10 +0100
          Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN Joe Perches <joe@perches.com> - 2017-03-03 01:00 +0100
      Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-03 00:00 +0100
    [PATCH 24/26] ocfs2: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 20:10 +0100
    [PATCH 23/26] mtd: cfi: reduce stack size with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 20:20 +0100
    [PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-02 23:30 +0100
    Re: [PATCH 00/26] bring back stack frame warning with KASAN Alexander Potapenko <glider@google.com> - 2017-03-03 13:30 +0100
      Re: [PATCH 00/26] bring back stack frame warning with KASAN Arnd Bergmann <arnd@arndb.de> - 2017-03-03 14:00 +0100
    Re: [PATCH 10/26] brcmsmac: reindent split functions Kalle Valo <kvalo@codeaurora.org> - 2017-03-06 17:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

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

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.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c        | 197 ++++++++++-----------
 1 file changed, 97 insertions(+), 100 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 42dc8e1f483d..48a4df488d75 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14764,8 +14764,8 @@ static void wlc_phy_ipa_restore_tx_digi_filts_nphy(struct brcms_phy *pi)
 }
 
 static void
-wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, u8 *events, u8 *dlys,
-		       u8 len)
+wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, const u8 *events,
+		       const u8 *dlys, u8 len)
 {
 	u32 t1_offset, t2_offset;
 	u8 ctr;
@@ -15240,16 +15240,16 @@ static void wlc_phy_workarounds_nphy_gainctrl_2057_rev5(struct brcms_phy *pi)
 static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 {
 	u16 currband;
-	s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
-	s8 *lna1_gain_db = NULL;
-	s8 *lna1_gain_db_2 = NULL;
-	s8 *lna2_gain_db = NULL;
-	s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
-	s8 *tia_gain_db;
-	s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
-	s8 *tia_gainbits;
-	u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
-	u16 *rfseq_init_gain;
+	static const s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
+	const s8 *lna1_gain_db = NULL;
+	const s8 *lna1_gain_db_2 = NULL;
+	const s8 *lna2_gain_db = NULL;
+	static const s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
+	const s8 *tia_gain_db;
+	static const s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
+	const s8 *tia_gainbits;
+	static const u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
+	const u16 *rfseq_init_gain;
 	u16 init_gaincode;
 	u16 clip1hi_gaincode;
 	u16 clip1md_gaincode = 0;
@@ -15310,10 +15310,9 @@ static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 
 			if ((freq <= 5080) || (freq == 5825)) {
 
-				s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
-				s8 lna1A_gain_db_2_rev7[] = {
-					11, 17, 22, 25};
-				s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
+				static const s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
+				static const s8 lna1A_gain_db_2_rev7[] = { 11, 17, 22, 25};
+				static const s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
 
 				crsminu_th = 0x3e;
 				lna1_gain_db = lna1A_gain_db_rev7;
@@ -15321,10 +15320,9 @@ static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 				lna2_gain_db = lna2A_gain_db_rev7;
 			} else if ((freq >= 5500) && (freq <= 5700)) {
 
-				s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
-				s8 lna1A_gain_db_2_rev7[] = {
-					12, 18, 22, 26};
-				s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
+				static const s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
+				static const s8 lna1A_gain_db_2_rev7[] = { 12, 18, 22, 26};
+				static const s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
 
 				crsminu_th = 0x45;
 				clip1md_gaincode_B = 0x14;
@@ -15335,10 +15333,9 @@ static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 				lna2_gain_db = lna2A_gain_db_rev7;
 			} else {
 
-				s8 lna1A_gain_db_rev7[] = { 12, 18, 22, 26 };
-				s8 lna1A_gain_db_2_rev7[] = {
-					12, 18, 22, 26};
-				s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
+				static const s8 lna1A_gain_db_rev7[] = { 12, 18, 22, 26 };
+				static const s8 lna1A_gain_db_2_rev7[] = { 12, 18, 22, 26};
+				static const s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
 
 				crsminu_th = 0x41;
 				lna1_gain_db = lna1A_gain_db_rev7;
@@ -15450,65 +15447,65 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct brcms_phy *pi)
 		NPHY_RFSEQ_CMD_CLR_HIQ_DIS,
 		NPHY_RFSEQ_CMD_SET_HPF_BW
 	};
-	u8 rfseq_updategainu_dlys[] = { 10, 30, 1 };
-	s8 lna1G_gain_db[] = { 7, 11, 16, 23 };
-	s8 lna1G_gain_db_rev4[] = { 8, 12, 17, 25 };
-	s8 lna1G_gain_db_rev5[] = { 9, 13, 18, 26 };
-	s8 lna1G_gain_db_rev6[] = { 8, 13, 18, 25 };
-	s8 lna1G_gain_db_rev6_224B0[] = { 10, 14, 19, 27 };
-	s8 lna1A_gain_db[] = { 7, 11, 17, 23 };
-	s8 lna1A_gain_db_rev4[] = { 8, 12, 18, 23 };
-	s8 lna1A_gain_db_rev5[] = { 6, 10, 16, 21 };
-	s8 lna1A_gain_db_rev6[] = { 6, 10, 16, 21 };
-	s8 *lna1_gain_db = NULL;
-	s8 lna2G_gain_db[] = { -5, 6, 10, 14 };
-	s8 lna2G_gain_db_rev5[] = { -3, 7, 11, 16 };
-	s8 lna2G_gain_db_rev6[] = { -5, 6, 10, 14 };
-	s8 lna2G_gain_db_rev6_224B0[] = { -5, 6, 10, 15 };
-	s8 lna2A_gain_db[] = { -6, 2, 6, 10 };
-	s8 lna2A_gain_db_rev4[] = { -5, 2, 6, 10 };
-	s8 lna2A_gain_db_rev5[] = { -7, 0, 4, 8 };
-	s8 lna2A_gain_db_rev6[] = { -7, 0, 4, 8 };
-	s8 *lna2_gain_db = NULL;
-	s8 tiaG_gain_db[] = {
+	static const u8 rfseq_updategainu_dlys[] = { 10, 30, 1 };
+	static const s8 lna1G_gain_db[] = { 7, 11, 16, 23 };
+	static const s8 lna1G_gain_db_rev4[] = { 8, 12, 17, 25 };
+	static const s8 lna1G_gain_db_rev5[] = { 9, 13, 18, 26 };
+	static const s8 lna1G_gain_db_rev6[] = { 8, 13, 18, 25 };
+	static const s8 lna1G_gain_db_rev6_224B0[] = { 10, 14, 19, 27 };
+	static const s8 lna1A_gain_db[] = { 7, 11, 17, 23 };
+	static const s8 lna1A_gain_db_rev4[] = { 8, 12, 18, 23 };
+	static const s8 lna1A_gain_db_rev5[] = { 6, 10, 16, 21 };
+	static const s8 lna1A_gain_db_rev6[] = { 6, 10, 16, 21 };
+	const s8 *lna1_gain_db = NULL;
+	static const s8 lna2G_gain_db[] = { -5, 6, 10, 14 };
+	static const s8 lna2G_gain_db_rev5[] = { -3, 7, 11, 16 };
+	static const s8 lna2G_gain_db_rev6[] = { -5, 6, 10, 14 };
+	static const s8 lna2G_gain_db_rev6_224B0[] = { -5, 6, 10, 15 };
+	static const s8 lna2A_gain_db[] = { -6, 2, 6, 10 };
+	static const s8 lna2A_gain_db_rev4[] = { -5, 2, 6, 10 };
+	static const s8 lna2A_gain_db_rev5[] = { -7, 0, 4, 8 };
+	static const s8 lna2A_gain_db_rev6[] = { -7, 0, 4, 8 };
+	const s8 *lna2_gain_db = NULL;
+	static const s8 tiaG_gain_db[] = {
 		0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A };
-	s8 tiaA_gain_db[] = {
+	static const s8 tiaA_gain_db[] = {
 		0x13, 0x13, 0x13, 0x13, 0x13, 0x13, 0x13, 0x13, 0x13, 0x13 };
-	s8 tiaA_gain_db_rev4[] = {
+	static const s8 tiaA_gain_db_rev4[] = {
 		0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d };
-	s8 tiaA_gain_db_rev5[] = {
+	static const s8 tiaA_gain_db_rev5[] = {
 		0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d };
-	s8 tiaA_gain_db_rev6[] = {
+	static const s8 tiaA_gain_db_rev6[] = {
 		0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d };
-	s8 *tia_gain_db;
-	s8 tiaG_gainbits[] = {
+	const s8 *tia_gain_db;
+	static const s8 tiaG_gainbits[] = {
 		0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03 };
-	s8 tiaA_gainbits[] = {
+	static const s8 tiaA_gainbits[] = {
 		0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06 };
-	s8 tiaA_gainbits_rev4[] = {
+	static const s8 tiaA_gainbits_rev4[] = {
 		0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04 };
-	s8 tiaA_gainbits_rev5[] = {
+	static const s8 tiaA_gainbits_rev5[] = {
 		0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04 };
-	s8 tiaA_gainbits_rev6[] = {
+	static const s8 tiaA_gainbits_rev6[] = {
 		0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04 };
-	s8 *tia_gainbits;
-	s8 lpf_gain_db[] = { 0x00, 0x06, 0x0c, 0x12, 0x12, 0x12 };
-	s8 lpf_gainbits[] = { 0x00, 0x01, 0x02, 0x03, 0x03, 0x03 };
-	u16 rfseqG_init_gain[] = { 0x613f, 0x613f, 0x613f, 0x613f };
-	u16 rfseqG_init_gain_rev4[] = { 0x513f, 0x513f, 0x513f, 0x513f };
-	u16 rfseqG_init_gain_rev5[] = { 0x413f, 0x413f, 0x413f, 0x413f };
-	u16 rfseqG_init_gain_rev5_elna[] = {
+	const s8 *tia_gainbits;
+	static const s8 lpf_gain_db[] = { 0x00, 0x06, 0x0c, 0x12, 0x12, 0x12 };
+	static const s8 lpf_gainbits[] = { 0x00, 0x01, 0x02, 0x03, 0x03, 0x03 };
+	static const u16 rfseqG_init_gain[] = { 0x613f, 0x613f, 0x613f, 0x613f };
+	static const u16 rfseqG_init_gain_rev4[] = { 0x513f, 0x513f, 0x513f, 0x513f };
+	static const u16 rfseqG_init_gain_rev5[] = { 0x413f, 0x413f, 0x413f, 0x413f };
+	static const u16 rfseqG_init_gain_rev5_elna[] = {
 		0x013f, 0x013f, 0x013f, 0x013f };
-	u16 rfseqG_init_gain_rev6[] = { 0x513f, 0x513f };
-	u16 rfseqG_init_gain_rev6_224B0[] = { 0x413f, 0x413f };
-	u16 rfseqG_init_gain_rev6_elna[] = { 0x113f, 0x113f };
-	u16 rfseqA_init_gain[] = { 0x516f, 0x516f, 0x516f, 0x516f };
-	u16 rfseqA_init_gain_rev4[] = { 0x614f, 0x614f, 0x614f, 0x614f };
-	u16 rfseqA_init_gain_rev4_elna[] = {
+	static const u16 rfseqG_init_gain_rev6[] = { 0x513f, 0x513f };
+	static const u16 rfseqG_init_gain_rev6_224B0[] = { 0x413f, 0x413f };
+	static const u16 rfseqG_init_gain_rev6_elna[] = { 0x113f, 0x113f };
+	static const u16 rfseqA_init_gain[] = { 0x516f, 0x516f, 0x516f, 0x516f };
+	static const u16 rfseqA_init_gain_rev4[] = { 0x614f, 0x614f, 0x614f, 0x614f };
+	static const u16 rfseqA_init_gain_rev4_elna[] = {
 		0x314f, 0x314f, 0x314f, 0x314f };
-	u16 rfseqA_init_gain_rev5[] = { 0x714f, 0x714f, 0x714f, 0x714f };
-	u16 rfseqA_init_gain_rev6[] = { 0x714f, 0x714f };
-	u16 *rfseq_init_gain;
+	static const u16 rfseqA_init_gain_rev5[] = { 0x714f, 0x714f, 0x714f, 0x714f };
+	static const u16 rfseqA_init_gain_rev6[] = { 0x714f, 0x714f };
+	const u16 *rfseq_init_gain;
 	u16 initG_gaincode = 0x627e;
 	u16 initG_gaincode_rev4 = 0x527e;
 	u16 initG_gaincode_rev5 = 0x427e;
@@ -15538,10 +15535,10 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct brcms_phy *pi)
 	u16 clip1mdA_gaincode_rev6 = 0x2084;
 	u16 clip1md_gaincode = 0;
 	u16 clip1loG_gaincode = 0x0074;
-	u16 clip1loG_gaincode_rev5[] = {
+	static const u16 clip1loG_gaincode_rev5[] = {
 		0x0062, 0x0064, 0x006a, 0x106a, 0x106c, 0x1074, 0x107c, 0x207c
 	};
-	u16 clip1loG_gaincode_rev6[] = {
+	static const u16 clip1loG_gaincode_rev6[] = {
 		0x106a, 0x106c, 0x1074, 0x107c, 0x007e, 0x107e, 0x207e, 0x307e
 	};
 	u16 clip1loG_gaincode_rev6_224B0 = 0x1074;
@@ -16066,7 +16063,7 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct brcms_phy *pi)
 
 static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
 {
-	u8 rfseq_rx2tx_events[] = {
+	static const u8 rfseq_rx2tx_events[] = {
 		NPHY_RFSEQ_CMD_NOP,
 		NPHY_RFSEQ_CMD_RXG_FBW,
 		NPHY_RFSEQ_CMD_TR_SWITCH,
@@ -16076,7 +16073,7 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
 		NPHY_RFSEQ_CMD_EXT_PA
 	};
 	u8 rfseq_rx2tx_dlys[] = { 8, 6, 6, 2, 4, 60, 1 };
-	u8 rfseq_tx2rx_events[] = {
+	static const u8 rfseq_tx2rx_events[] = {
 		NPHY_RFSEQ_CMD_NOP,
 		NPHY_RFSEQ_CMD_EXT_PA,
 		NPHY_RFSEQ_CMD_TX_GAIN,
@@ -16085,8 +16082,8 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
 		NPHY_RFSEQ_CMD_RXG_FBW,
 		NPHY_RFSEQ_CMD_CLR_HIQ_DIS
 	};
-	u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
-	u8 rfseq_tx2rx_events_rev3[] = {
+	static const u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
+	static const u8 rfseq_tx2rx_events_rev3[] = {
 		NPHY_REV3_RFSEQ_CMD_EXT_PA,
 		NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
 		NPHY_REV3_RFSEQ_CMD_TX_GAIN,
@@ -16096,7 +16093,7 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
 		NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
 		NPHY_REV3_RFSEQ_CMD_END
 	};
-	u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
+	static const u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
 	u8 rfseq_rx2tx_events_rev3[] = {
 		NPHY_REV3_RFSEQ_CMD_NOP,
 		NPHY_REV3_RFSEQ_CMD_RXG_FBW,
@@ -16110,7 +16107,7 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
 	};
 	u8 rfseq_rx2tx_dlys_rev3[] = { 8, 6, 6, 4, 4, 18, 42, 1, 1 };
 
-	u8 rfseq_rx2tx_events_rev3_ipa[] = {
+	static const u8 rfseq_rx2tx_events_rev3_ipa[] = {
 		NPHY_REV3_RFSEQ_CMD_NOP,
 		NPHY_REV3_RFSEQ_CMD_RXG_FBW,
 		NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
@@ -16121,15 +16118,15 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
 		NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
 		NPHY_REV3_RFSEQ_CMD_END
 	};
-	u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
-	u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
+	static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
+	static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
 
 	s16 alpha0, alpha1, alpha2;
 	s16 beta0, beta1, beta2;
 	u32 leg_data_weights, ht_data_weights, nss1_data_weights,
 	    stbc_data_weights;
 	u8 chan_freq_range = 0;
-	u16 dac_control = 0x0002;
+	static const u16 dac_control = 0x0002;
 	u16 aux_adc_vmid_rev7_core0[] = { 0x8e, 0x96, 0x96, 0x96 };
 	u16 aux_adc_vmid_rev7_core1[] = { 0x8f, 0x9f, 0x9f, 0x96 };
 	u16 aux_adc_vmid_rev4[] = { 0xa2, 0xb4, 0xb4, 0x89 };
@@ -16139,8 +16136,8 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
 	u16 aux_adc_gain_rev4[] = { 0x02, 0x02, 0x02, 0x00 };
 	u16 aux_adc_gain_rev3[] = { 0x02, 0x02, 0x02, 0x00 };
 	u16 *aux_adc_gain;
-	u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
-	u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
+	static const u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
+	static const u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
 	s32 min_nvar_val = 0x18d;
 	s32 min_nvar_offset_6mbps = 20;
 	u8 pdetrange;
@@ -16151,9 +16148,9 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
 	u16 rfseq_rx2tx_lpf_h_hpc_rev7 = 0x77;
 	u16 rfseq_tx2rx_lpf_h_hpc_rev7 = 0x77;
 	u16 rfseq_pktgn_lpf_h_hpc_rev7 = 0x77;
-	u16 rfseq_htpktgn_lpf_hpc_rev7[] = { 0x77, 0x11, 0x11 };
-	u16 rfseq_pktgn_lpf_hpc_rev7[] = { 0x11, 0x11 };
-	u16 rfseq_cckpktgn_lpf_hpc_rev7[] = { 0x11, 0x11 };
+	static const u16 rfseq_htpktgn_lpf_hpc_rev7[] = { 0x77, 0x11, 0x11 };
+	static const u16 rfseq_pktgn_lpf_hpc_rev7[] = { 0x11, 0x11 };
+	static const u16 rfseq_cckpktgn_lpf_hpc_rev7[] = { 0x11, 0x11 };
 	u16 ipalvlshift_3p3_war_en = 0;
 	u16 rccal_bcap_val, rccal_scap_val;
 	u16 rccal_tx20_11b_bcap = 0;
@@ -24291,13 +24288,13 @@ static void wlc_phy_update_txcal_ladder_nphy(struct brcms_phy *pi, u16 core)
 	u16 bbmult;
 	u16 tblentry;
 
-	struct nphy_txiqcal_ladder ladder_lo[] = {
+	static const struct nphy_txiqcal_ladder ladder_lo[] = {
 		{3, 0}, {4, 0}, {6, 0}, {9, 0}, {13, 0}, {18, 0},
 		{25, 0}, {25, 1}, {25, 2}, {25, 3}, {25, 4}, {25, 5},
 		{25, 6}, {25, 7}, {35, 7}, {50, 7}, {71, 7}, {100, 7}
 	};
 
-	struct nphy_txiqcal_ladder ladder_iq[] = {
+	static const struct nphy_txiqcal_ladder ladder_iq[] = {
 		{3, 0}, {4, 0}, {6, 0}, {9, 0}, {13, 0}, {18, 0},
 		{25, 0}, {35, 0}, {50, 0}, {71, 0}, {100, 0}, {100, 1},
 		{100, 2}, {100, 3}, {100, 4}, {100, 5}, {100, 6}, {100, 7}
@@ -25773,67 +25770,67 @@ wlc_phy_cal_txiqlo_nphy(struct brcms_phy *pi, struct nphy_txgains target_gain,
 	u16 cal_gain[2];
 	struct nphy_iqcal_params cal_params[2];
 	u32 tbl_len;
-	void *tbl_ptr;
+	const void *tbl_ptr;
 	bool ladder_updated[2];
 	u8 mphase_cal_lastphase = 0;
 	int bcmerror = 0;
 	bool phyhang_avoid_state = false;
 
-	u16 tbl_tx_iqlo_cal_loft_ladder_20[] = {
+	static const u16 tbl_tx_iqlo_cal_loft_ladder_20[] = {
 		0x0300, 0x0500, 0x0700, 0x0900, 0x0d00, 0x1100, 0x1900, 0x1901,
 		0x1902,
 		0x1903, 0x1904, 0x1905, 0x1906, 0x1907, 0x2407, 0x3207, 0x4607,
 		0x6407
 	};
 
-	u16 tbl_tx_iqlo_cal_iqimb_ladder_20[] = {
+	static const u16 tbl_tx_iqlo_cal_iqimb_ladder_20[] = {
 		0x0200, 0x0300, 0x0600, 0x0900, 0x0d00, 0x1100, 0x1900, 0x2400,
 		0x3200,
 		0x4600, 0x6400, 0x6401, 0x6402, 0x6403, 0x6404, 0x6405, 0x6406,
 		0x6407
 	};
 
-	u16 tbl_tx_iqlo_cal_loft_ladder_40[] = {
+	static const u16 tbl_tx_iqlo_cal_loft_ladder_40[] = {
 		0x0200, 0x0300, 0x0400, 0x0700, 0x0900, 0x0c00, 0x1200, 0x1201,
 		0x1202,
 		0x1203, 0x1204, 0x1205, 0x1206, 0x1207, 0x1907, 0x2307, 0x3207,
 		0x4707
 	};
 
-	u16 tbl_tx_iqlo_cal_iqimb_ladder_40[] = {
+	static const u16 tbl_tx_iqlo_cal_iqimb_ladder_40[] = {
 		0x0100, 0x0200, 0x0400, 0x0700, 0x0900, 0x0c00, 0x1200, 0x1900,
 		0x2300,
 		0x3200, 0x4700, 0x4701, 0x4702, 0x4703, 0x4704, 0x4705, 0x4706,
 		0x4707
 	};
 
-	u16 tbl_tx_iqlo_cal_startcoefs[] = {
+	static const u16 tbl_tx_iqlo_cal_startcoefs[] = {
 		0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
 		0x0000
 	};
 
-	u16 tbl_tx_iqlo_cal_cmds_fullcal[] = {
+	static const u16 tbl_tx_iqlo_cal_cmds_fullcal[] = {
 		0x8123, 0x8264, 0x8086, 0x8245, 0x8056,
 		0x9123, 0x9264, 0x9086, 0x9245, 0x9056
 	};
 
-	u16 tbl_tx_iqlo_cal_cmds_recal[] = {
+	static const u16 tbl_tx_iqlo_cal_cmds_recal[] = {
 		0x8101, 0x8253, 0x8053, 0x8234, 0x8034,
 		0x9101, 0x9253, 0x9053, 0x9234, 0x9034
 	};
 
-	u16 tbl_tx_iqlo_cal_startcoefs_nphyrev3[] = {
+	static const u16 tbl_tx_iqlo_cal_startcoefs_nphyrev3[] = {
 		0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
 		0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
 		0x0000
 	};
 
-	u16 tbl_tx_iqlo_cal_cmds_fullcal_nphyrev3[] = {
+	static const u16 tbl_tx_iqlo_cal_cmds_fullcal_nphyrev3[] = {
 		0x8434, 0x8334, 0x8084, 0x8267, 0x8056, 0x8234,
 		0x9434, 0x9334, 0x9084, 0x9267, 0x9056, 0x9234
 	};
 
-	u16 tbl_tx_iqlo_cal_cmds_recal_nphyrev3[] = {
+	static const u16 tbl_tx_iqlo_cal_cmds_recal_nphyrev3[] = {
 		0x8423, 0x8323, 0x8073, 0x8256, 0x8045, 0x8223,
 		0x9423, 0x9323, 0x9073, 0x9256, 0x9045, 0x9223
 	};
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

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

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@broadcom.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  .../broadcom/brcm80211/brcmsmac/phy/phy_n.c        | 197 ++++++++++-----------
>  1 file changed, 97 insertions(+), 100 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 42dc8e1f483d..48a4df488d75 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
> @@ -14764,8 +14764,8 @@ static void wlc_phy_ipa_restore_tx_digi_filts_nphy(struct brcms_phy *pi)
>  }
>  
>  static void
> -wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, u8 *events, u8 *dlys,
> -		       u8 len)
> +wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, const u8 *events,
> +		       const u8 *dlys, u8 len)
>  {
>  	u32 t1_offset, t2_offset;
>  	u8 ctr;
> @@ -15240,16 +15240,16 @@ static void wlc_phy_workarounds_nphy_gainctrl_2057_rev5(struct brcms_phy *pi)
>  static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
>  {
>  	u16 currband;
> -	s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
> -	s8 *lna1_gain_db = NULL;
> -	s8 *lna1_gain_db_2 = NULL;
> -	s8 *lna2_gain_db = NULL;
> -	s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
> -	s8 *tia_gain_db;
> -	s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
> -	s8 *tia_gainbits;
> -	u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
> -	u16 *rfseq_init_gain;
> +	static const s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
> +	const s8 *lna1_gain_db = NULL;
> +	const s8 *lna1_gain_db_2 = NULL;
> +	const s8 *lna2_gain_db = NULL;
> +	static const s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
> +	const s8 *tia_gain_db;
> +	static const s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
> +	const s8 *tia_gainbits;
> +	static const u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
> +	const u16 *rfseq_init_gain;
>  	u16 init_gaincode;
>  	u16 clip1hi_gaincode;
>  	u16 clip1md_gaincode = 0;
> @@ -15310,10 +15310,9 @@ static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
>  
>  			if ((freq <= 5080) || (freq == 5825)) {
>  
> -				s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
> -				s8 lna1A_gain_db_2_rev7[] = {
> -					11, 17, 22, 25};
> -				s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
> +				static const s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
> +				static const s8 lna1A_gain_db_2_rev7[] = { 11, 17, 22, 25};
> +				static const s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
>  
>  				crsminu_th = 0x3e;
>  				lna1_gain_db = lna1A_gain_db_rev7;
> @@ -15321,10 +15320,9 @@ static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
>  				lna2_gain_db = lna2A_gain_db_rev7;
>  			} else if ((freq >= 5500) && (freq <= 5700)) {
>  
> -				s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
> -				s8 lna1A_gain_db_2_rev7[] = {
> -					12, 18, 22, 26};
> -				s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
> +				static const s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
> +				static const s8 lna1A_gain_db_2_rev7[] = { 12, 18, 22, 26};
> +				static const s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
>  
>  				crsminu_th = 0x45;
>  				clip1md_gaincode_B = 0x14;
> @@ -15335,10 +15333,9 @@ static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
>  				lna2_gain_db = lna2A_gain_db_rev7;
>  			} else {
>  
> -				s8 lna1A_gain_db_rev7[] = { 12, 18, 22, 26 };
> -				s8 lna1A_gain_db_2_rev7[] = {
> -					12, 18, 22, 26};
> -				s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
> +				static const s8 lna1A_gain_db_rev7[] = { 12, 18, 22, 26 };
> +				static const s8 lna1A_gain_db_2_rev7[] = { 12, 18, 22, 26};
> +				static const s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
>  
>  				crsminu_th = 0x41;
>  				lna1_gain_db = lna1A_gain_db_rev7;
> @@ -15450,65 +15447,65 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct brcms_phy *pi)
>  		NPHY_RFSEQ_CMD_CLR_HIQ_DIS,
>  		NPHY_RFSEQ_CMD_SET_HPF_BW
>  	};
> -	u8 rfseq_updategainu_dlys[] = { 10, 30, 1 };
> -	s8 lna1G_gain_db[] = { 7, 11, 16, 23 };
> -	s8 lna1G_gain_db_rev4[] = { 8, 12, 17, 25 };
> -	s8 lna1G_gain_db_rev5[] = { 9, 13, 18, 26 };
> -	s8 lna1G_gain_db_rev6[] = { 8, 13, 18, 25 };
> -	s8 lna1G_gain_db_rev6_224B0[] = { 10, 14, 19, 27 };
> -	s8 lna1A_gain_db[] = { 7, 11, 17, 23 };
> -	s8 lna1A_gain_db_rev4[] = { 8, 12, 18, 23 };
> -	s8 lna1A_gain_db_rev5[] = { 6, 10, 16, 21 };
> -	s8 lna1A_gain_db_rev6[] = { 6, 10, 16, 21 };
> -	s8 *lna1_gain_db = NULL;
> -	s8 lna2G_gain_db[] = { -5, 6, 10, 14 };
> -	s8 lna2G_gain_db_rev5[] = { -3, 7, 11, 16 };
> -	s8 lna2G_gain_db_rev6[] = { -5, 6, 10, 14 };
> -	s8 lna2G_gain_db_rev6_224B0[] = { -5, 6, 10, 15 };
> -	s8 lna2A_gain_db[] = { -6, 2, 6, 10 };
> -	s8 lna2A_gain_db_rev4[] = { -5, 2, 6, 10 };
> -	s8 lna2A_gain_db_rev5[] = { -7, 0, 4, 8 };
> -	s8 lna2A_gain_db_rev6[] = { -7, 0, 4, 8 };
> -	s8 *lna2_gain_db = NULL;
> -	s8 tiaG_gain_db[] = {
> +	static const u8 rfseq_updategainu_dlys[] = { 10, 30, 1 };
> +	static const s8 lna1G_gain_db[] = { 7, 11, 16, 23 };
> +	static const s8 lna1G_gain_db_rev4[] = { 8, 12, 17, 25 };
> +	static const s8 lna1G_gain_db_rev5[] = { 9, 13, 18, 26 };
> +	static const s8 lna1G_gain_db_rev6[] = { 8, 13, 18, 25 };
> +	static const s8 lna1G_gain_db_rev6_224B0[] = { 10, 14, 19, 27 };
> +	static const s8 lna1A_gain_db[] = { 7, 11, 17, 23 };
> +	static const s8 lna1A_gain_db_rev4[] = { 8, 12, 18, 23 };
> +	static const s8 lna1A_gain_db_rev5[] = { 6, 10, 16, 21 };
> +	static const s8 lna1A_gain_db_rev6[] = { 6, 10, 16, 21 };
> +	const s8 *lna1_gain_db = NULL;
> +	static const s8 lna2G_gain_db[] = { -5, 6, 10, 14 };
> +	static const s8 lna2G_gain_db_rev5[] = { -3, 7, 11, 16 };
> +	static const s8 lna2G_gain_db_rev6[] = { -5, 6, 10, 14 };
> +	static const s8 lna2G_gain_db_rev6_224B0[] = { -5, 6, 10, 15 };
> +	static const s8 lna2A_gain_db[] = { -6, 2, 6, 10 };
> +	static const s8 lna2A_gain_db_rev4[] = { -5, 2, 6, 10 };
> +	static const s8 lna2A_gain_db_rev5[] = { -7, 0, 4, 8 };
> +	static const s8 lna2A_gain_db_rev6[] = { -7, 0, 4, 8 };
> +	const s8 *lna2_gain_db = NULL;
> +	static const s8 tiaG_gain_db[] = {
>  		0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A };
> -	s8 tiaA_gain_db[] = {
> +	static const s8 tiaA_gain_db[] = {
>  		0x13, 0x13, 0x13, 0x13, 0x13, 0x13, 0x13, 0x13, 0x13, 0x13 };
> -	s8 tiaA_gain_db_rev4[] = {
> +	static const s8 tiaA_gain_db_rev4[] = {
>  		0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d };
> -	s8 tiaA_gain_db_rev5[] = {
> +	static const s8 tiaA_gain_db_rev5[] = {
>  		0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d };
> -	s8 tiaA_gain_db_rev6[] = {
> +	static const s8 tiaA_gain_db_rev6[] = {
>  		0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d, 0x0d };
> -	s8 *tia_gain_db;
> -	s8 tiaG_gainbits[] = {
> +	const s8 *tia_gain_db;
> +	static const s8 tiaG_gainbits[] = {
>  		0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03 };
> -	s8 tiaA_gainbits[] = {
> +	static const s8 tiaA_gainbits[] = {
>  		0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06 };
> -	s8 tiaA_gainbits_rev4[] = {
> +	static const s8 tiaA_gainbits_rev4[] = {
>  		0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04 };
> -	s8 tiaA_gainbits_rev5[] = {
> +	static const s8 tiaA_gainbits_rev5[] = {
>  		0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04 };
> -	s8 tiaA_gainbits_rev6[] = {
> +	static const s8 tiaA_gainbits_rev6[] = {
>  		0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04, 0x04 };
> -	s8 *tia_gainbits;
> -	s8 lpf_gain_db[] = { 0x00, 0x06, 0x0c, 0x12, 0x12, 0x12 };
> -	s8 lpf_gainbits[] = { 0x00, 0x01, 0x02, 0x03, 0x03, 0x03 };
> -	u16 rfseqG_init_gain[] = { 0x613f, 0x613f, 0x613f, 0x613f };
> -	u16 rfseqG_init_gain_rev4[] = { 0x513f, 0x513f, 0x513f, 0x513f };
> -	u16 rfseqG_init_gain_rev5[] = { 0x413f, 0x413f, 0x413f, 0x413f };
> -	u16 rfseqG_init_gain_rev5_elna[] = {
> +	const s8 *tia_gainbits;
> +	static const s8 lpf_gain_db[] = { 0x00, 0x06, 0x0c, 0x12, 0x12, 0x12 };
> +	static const s8 lpf_gainbits[] = { 0x00, 0x01, 0x02, 0x03, 0x03, 0x03 };
> +	static const u16 rfseqG_init_gain[] = { 0x613f, 0x613f, 0x613f, 0x613f };
> +	static const u16 rfseqG_init_gain_rev4[] = { 0x513f, 0x513f, 0x513f, 0x513f };
> +	static const u16 rfseqG_init_gain_rev5[] = { 0x413f, 0x413f, 0x413f, 0x413f };
> +	static const u16 rfseqG_init_gain_rev5_elna[] = {
>  		0x013f, 0x013f, 0x013f, 0x013f };
> -	u16 rfseqG_init_gain_rev6[] = { 0x513f, 0x513f };
> -	u16 rfseqG_init_gain_rev6_224B0[] = { 0x413f, 0x413f };
> -	u16 rfseqG_init_gain_rev6_elna[] = { 0x113f, 0x113f };
> -	u16 rfseqA_init_gain[] = { 0x516f, 0x516f, 0x516f, 0x516f };
> -	u16 rfseqA_init_gain_rev4[] = { 0x614f, 0x614f, 0x614f, 0x614f };
> -	u16 rfseqA_init_gain_rev4_elna[] = {
> +	static const u16 rfseqG_init_gain_rev6[] = { 0x513f, 0x513f };
> +	static const u16 rfseqG_init_gain_rev6_224B0[] = { 0x413f, 0x413f };
> +	static const u16 rfseqG_init_gain_rev6_elna[] = { 0x113f, 0x113f };
> +	static const u16 rfseqA_init_gain[] = { 0x516f, 0x516f, 0x516f, 0x516f };
> +	static const u16 rfseqA_init_gain_rev4[] = { 0x614f, 0x614f, 0x614f, 0x614f };
> +	static const u16 rfseqA_init_gain_rev4_elna[] = {
>  		0x314f, 0x314f, 0x314f, 0x314f };
> -	u16 rfseqA_init_gain_rev5[] = { 0x714f, 0x714f, 0x714f, 0x714f };
> -	u16 rfseqA_init_gain_rev6[] = { 0x714f, 0x714f };
> -	u16 *rfseq_init_gain;
> +	static const u16 rfseqA_init_gain_rev5[] = { 0x714f, 0x714f, 0x714f, 0x714f };
> +	static const u16 rfseqA_init_gain_rev6[] = { 0x714f, 0x714f };
> +	const u16 *rfseq_init_gain;
>  	u16 initG_gaincode = 0x627e;
>  	u16 initG_gaincode_rev4 = 0x527e;
>  	u16 initG_gaincode_rev5 = 0x427e;
> @@ -15538,10 +15535,10 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct brcms_phy *pi)
>  	u16 clip1mdA_gaincode_rev6 = 0x2084;
>  	u16 clip1md_gaincode = 0;
>  	u16 clip1loG_gaincode = 0x0074;
> -	u16 clip1loG_gaincode_rev5[] = {
> +	static const u16 clip1loG_gaincode_rev5[] = {
>  		0x0062, 0x0064, 0x006a, 0x106a, 0x106c, 0x1074, 0x107c, 0x207c
>  	};
> -	u16 clip1loG_gaincode_rev6[] = {
> +	static const u16 clip1loG_gaincode_rev6[] = {
>  		0x106a, 0x106c, 0x1074, 0x107c, 0x007e, 0x107e, 0x207e, 0x307e
>  	};
>  	u16 clip1loG_gaincode_rev6_224B0 = 0x1074;
> @@ -16066,7 +16063,7 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct brcms_phy *pi)
>  
>  static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
>  {
> -	u8 rfseq_rx2tx_events[] = {
> +	static const u8 rfseq_rx2tx_events[] = {
>  		NPHY_RFSEQ_CMD_NOP,
>  		NPHY_RFSEQ_CMD_RXG_FBW,
>  		NPHY_RFSEQ_CMD_TR_SWITCH,
> @@ -16076,7 +16073,7 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
>  		NPHY_RFSEQ_CMD_EXT_PA
>  	};
>  	u8 rfseq_rx2tx_dlys[] = { 8, 6, 6, 2, 4, 60, 1 };
> -	u8 rfseq_tx2rx_events[] = {
> +	static const u8 rfseq_tx2rx_events[] = {
>  		NPHY_RFSEQ_CMD_NOP,
>  		NPHY_RFSEQ_CMD_EXT_PA,
>  		NPHY_RFSEQ_CMD_TX_GAIN,
> @@ -16085,8 +16082,8 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
>  		NPHY_RFSEQ_CMD_RXG_FBW,
>  		NPHY_RFSEQ_CMD_CLR_HIQ_DIS
>  	};
> -	u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
> -	u8 rfseq_tx2rx_events_rev3[] = {
> +	static const u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
> +	static const u8 rfseq_tx2rx_events_rev3[] = {
>  		NPHY_REV3_RFSEQ_CMD_EXT_PA,
>  		NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
>  		NPHY_REV3_RFSEQ_CMD_TX_GAIN,
> @@ -16096,7 +16093,7 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
>  		NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
>  		NPHY_REV3_RFSEQ_CMD_END
>  	};
> -	u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
> +	static const u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
>  	u8 rfseq_rx2tx_events_rev3[] = {
>  		NPHY_REV3_RFSEQ_CMD_NOP,
>  		NPHY_REV3_RFSEQ_CMD_RXG_FBW,
> @@ -16110,7 +16107,7 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
>  	};
>  	u8 rfseq_rx2tx_dlys_rev3[] = { 8, 6, 6, 4, 4, 18, 42, 1, 1 };
>  
> -	u8 rfseq_rx2tx_events_rev3_ipa[] = {
> +	static const u8 rfseq_rx2tx_events_rev3_ipa[] = {
>  		NPHY_REV3_RFSEQ_CMD_NOP,
>  		NPHY_REV3_RFSEQ_CMD_RXG_FBW,
>  		NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
> @@ -16121,15 +16118,15 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
>  		NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
>  		NPHY_REV3_RFSEQ_CMD_END
>  	};
> -	u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
> -	u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
> +	static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
> +	static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
>  
>  	s16 alpha0, alpha1, alpha2;
>  	s16 beta0, beta1, beta2;
>  	u32 leg_data_weights, ht_data_weights, nss1_data_weights,
>  	    stbc_data_weights;
>  	u8 chan_freq_range = 0;
> -	u16 dac_control = 0x0002;
> +	static const u16 dac_control = 0x0002;
>  	u16 aux_adc_vmid_rev7_core0[] = { 0x8e, 0x96, 0x96, 0x96 };
>  	u16 aux_adc_vmid_rev7_core1[] = { 0x8f, 0x9f, 0x9f, 0x96 };
>  	u16 aux_adc_vmid_rev4[] = { 0xa2, 0xb4, 0xb4, 0x89 };
> @@ -16139,8 +16136,8 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
>  	u16 aux_adc_gain_rev4[] = { 0x02, 0x02, 0x02, 0x00 };
>  	u16 aux_adc_gain_rev3[] = { 0x02, 0x02, 0x02, 0x00 };
>  	u16 *aux_adc_gain;
> -	u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
> -	u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
> +	static const u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
> +	static const u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
>  	s32 min_nvar_val = 0x18d;
>  	s32 min_nvar_offset_6mbps = 20;
>  	u8 pdetrange;
> @@ -16151,9 +16148,9 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
>  	u16 rfseq_rx2tx_lpf_h_hpc_rev7 = 0x77;
>  	u16 rfseq_tx2rx_lpf_h_hpc_rev7 = 0x77;
>  	u16 rfseq_pktgn_lpf_h_hpc_rev7 = 0x77;
> -	u16 rfseq_htpktgn_lpf_hpc_rev7[] = { 0x77, 0x11, 0x11 };
> -	u16 rfseq_pktgn_lpf_hpc_rev7[] = { 0x11, 0x11 };
> -	u16 rfseq_cckpktgn_lpf_hpc_rev7[] = { 0x11, 0x11 };
> +	static const u16 rfseq_htpktgn_lpf_hpc_rev7[] = { 0x77, 0x11, 0x11 };
> +	static const u16 rfseq_pktgn_lpf_hpc_rev7[] = { 0x11, 0x11 };
> +	static const u16 rfseq_cckpktgn_lpf_hpc_rev7[] = { 0x11, 0x11 };
>  	u16 ipalvlshift_3p3_war_en = 0;
>  	u16 rccal_bcap_val, rccal_scap_val;
>  	u16 rccal_tx20_11b_bcap = 0;
> @@ -24291,13 +24288,13 @@ static void wlc_phy_update_txcal_ladder_nphy(struct brcms_phy *pi, u16 core)
>  	u16 bbmult;
>  	u16 tblentry;
>  
> -	struct nphy_txiqcal_ladder ladder_lo[] = {
> +	static const struct nphy_txiqcal_ladder ladder_lo[] = {
>  		{3, 0}, {4, 0}, {6, 0}, {9, 0}, {13, 0}, {18, 0},
>  		{25, 0}, {25, 1}, {25, 2}, {25, 3}, {25, 4}, {25, 5},
>  		{25, 6}, {25, 7}, {35, 7}, {50, 7}, {71, 7}, {100, 7}
>  	};
>  
> -	struct nphy_txiqcal_ladder ladder_iq[] = {
> +	static const struct nphy_txiqcal_ladder ladder_iq[] = {
>  		{3, 0}, {4, 0}, {6, 0}, {9, 0}, {13, 0}, {18, 0},
>  		{25, 0}, {35, 0}, {50, 0}, {71, 0}, {100, 0}, {100, 1},
>  		{100, 2}, {100, 3}, {100, 4}, {100, 5}, {100, 6}, {100, 7}
> @@ -25773,67 +25770,67 @@ wlc_phy_cal_txiqlo_nphy(struct brcms_phy *pi, struct nphy_txgains target_gain,
>  	u16 cal_gain[2];
>  	struct nphy_iqcal_params cal_params[2];
>  	u32 tbl_len;
> -	void *tbl_ptr;
> +	const void *tbl_ptr;
>  	bool ladder_updated[2];
>  	u8 mphase_cal_lastphase = 0;
>  	int bcmerror = 0;
>  	bool phyhang_avoid_state = false;
>  
> -	u16 tbl_tx_iqlo_cal_loft_ladder_20[] = {
> +	static const u16 tbl_tx_iqlo_cal_loft_ladder_20[] = {
>  		0x0300, 0x0500, 0x0700, 0x0900, 0x0d00, 0x1100, 0x1900, 0x1901,
>  		0x1902,
>  		0x1903, 0x1904, 0x1905, 0x1906, 0x1907, 0x2407, 0x3207, 0x4607,
>  		0x6407
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_iqimb_ladder_20[] = {
> +	static const u16 tbl_tx_iqlo_cal_iqimb_ladder_20[] = {
>  		0x0200, 0x0300, 0x0600, 0x0900, 0x0d00, 0x1100, 0x1900, 0x2400,
>  		0x3200,
>  		0x4600, 0x6400, 0x6401, 0x6402, 0x6403, 0x6404, 0x6405, 0x6406,
>  		0x6407
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_loft_ladder_40[] = {
> +	static const u16 tbl_tx_iqlo_cal_loft_ladder_40[] = {
>  		0x0200, 0x0300, 0x0400, 0x0700, 0x0900, 0x0c00, 0x1200, 0x1201,
>  		0x1202,
>  		0x1203, 0x1204, 0x1205, 0x1206, 0x1207, 0x1907, 0x2307, 0x3207,
>  		0x4707
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_iqimb_ladder_40[] = {
> +	static const u16 tbl_tx_iqlo_cal_iqimb_ladder_40[] = {
>  		0x0100, 0x0200, 0x0400, 0x0700, 0x0900, 0x0c00, 0x1200, 0x1900,
>  		0x2300,
>  		0x3200, 0x4700, 0x4701, 0x4702, 0x4703, 0x4704, 0x4705, 0x4706,
>  		0x4707
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_startcoefs[] = {
> +	static const u16 tbl_tx_iqlo_cal_startcoefs[] = {
>  		0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>  		0x0000
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_cmds_fullcal[] = {
> +	static const u16 tbl_tx_iqlo_cal_cmds_fullcal[] = {
>  		0x8123, 0x8264, 0x8086, 0x8245, 0x8056,
>  		0x9123, 0x9264, 0x9086, 0x9245, 0x9056
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_cmds_recal[] = {
> +	static const u16 tbl_tx_iqlo_cal_cmds_recal[] = {
>  		0x8101, 0x8253, 0x8053, 0x8234, 0x8034,
>  		0x9101, 0x9253, 0x9053, 0x9234, 0x9034
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_startcoefs_nphyrev3[] = {
> +	static const u16 tbl_tx_iqlo_cal_startcoefs_nphyrev3[] = {
>  		0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>  		0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
>  		0x0000
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_cmds_fullcal_nphyrev3[] = {
> +	static const u16 tbl_tx_iqlo_cal_cmds_fullcal_nphyrev3[] = {
>  		0x8434, 0x8334, 0x8084, 0x8267, 0x8056, 0x8234,
>  		0x9434, 0x9334, 0x9084, 0x9267, 0x9056, 0x9234
>  	};
>  
> -	u16 tbl_tx_iqlo_cal_cmds_recal_nphyrev3[] = {
> +	static const u16 tbl_tx_iqlo_cal_cmds_recal_nphyrev3[] = {
>  		0x8423, 0x8323, 0x8073, 0x8256, 0x8045, 0x8223,
>  		0x9423, 0x9323, 0x9073, 0x9256, 0x9045, 0x9223
>  	};
> 

[toc] | [prev] | [next] | [standalone]

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

Arend Van Spriel <arend.vanspriel@broadcom.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@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.

-- 
Kalle Valo

[toc] | [prev] | [next] | [standalone]

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

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

       Arnd

[toc] | [prev] | [next] | [standalone]

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

Arnd Bergmann <arnd@arndb.de> writes:

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

[toc] | [prev] | [next] | [standalone]

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

On 7-3-2017 10:44, Kalle Valo wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
>> On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>> Arend Van Spriel <arend.vanspriel@broadcom.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@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

[toc] | [prev] | [next] | [standalone]

#1591339 — [PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN

Enabling CONFIG_KASAN can lead to an instant stack overflow:

drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_generic_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 30464 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_broadwell_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the frame size of 5376 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_skl_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2628:1: error: the frame size of 5296 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

The reason is the INTEL_GVT_MMIO_OFFSET() hack that attempts to convert any type
(including i915_reg_t) into a u32 by reading the first four bytes, in combination
with the stack sanitizer that adds a redzone around each instance.

Originally, i915_reg_t was introduced to add a little extra type safety by
disallowing simple type casts, and INTEL_GVT_MMIO_OFFSET() goes the opposite
way by allowing any type as input, including those that are not safe in this
context.

I'm replacing it with an implementation that specifically allows the three
types that are actually used as input: 'i915_reg_t' (from _MMIO constants),
'int' (from other constants), and 'unsigned int' (from function arguments),
and any other type should now provoke a build error. This also solves the
stack overflow as we no longer use a local variable for each instance.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/gpu/drm/i915/gvt/mmio.h | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/mmio.h b/drivers/gpu/drm/i915/gvt/mmio.h
index 3bc620f56f35..bf40100fc626 100644
--- a/drivers/gpu/drm/i915/gvt/mmio.h
+++ b/drivers/gpu/drm/i915/gvt/mmio.h
@@ -78,13 +78,20 @@ bool intel_gvt_match_device(struct intel_gvt *gvt, unsigned long device);
 int intel_gvt_setup_mmio_info(struct intel_gvt *gvt);
 void intel_gvt_clean_mmio_info(struct intel_gvt *gvt);
 
+static inline u32 intel_gvt_mmio_offset(unsigned int offset)
+{
+	return offset;
+}
+
 struct intel_gvt_mmio_info *intel_gvt_find_mmio_info(struct intel_gvt *gvt,
 						     unsigned int offset);
-#define INTEL_GVT_MMIO_OFFSET(reg) ({ \
-	typeof(reg) __reg = reg; \
-	u32 *offset = (u32 *)&__reg; \
-	*offset; \
-})
+#define INTEL_GVT_MMIO_OFFSET(reg) \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), int), intel_gvt_mmio_offset, \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), unsigned int), intel_gvt_mmio_offset, \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), i915_reg_t), i915_mmio_reg_offset, \
+	(void)(0) \
+)))(reg)
+
 
 int intel_vgpu_init_mmio(struct intel_vgpu *vgpu);
 void intel_vgpu_reset_mmio(struct intel_vgpu *vgpu);
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1591358 — Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote:
> The internal logging infrastructure in ocfs2 causes special warning code to be
> used with KASAN, which produces rather large stack frames:

> fs/ocfs2/super.c: In function 'ocfs2_fill_super':
> fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

At least by default it doesn't seem to.

gcc 6.2 allyesconfig, CONFIG_KASAN=y
with either CONFIG_KASAN_INLINE or CONFIG_KASAN_OUTLINE

gcc doesn't emit a stack warning

> By simply passing the mask by value instead of reference, we can avoid the
> problem completely.

Any idea why that's so?
 
>  On 64-bit architectures, this is also more efficient,

Efficient true, but the same overall stack no?

> while on the less common (at least among ocfs2 users) 32-bit architectures,
> I'm guessing that the resulting code is comparable to what it was before.
> 
> The current version was introduced by Joe Perches as an optimization, maybe
> he can see if my change regresses compared to his.

I don't see it.

> Cc: Joe Perches <joe@perches.com>
> Fixes: 7c2bd2f930ae ("ocfs2: reduce object size of mlog uses")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  fs/ocfs2/cluster/masklog.c | 10 +++++-----
>  fs/o cfs2/cluster/masklog.h |  4 ++--
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
> index d331c2386b94..9720c5443e4d 100644
> --- a/fs/ocfs2/cluster/masklog.c
> +++ b/fs/ocfs2/cluster/masklog.c
> @@ -64,7 +64,7 @@ static ssize_t mlog_mask_store(u64 mask, const char *buf, size_t count)
>  	return count;
>  }
>  
> -void __mlog_printk(const u64 *mask, const char *func, int line,
> +void __mlog_printk(const u64 mask, const char *func, int line,
>  		   const char *fmt, ...)
>  {
>  	struct va_format vaf;
> @@ -72,14 +72,14 @@ void __mlog_printk(const u64 *mask, const char *func, int line,
>  	const char *level;
>  	const char *prefix = "";
>  
> -	if (!__mlog_test_u64(*mask, mlog_and_bits) ||
> -	    __mlog_test_u64(*mask, mlog_not_bits))
> +	if (!__mlog_test_u64(mask, mlog_and_bits) ||
> +	    __mlog_test_u64(mask, mlog_not_bits))
>  		return;
>  
> -	if (*mask & ML_ERROR) {
> +	if (mask & ML_ERROR) {
>  		level = KERN_ERR;
>  		prefix = "ERROR: ";
> -	} else if (*mask & ML_NOTICE) {
> +	} else if (mask & ML_NOTICE) {
>  		level = KERN_NOTICE;
>  	} else {
>  		level = KERN_INFO;
> diff --git a/fs/ocfs2/cluster/masklog.h b/fs/ocfs2/cluster/masklog.h
> index 308ea0eb35fd..0d0f4bf2c3d8 100644
> --- a/fs/ocfs2/cluster/masklog.h
> +++ b/fs/ocfs2/cluster/masklog.h
> @@ -163,7 +163,7 @@ extern struct mlog_bits mlog_and_bits, mlog_not_bits;
>  #endif
>  
>  __printf(4, 5)
> -void __mlog_printk(const u64 *m, const char *func, int line,
> +void __mlog_printk(const u64 m, const char *func, int line,
>  		   const char *fmt, ...);
>  
>  /*
> @@ -174,7 +174,7 @@ void __mlog_printk(const u64 *m, const char *func, int line,
>  do {									\
>  	u64 _m = MLOG_MASK_PREFIX | (mask);				\
>  	if (_m & ML_ALLOWED_BITS)					\
> -		__mlog_printk(&_m, __func__, __LINE__, fmt,		\
> +		__mlog_printk(_m, __func__, __LINE__, fmt,		\
>  			      ##__VA_ARGS__);				\
>  } while (0)
>  

[toc] | [prev] | [next] | [standalone]

#1591527 — Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote:
> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches <joe@perches.com> wrote:
> > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote:
> > > The internal logging infrastructure in ocfs2 causes special warning code to be
> > > used with KASAN, which produces rather large stack frames:
> > > fs/ocfs2/super.c: In function 'ocfs2_fill_super':
> > > fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
> > 
> > At least by default it doesn't seem to.
> > 
> > gcc 6.2 allyesconfig, CONFIG_KASAN=y
> > with either CONFIG_KASAN_INLINE or CONFIG_KASAN_OUTLINE
> > 
> > gcc doesn't emit a stack warning
> 
> The warning is disabled until patch 26/26. which picks the 3072 default.
> The 3264 number was with gcc-7, which is worse than gcc-6 since it enables
> an extra check.
> 
> > > By simply passing the mask by value instead of reference, we can avoid the
> > > problem completely.
> > 
> > Any idea why that's so?
> 
> With KASAN, every time we inline the function, the compiler has to allocate
> space for another copy of the variable plus a redzone to detect whether
> passing it by reference into another function causes an overflow at runtime.

These logging functions aren't inlined.
You're referring to the stack frame?

> > >  On 64-bit architectures, this is also more efficient,
> > 
> > Efficient true, but the same overall stack no?
> 
> Here is what I see with CONFIG_FRAME_WARN=300 and x86_64-linux-gcc-6.3.1:
> 
> before:
[]
> fs/ocfs2/super.c:1219:1: error: the frame size of 552 bytes is larger
> than 300 bytes [-Werror=frame-larger-than=]
> 
> after:
> fs/ocfs2/super.c: In function 'ocfs2_fill_super':
> fs/ocfs2/super.c:1219:1: error: the frame size of 472 bytes is larger
> than 300 bytes [-Werror=frame-larger-than=]
> 
> and with gcc-7.0.1 (including -fsanitize-address-use-after-scope), before:
[]
> fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger
> than 300 bytes [-Werror=frame-larger-than=]
> 
> after:
> fs/ocfs2/super.c: In function 'ocfs2_fill_super':
> fs/ocfs2/super.c:1219:1: error: the frame size of 704 bytes is larger
> than 300 bytes [-Werror=frame-larger-than=]

Still doesn't make sense to me.

None of the logging functions are inlined as they are all
EXPORT_SYMBOL.

This just changes a pointer to a u64, which is the same
size on x86-64 (and is of course larger on x86-32).

Perhaps KASAN has the odd behavior and working around
KASAN's behavior may not be the proper thing to do.

Maybe if CONFIG_KASAN is set, the minimum stack should
be increased via THREAD_SIZE_ORDER or some such.

[toc] | [prev] | [next] | [standalone]

#1591539 — Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, Mar 2, 2017 at 11:40 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote:
>> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches <joe@perches.com> wrote:
>> > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote:
>> > > The internal logging infrastructure in ocfs2 causes special warning code to be
>> > > used with KASAN, which produces rather large stack frames:
>> > > fs/ocfs2/super.c: In function 'ocfs2_fill_super':
>> > > fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
>> >
>> > At least by default it doesn't seem to.
>> >
>> > gcc 6.2 allyesconfig, CONFIG_KASAN=y
>> > with either CONFIG_KASAN_INLINE or CONFIG_KASAN_OUTLINE
>> >
>> > gcc doesn't emit a stack warning
>>
>> The warning is disabled until patch 26/26. which picks the 3072 default.
>> The 3264 number was with gcc-7, which is worse than gcc-6 since it enables
>> an extra check.
>>
>> > > By simply passing the mask by value instead of reference, we can avoid the
>> > > problem completely.
>> >
>> > Any idea why that's so?
>>
>> With KASAN, every time we inline the function, the compiler has to allocate
>> space for another copy of the variable plus a redzone to detect whether
>> passing it by reference into another function causes an overflow at runtime.
>
> These logging functions aren't inlined.

Sorry, my mistake. In this case mlog() is a macro, not an inline functions.
The effect is the same though.

> You're referring to the stack frame?

The stack frame of the function that calls mlog(), yes.
>
> Still doesn't make sense to me.
>
> None of the logging functions are inlined as they are all
> EXPORT_SYMBOL.

mlog() is placed in the calling function.

> This just changes a pointer to a u64, which is the same
> size on x86-64 (and is of course larger on x86-32).

KASAN decides that passing a pointer to _m into an extern function
(_mlog_printk) is potentially dangerous, as that function might
keep a reference to that pointer after it goes out of scope,
or it might not know the correct length of the stack object pointed to.

We can see from looking at the __mlog_printk() function definition
that it's actually safe, but the compiler cannot see that when looking
at another source file.

> Perhaps KASAN has the odd behavior and working around
> KASAN's behavior may not be the proper thing to do.

Turning off KASAN fixes the problem, but the entire purpose of
KASAN is to identify code that is potentially dangerous.

> Maybe if CONFIG_KASAN is set, the minimum stack should
> be increased via THREAD_SIZE_ORDER or some such.

This is what happened in 3f181b4d8652 ("lib/Kconfig.debug:
disable -Wframe-larger-than warnings with KASAN=y").

I'm trying to revert that patch so we actually get warnings
again about functions that are still dangerous. I picked 3072
as an arbitrary limit, as there are only a handful of files
that use larger stack frames in the worst case, but we can
only use that limit after fixing up all the warnings it shows.

       Arnd

[toc] | [prev] | [next] | [standalone]

#1591562 — Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, 2017-03-02 at 23:59 +0100, Arnd Bergmann wrote:
> KASAN decides that passing a pointer to _m into an extern function
> (_mlog_printk) is potentially dangerous, as that function might
> keep a reference to that pointer after it goes out of scope,
> or it might not know the correct length of the stack object pointed to.
> 
> We can see from looking at the __mlog_printk() function definition
> that it's actually safe, but the compiler cannot see that when looking
> at another source file.

OK, thanks.

btw:

changing __mlog_printk can save ~11% (90+KB) of object text size
by removing __func__ and __LINE__ and using vsprintf pointer extension
%pS, __builtin_return_address(0) as it is already used in dlmmaster.

(defconfig x86-64, with ocfs2)

$ size fs/ocfs2/built-in.o*
   text	   data	    bss	    dec	    hex	filename
 759791	 111373	 105688	 976852	  ee7d4	fs/ocfs2/built-in.o.new
 852959	 111373	 105688	1070020	 1053c4	fs/ocfs2/built-in.o.old

It's nearly the same output.

---

 fs/ocfs2/cluster/masklog.c | 8 ++++----
 fs/ocfs2/cluster/masklog.h | 8 +++-----
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
index d331c2386b94..a3f080f37108 100644
--- a/fs/ocfs2/cluster/masklog.c
+++ b/fs/ocfs2/cluster/masklog.c
@@ -64,8 +64,7 @@ static ssize_t mlog_mask_store(u64 mask, const char *buf, size_t count)
 	return count;
 }
 
-void __mlog_printk(const u64 *mask, const char *func, int line,
-		   const char *fmt, ...)
+void __mlog_printk(const u64 *mask, const char *fmt, ...)
 {
 	struct va_format vaf;
 	va_list args;
@@ -90,9 +89,10 @@ void __mlog_printk(const u64 *mask, const char *func, int line,
 	vaf.fmt = fmt;
 	vaf.va = &args;
 
-	printk("%s(%s,%u,%u):%s:%d %s%pV",
+	printk("%s(%s,%u,%u):%pS %s%pV",
 	       level, current->comm, task_pid_nr(current),
-	       raw_smp_processor_id(), func, line, prefix, &vaf);
+	       raw_smp_processor_id(), __builtin_return_address(0),
+	       prefix, &vaf);
 
 	va_end(args);
 }
diff --git a/fs/ocfs2/cluster/masklog.h b/fs/ocfs2/cluster/masklog.h
index 3c16da69605d..56ba5baf625b 100644
--- a/fs/ocfs2/cluster/masklog.h
+++ b/fs/ocfs2/cluster/masklog.h
@@ -162,9 +162,8 @@ extern struct mlog_bits mlog_and_bits, mlog_not_bits;
 
 #endif
 
-__printf(4, 5) __nocapture(2)
-void __mlog_printk(const u64 *m, const char *func, int line,
-		   const char *fmt, ...);
+__printf(2, 3) __nocapture(2)
+void __mlog_printk(const u64 *m, const char *fmt, ...);
 
 /*
  * Testing before the __mlog_printk call lets the compiler eliminate the
@@ -174,8 +173,7 @@ void __mlog_printk(const u64 *m, const char *func, int line,
 do {									\
 	u64 _m = MLOG_MASK_PREFIX | (mask);				\
 	if (_m & ML_ALLOWED_BITS)					\
-		__mlog_printk(&_m, __func__, __LINE__, fmt,		\
-			      ##__VA_ARGS__);				\
+		__mlog_printk(&_m, fmt, ##__VA_ARGS__);			\
 } while (0)
 
 #define mlog_errno(st) ({						\

[toc] | [prev] | [next] | [standalone]

#1591532 — Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote:
>> The internal logging infrastructure in ocfs2 causes special warning code to be
>> used with KASAN, which produces rather large stack frames:
>
>> fs/ocfs2/super.c: In function 'ocfs2_fill_super':
>> fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
>
> At least by default it doesn't seem to.
>
> gcc 6.2 allyesconfig, CONFIG_KASAN=y
> with either CONFIG_KASAN_INLINE or CONFIG_KASAN_OUTLINE
>
> gcc doesn't emit a stack warning

The warning is disabled until patch 26/26. which picks the 3072 default.
The 3264 number was with gcc-7, which is worse than gcc-6 since it enables
an extra check.

>> By simply passing the mask by value instead of reference, we can avoid the
>> problem completely.
>
> Any idea why that's so?

With KASAN, every time we inline the function, the compiler has to allocate
space for another copy of the variable plus a redzone to detect whether
passing it by reference into another function causes an overflow at runtime.

>>  On 64-bit architectures, this is also more efficient,
>
> Efficient true, but the same overall stack no?

Here is what I see with CONFIG_FRAME_WARN=300 and x86_64-linux-gcc-6.3.1:

before:
fs/ocfs2/super.c: In function 'ocfs2_parse_options.isra.3':
fs/ocfs2/super.c:1508:1: error: the frame size of 352 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]
fs/ocfs2/super.c: In function 'ocfs2_enable_quotas':
fs/ocfs2/super.c:974:1: error: the frame size of 344 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]
fs/ocfs2/super.c: In function 'ocfs2_fill_super':
fs/ocfs2/super.c:1219:1: error: the frame size of 552 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]

after:
fs/ocfs2/super.c: In function 'ocfs2_fill_super':
fs/ocfs2/super.c:1219:1: error: the frame size of 472 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]

and with gcc-7.0.1 (including -fsanitize-address-use-after-scope), before:
fs/ocfs2/super.c: In function 'ocfs2_check_volume':
fs/ocfs2/super.c:2512:1: error: the frame size of 768 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]
fs/ocfs2/super.c: In function 'ocfs2_statfs':
fs/ocfs2/super.c:1717:1: error: the frame size of 320 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]
fs/ocfs2/super.c: In function 'ocfs2_parse_options.isra.3':
fs/ocfs2/super.c:1508:1: error: the frame size of 464 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]
fs/ocfs2/super.c: In function 'ocfs2_enable_quotas':
fs/ocfs2/super.c:974:1: error: the frame size of 320 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]
fs/ocfs2/super.c: In function 'ocfs2_remount':
fs/ocfs2/super.c:752:1: error: the frame size of 568 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]
fs/ocfs2/super.c: In function 'ocfs2_initialize_super.isra.8':
fs/ocfs2/super.c:2339:1: error: the frame size of 1712 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]
fs/ocfs2/super.c: In function 'ocfs2_fill_super':
fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]

after:
fs/ocfs2/super.c: In function 'ocfs2_fill_super':
fs/ocfs2/super.c:1219:1: error: the frame size of 704 bytes is larger
than 300 bytes [-Werror=frame-larger-than=]

     Arnd

[toc] | [prev] | [next] | [standalone]

#1591402 — [PATCH 24/26] ocfs2: reduce stack size with KASAN

The internal logging infrastructure in ocfs2 causes special warning code to be
used with KASAN, which produces rather large stack frames:

fs/ocfs2/super.c: In function 'ocfs2_fill_super':
fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

By simply passing the mask by value instead of reference, we can avoid the
problem completely. On 64-bit architectures, this is also more efficient,
while on the less common (at least among ocfs2 users) 32-bit architectures,
I'm guessing that the resulting code is comparable to what it was before.

The current version was introduced by Joe Perches as an optimization, maybe
he can see if my change regresses compared to his.

Cc: Joe Perches <joe@perches.com>
Fixes: 7c2bd2f930ae ("ocfs2: reduce object size of mlog uses")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/ocfs2/cluster/masklog.c | 10 +++++-----
 fs/ocfs2/cluster/masklog.h |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
index d331c2386b94..9720c5443e4d 100644
--- a/fs/ocfs2/cluster/masklog.c
+++ b/fs/ocfs2/cluster/masklog.c
@@ -64,7 +64,7 @@ static ssize_t mlog_mask_store(u64 mask, const char *buf, size_t count)
 	return count;
 }
 
-void __mlog_printk(const u64 *mask, const char *func, int line,
+void __mlog_printk(const u64 mask, const char *func, int line,
 		   const char *fmt, ...)
 {
 	struct va_format vaf;
@@ -72,14 +72,14 @@ void __mlog_printk(const u64 *mask, const char *func, int line,
 	const char *level;
 	const char *prefix = "";
 
-	if (!__mlog_test_u64(*mask, mlog_and_bits) ||
-	    __mlog_test_u64(*mask, mlog_not_bits))
+	if (!__mlog_test_u64(mask, mlog_and_bits) ||
+	    __mlog_test_u64(mask, mlog_not_bits))
 		return;
 
-	if (*mask & ML_ERROR) {
+	if (mask & ML_ERROR) {
 		level = KERN_ERR;
 		prefix = "ERROR: ";
-	} else if (*mask & ML_NOTICE) {
+	} else if (mask & ML_NOTICE) {
 		level = KERN_NOTICE;
 	} else {
 		level = KERN_INFO;
diff --git a/fs/ocfs2/cluster/masklog.h b/fs/ocfs2/cluster/masklog.h
index 308ea0eb35fd..0d0f4bf2c3d8 100644
--- a/fs/ocfs2/cluster/masklog.h
+++ b/fs/ocfs2/cluster/masklog.h
@@ -163,7 +163,7 @@ extern struct mlog_bits mlog_and_bits, mlog_not_bits;
 #endif
 
 __printf(4, 5)
-void __mlog_printk(const u64 *m, const char *func, int line,
+void __mlog_printk(const u64 m, const char *func, int line,
 		   const char *fmt, ...);
 
 /*
@@ -174,7 +174,7 @@ void __mlog_printk(const u64 *m, const char *func, int line,
 do {									\
 	u64 _m = MLOG_MASK_PREFIX | (mask);				\
 	if (_m & ML_ALLOWED_BITS)					\
-		__mlog_printk(&_m, __func__, __LINE__, fmt,		\
+		__mlog_printk(_m, __func__, __LINE__, fmt,		\
 			      ##__VA_ARGS__);				\
 } while (0)
 
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1591411 — [PATCH 23/26] mtd: cfi: reduce stack size with KASAN

When CONFIG_KASAN is used, we consume a lot of extra stack space:

drivers/mtd/chips/cfi_cmdset_0020.c: In function 'do_write_buffer':
drivers/mtd/chips/cfi_cmdset_0020.c:603:1: error: the frame size of 2080 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize':
drivers/mtd/chips/cfi_cmdset_0020.c:972:1: error: the frame size of 1936 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':
drivers/mtd/chips/cfi_cmdset_0001.c:1841:1: error: the frame size of 1776 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]

This marks some functions as noinline_for_kasan to keep reduce the
overall stack size.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/mtd/chips/cfi_cmdset_0020.c | 8 ++++----
 include/linux/mtd/map.h             | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0020.c b/drivers/mtd/chips/cfi_cmdset_0020.c
index 94d3eb42c4d5..8a21e030829c 100644
--- a/drivers/mtd/chips/cfi_cmdset_0020.c
+++ b/drivers/mtd/chips/cfi_cmdset_0020.c
@@ -244,7 +244,7 @@ static struct mtd_info *cfi_staa_setup(struct map_info *map)
 }
 
 
-static inline int do_read_onechip(struct map_info *map, struct flchip *chip, loff_t adr, size_t len, u_char *buf)
+static noinline_for_kasan int do_read_onechip(struct map_info *map, struct flchip *chip, loff_t adr, size_t len, u_char *buf)
 {
 	map_word status, status_OK;
 	unsigned long timeo;
@@ -728,7 +728,7 @@ cfi_staa_writev(struct mtd_info *mtd, const struct kvec *vecs,
 }
 
 
-static inline int do_erase_oneblock(struct map_info *map, struct flchip *chip, unsigned long adr)
+static noinline_for_kasan int do_erase_oneblock(struct map_info *map, struct flchip *chip, unsigned long adr)
 {
 	struct cfi_private *cfi = map->fldrv_priv;
 	map_word status, status_OK;
@@ -1029,7 +1029,7 @@ static void cfi_staa_sync (struct mtd_info *mtd)
 	}
 }
 
-static inline int do_lock_oneblock(struct map_info *map, struct flchip *chip, unsigned long adr)
+static noinline_for_kasan int do_lock_oneblock(struct map_info *map, struct flchip *chip, unsigned long adr)
 {
 	struct cfi_private *cfi = map->fldrv_priv;
 	map_word status, status_OK;
@@ -1175,7 +1175,7 @@ static int cfi_staa_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
 	}
 	return 0;
 }
-static inline int do_unlock_oneblock(struct map_info *map, struct flchip *chip, unsigned long adr)
+static noinline_for_kasan int do_unlock_oneblock(struct map_info *map, struct flchip *chip, unsigned long adr)
 {
 	struct cfi_private *cfi = map->fldrv_priv;
 	map_word status, status_OK;
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 3aa56e3104bb..8c2e241f45c7 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -316,7 +316,7 @@ static inline map_word map_word_or(struct map_info *map, map_word val1, map_word
 	return r;
 }
 
-static inline int map_word_andequal(struct map_info *map, map_word val1, map_word val2, map_word val3)
+static noinline_for_kasan int map_word_andequal(struct map_info *map, map_word val1, map_word val2, map_word val3)
 {
 	int i;
 
@@ -328,7 +328,7 @@ static inline int map_word_andequal(struct map_info *map, map_word val1, map_wor
 	return 1;
 }
 
-static inline int map_word_bitsset(struct map_info *map, map_word val1, map_word val2)
+static noinline_for_kasan int map_word_bitsset(struct map_info *map, map_word val1, map_word val2)
 {
 	int i;
 
@@ -362,7 +362,7 @@ static inline map_word map_word_load(struct map_info *map, const void *ptr)
 	return r;
 }
 
-static inline map_word map_word_load_partial(struct map_info *map, map_word orig, const unsigned char *buf, int start, int len)
+static noinline_for_kasan map_word map_word_load_partial(struct map_info *map, map_word orig, const unsigned char *buf, int start, int len)
 {
 	int i;
 
@@ -392,7 +392,7 @@ static inline map_word map_word_load_partial(struct map_info *map, map_word orig
 #define MAP_FF_LIMIT 8
 #endif
 
-static inline map_word map_word_ff(struct map_info *map)
+static noinline_for_kasan map_word map_word_ff(struct map_info *map)
 {
 	map_word r;
 	int i;
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1591515 — [PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN

With CONFIG_KASAN, this driver has shown a ridiculously large stack frame
in one configuration:

drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

In most builds, it's only about 3300 bytes, but that's still large anough to
risk a kernel stack overflow.

Marking the two register access functions as noinline_for_kasan avoids
the problem and brings the largest stack frame size down to 232 bytes.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/media/i2c/cx25840/cx25840-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c
index b8d3c070bfc1..fd72e5a11cb9 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -81,7 +81,7 @@ MODULE_PARM_DESC(debug, "Debugging messages [0=Off (default) 1=On]");
 /* ----------------------------------------------------------------------- */
 static void cx23888_std_setup(struct i2c_client *client);
 
-int cx25840_write(struct i2c_client *client, u16 addr, u8 value)
+noinline_for_kasan int cx25840_write(struct i2c_client *client, u16 addr, u8 value)
 {
 	u8 buffer[3];
 	buffer[0] = addr >> 8;
@@ -90,7 +90,7 @@ int cx25840_write(struct i2c_client *client, u16 addr, u8 value)
 	return i2c_master_send(client, buffer, 3);
 }
 
-int cx25840_write4(struct i2c_client *client, u16 addr, u32 value)
+noinline_for_kasan int cx25840_write4(struct i2c_client *client, u16 addr, u32 value)
 {
 	u8 buffer[6];
 	buffer[0] = addr >> 8;
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1591906

On Thu, Mar 2, 2017 at 5:38 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> It took a long while to get this done, but I'm finally ready
> to send the first half of the KASAN stack size patches that
> I did in response to the kernelci.org warnings.
>
> As before, it's worth mentioning that things are generally worse
> with gcc-7.0.1 because of the addition of -fsanitize-address-use-after-scope
> that are not present on kernelci, so my randconfig testing found
> a lot more than kernelci did.
>
> The main areas are:
>
> - READ_ONCE/WRITE_ONCE cause problems in lots of code
> - typecheck() causes huge problems in a few places
> - I'm introducing "noinline_for_kasan" and use it in a lot
>   of places that suffer from inline functions with local variables
>   - netlink, as used in various parts of the kernel
>   - a number of drivers/media drivers
>   - a handful of wireless network drivers
> - kmemcheck conflicts with -fsanitize-address-use-after-scope
>
> This series lets us add back a stack frame warning for 3072 bytes
> with -fsanitize-address-use-after-scope, or 2048 bytes without it.
>
> I have a follow-up series that further reduces the stack frame
> warning limit to 1280 bytes for all 64-bit architectures, and
> 1536 bytes with basic KASAN support (no -fsanitize-address-use-after-scope).
> For now, I'm only posting the first half, in order to keep
> it (barely) reviewable.
Can you please elaborate on why do you need this? Are you trying to
squeeze KASAN into some embedded device?
Noinlines sprayed over the codebase are hard to maintain, and certain
compiler changes may cause bloated stack frames in other places.
Maybe it should be enough to just increase the stack frame limit in
KASAN builds, as Dmitry suggested previously?
> Both series are tested with many hundred randconfig builds on both
> x86 and arm64, which are the only architectures supporting KASAN.
>
>         Arnd
>
>  [PATCH 01/26] compiler: introduce noinline_for_kasan annotation
>  [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE
>  [PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro
>  [PATCH 04/26] tty: kbd: reduce stack size with KASAN
>  [PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan
>  [PATCH 06/26] rocker: mark rocker_tlv_put_* functions as
>  [PATCH 07/26] brcmsmac: reduce stack size with KASAN
>  [PATCH 08/26] brcmsmac: make some local variables 'static const' to
>  [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy
>  [PATCH 10/26] brcmsmac: reindent split functions
>  [PATCH 11/26] rtlwifi: reduce stack usage for KASAN
>  [PATCH 12/26] wl3501_cs: reduce stack size for KASAN
>  [PATCH 13/26] rtl8180: reduce stack size for KASAN
>  [PATCH 14/26] [media] dvb-frontends: reduce stack size in i2c access
>  [PATCH 15/26] [media] tuners: i2c: reduce stack usage for
>  [PATCH 16/26] [media] i2c: adv7604: mark register access as
>  [PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN
>  [PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN
>  [PATCH 19/26] [media] r820t: mark register functions as
>  [PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce
>  [PATCH 21/26] drm/bridge: ps8622: reduce stack size for KASAN
>  [PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with
>  [PATCH 23/26] mtd: cfi: reduce stack size with KASAN
>  [PATCH 24/26] ocfs2: reduce stack size with KASAN
>  [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan
>  [PATCH 26/26] kasan: rework Kconfig settings
>
>  arch/x86/include/asm/switch_to.h                                 |    2 +-
>  drivers/gpu/drm/bridge/parade-ps8622.c                           |    2 +-
>  drivers/gpu/drm/i915/gvt/mmio.h                                  |   17 +-
>  drivers/isdn/hardware/eicon/Kconfig                              |    1 +
>  drivers/media/dvb-frontends/ascot2e.c                            |    3 +-
>  drivers/media/dvb-frontends/cxd2841er.c                          |    4 +-
>  drivers/media/dvb-frontends/drx39xyj/drxj.c                      |   14 +-
>  drivers/media/dvb-frontends/helene.c                             |    4 +-
>  drivers/media/dvb-frontends/horus3a.c                            |    2 +-
>  drivers/media/dvb-frontends/itd1000.c                            |    2 +-
>  drivers/media/dvb-frontends/mt312.c                              |    2 +-
>  drivers/media/dvb-frontends/si2165.c                             |   14 +-
>  drivers/media/dvb-frontends/stb0899_drv.c                        |    2 +-
>  drivers/media/dvb-frontends/stb6100.c                            |    2 +-
>  drivers/media/dvb-frontends/stv0367.c                            |    2 +-
>  drivers/media/dvb-frontends/stv090x.c                            |    2 +-
>  drivers/media/dvb-frontends/stv6110.c                            |    2 +-
>  drivers/media/dvb-frontends/stv6110x.c                           |    2 +-
>  drivers/media/dvb-frontends/tda8083.c                            |    2 +-
>  drivers/media/dvb-frontends/zl10039.c                            |    2 +-
>  drivers/media/i2c/adv7604.c                                      |    4 +-
>  drivers/media/i2c/cx25840/cx25840-core.c                         |    4 +-
>  drivers/media/i2c/ks0127.c                                       |    2 +-
>  drivers/media/tuners/r820t.c                                     |    4 +-
>  drivers/media/tuners/tuner-i2c.h                                 |   15 +-
>  drivers/media/usb/em28xx/em28xx-dvb.c                            |  947 +++++++++++++++++++++------------------
>  drivers/mtd/chips/cfi_cmdset_0020.c                              |    8 +-
>  drivers/net/ethernet/rocker/rocker_tlv.h                         |   24 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c     | 1860 +++++++++++++++++++++++++++++++++++++----------------------------------------
>  drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c         |    4 +-
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c |   41 +-
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c |   26 +-
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c |   34 +-
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c |   36 +-
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c |   38 +-
>  drivers/net/wireless/wl3501_cs.c                                 |   10 +-
>  drivers/tty/vt/keyboard.c                                        |    6 +-
>  fs/ocfs2/cluster/masklog.c                                       |   10 +-
>  fs/ocfs2/cluster/masklog.h                                       |    4 +-
>  fs/overlayfs/util.c                                              |    6 +-
>  include/linux/compiler.h                                         |   58 ++-
>  include/linux/mtd/map.h                                          |    8 +-
>  include/linux/typecheck.h                                        |    7 +-
>  include/net/netlink.h                                            |   36 +-
>  lib/Kconfig.debug                                                |    9 +-
>  lib/Kconfig.kasan                                                |   11 +-
>  lib/Kconfig.kmemcheck                                            |    1 +
>  scripts/Makefile.kasan                                           |    3 +
>  48 files changed, 1670 insertions(+), 1629 deletions(-)
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[toc] | [prev] | [next] | [standalone]

#1591923

On Fri, Mar 3, 2017 at 1:25 PM, Alexander Potapenko <glider@google.com> wrote:
> On Thu, Mar 2, 2017 at 5:38 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> It took a long while to get this done, but I'm finally ready
>> to send the first half of the KASAN stack size patches that
>> I did in response to the kernelci.org warnings.
>>
>> As before, it's worth mentioning that things are generally worse
>> with gcc-7.0.1 because of the addition of -fsanitize-address-use-after-scope
>> that are not present on kernelci, so my randconfig testing found
>> a lot more than kernelci did.
>>
>> The main areas are:
>>
>> - READ_ONCE/WRITE_ONCE cause problems in lots of code
>> - typecheck() causes huge problems in a few places
>> - I'm introducing "noinline_for_kasan" and use it in a lot
>>   of places that suffer from inline functions with local variables
>>   - netlink, as used in various parts of the kernel
>>   - a number of drivers/media drivers
>>   - a handful of wireless network drivers
>> - kmemcheck conflicts with -fsanitize-address-use-after-scope
>>
>> This series lets us add back a stack frame warning for 3072 bytes
>> with -fsanitize-address-use-after-scope, or 2048 bytes without it.
>>
>> I have a follow-up series that further reduces the stack frame
>> warning limit to 1280 bytes for all 64-bit architectures, and
>> 1536 bytes with basic KASAN support (no -fsanitize-address-use-after-scope).
>> For now, I'm only posting the first half, in order to keep
>> it (barely) reviewable.
>
> Can you please elaborate on why do you need this? Are you trying to
> squeeze KASAN into some embedded device?
> Noinlines sprayed over the codebase are hard to maintain, and certain
> compiler changes may cause bloated stack frames in other places.
> Maybe it should be enough to just increase the stack frame limit in
> KASAN builds, as Dmitry suggested previously?

The current state of mainline has doubled the kernel stack size with
KASAN, and completely turned off the warning for per-function
stack frames. In some cases, this is completely broken as we have
functions that exceed even the 32kb per-thread stacks by themselves,
so I want to turn on the warning again and fix all the outliers.

The hard part is deciding what size is reasonable for a given function,
as smaller limits cause more harmless warnings while larger limits
can hide more actual problems. Before running into the KASAN
problem, I had already determined that we can lower the warning
limit for 64-bit architectures from 2048 bytes to 1280 with just
a handful of patches that are generally a good cleanup anyway.

This led me to picking three separate warning limits, based on
what I found reasonable to work around in the code:

3072 bytes with -fsanitize-address-use-after-scope
1536 bytes with KASAN but without -fsanitize-address-use-after-scope
1280 bytes on 64-bit without KASAN
1024 bytes on 32-bit architectures

If we use higher limits, the patch series will get a bit shorter. For
the limits above, I needed a total of 51 patches, while this shorter
series of 26 patches has slightly laxer limits:

3072 bytes with -fsanitize-address-use-after-scope
2048 bytes on 64-bit architectures with or without KASAN, but
          without  -fsanitize-address-use-after-scope
1024 bytes on 32-bit architectures

The individual patches should list the highest frame size I ran
into, so I can try to reduce the number of patches if you have
a suggestion for a different set of limits.

       Arnd

[toc] | [prev] | [next] | [standalone]

#1593531 — Re: [PATCH 10/26] brcmsmac: reindent split functions

Arend Van Spriel <arend.vanspriel@broadcom.com> writes:

> On 2-3-2017 17:38, Arnd Bergmann wrote:
>> In the previous commit I left the indentation alone to help reviewing
>> the patch, this one now runs the three new functions through 'indent -kr -8'
>> with some manual fixups to avoid silliness.
>> 
>> No changes other than whitespace are intended here.
>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>>  .../broadcom/brcm80211/brcmsmac/phy/phy_n.c        | 1507 +++++++++-----------
>>  1 file changed, 697 insertions(+), 810 deletions(-)
>> 

Arend, please edit your quotes. Leaving 1000 lines of unnecessary quotes
in your reply makes my use of patchwork horrible:

https://patchwork.kernel.org/patch/9601155/

-- 
Kalle Valo

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web