From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751179AbdBCQgg (ORCPT ); Fri, 3 Feb 2017 11:36:36 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:58173 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750953AbdBCQge (ORCPT ); Fri, 3 Feb 2017 11:36:34 -0500 From: Arnd Bergmann To: "David S. Miller" Cc: Arnd Bergmann , stable@vger.kernel.org, Yisen Zhuang , Salil Mehta , Daode Huang , Kejian Yan , Lisheng , oulijun , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN Date: Fri, 3 Feb 2017 17:35:46 +0100 Message-Id: <20170203163607.3488037-1-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 X-Provags-ID: V03:K0:j8jV7f6zGEVxh3pYWxG2aLeiS5HKOrTfjhgWoFAsbwS/GP+iQGZ z4Y50e2bH/upFQVTvkL1FrPAwcD7n3gGt4h1eSg15QeXlTaG8YatmRV0iyG/iTqgoap+MDQ 5fNbiWlBX54tIpPIGGM2wj5ERFf/rGUgAphNcaG23/6TBMwZJHL+mZfu/a54rNfdhLC5LOD uzpAwf4j/rzoh3GQpY2bw== X-UI-Out-Filterresults: notjunk:1;V01:K0:dKcD90A6PAI=:sx2a6N0HjHywYNJRVx5WzI gRD14bzUuyDj8OIgPz1A4bSHWZFnH+fXITQDgaTR5xSvxDGxJqHl0zkwkclaGnO5fMrHuLADn 3jCm4ydum4YalPcEPpDVEs4XhfF/8ZLfkg3rtsX49qxaAoxb12CfYz1hZW926cLpt5Mn/I2HS IZUvNTcw6Td7dKeZojE8eutrnoljN4K91WRgXS8BVynkWA9AAnFm2kofQ5rVHkQZAz7nzYCLr pwt74ik1A3fh56aLrxvROFna+2TLMw4rp1wo2Iv0rmwfIqNkddfmUOaq7nAZp7gFzcD1psn14 3QyHgvNyuDe9FZsgb1U5N29IRvahgFcVutvqpaY+lIM8u4xsLN9NbOgyuyvPsYfVKEK9MgucH c2um21rYvWJ7Oswh3ge6HhAVDkmksEl6sRtTpQT+5c76/hCS4A6XX0eR2mJUJETIjElZX16rS zJDEMVmMRzXp3pO/dEFLdpMHHoaFHjq3w9MTYEU/fV8QKXaiLk0M6gZNaYl4iSH/DzQCrKG/P wiEpwctECXPG6wjMbzKxRQu+fPApAIE2rAzkngC5uSGP7sd1/hhS6/lQY8Hre3wUpSYFV7yHc IjQNtlHJ+cvhNGU5RpWBcHR2SyKJNCZQUTlCRXAnLu3SrxCFYNN0rYF4OKm7Ctf2EGIDa5iP2 5XEbpvKuWBIJ+3KLPKC2AeBtALgv6peO1hc3SyT+CimT2Ha7kzSOkFlIDvz1rGLpyG1w= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use an indexed load for the register address, but it has an absolutely detrimental effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely kernel stack overflow aside from very complex object code: hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats': hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common': hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs': hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs': hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs': hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs': hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init': hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs': hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats': hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs': hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE seems safe anyway and it avoids a serious issue for some people. I have verified that with gcc-5.3.1, the object code we get is better in the new version both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte stack frame for hns_dsaf_get_regs() but otherwise have practically identical object code. With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already good either way. This patch is probably not urgent to get into 4.11 as only KASAN=y builds with certain compilers are affected, but I still think it makes sense to backport into older kernels. Cc: stable@vger.kernel.org Fixes: 511e6bc ("net: add Hisilicon Network Subsystem DSAF support") Signed-off-by: Arnd Bergmann --- --- drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h index 87226685f742..8fa18fc17cd2 100644 --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h @@ -1014,9 +1014,7 @@ static inline void dsaf_write_reg(void __iomem *base, u32 reg, u32 value) { - u8 __iomem *reg_addr = ACCESS_ONCE(base); - - writel(value, reg_addr + reg); + writel(value, base + reg); } #define dsaf_write_dev(a, reg, value) \ @@ -1024,9 +1022,7 @@ static inline void dsaf_write_reg(void __iomem *base, u32 reg, u32 value) static inline u32 dsaf_read_reg(u8 __iomem *base, u32 reg) { - u8 __iomem *reg_addr = ACCESS_ONCE(base); - - return readl(reg_addr + reg); + return readl(base + reg); } static inline void dsaf_write_syscon(struct regmap *base, u32 reg, u32 value) -- 2.9.0