From patchwork Mon Jun 19 18:29:40 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105923 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1032455qgd; Mon, 19 Jun 2017 12:37:07 -0700 (PDT) X-Received: by 10.84.174.67 with SMTP id q61mr30981063plb.60.1497901027624; Mon, 19 Jun 2017 12:37:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497901027; cv=none; d=google.com; s=arc-20160816; b=TXLRPe3uxnocLlhtUpq/zx7vYvySwc3dWVFD1/Ocr1vvMqDg40GsLv8zwUMTLVhZDP ciEereJpesCffxcfQ5ueUtMugV5IVkr0iT6CiSMsEOC1UTu0LEwfEEUV4KR0s+r8SMFl uT7QqrdRFFJ0m3AV9PDZ/vegD3WyTb0hZEgRo/NZKUccxlMnpc9YsxYsTU1hPtJ4+2lJ KU+vvb5QTEelT9l/k4qzUOstiQzfCTKIXaJU/KUxCq/vZlFyZq15lkA/HDqyhEZsoXDz hndwk8sNABGkiKsERgqc6iMsFy/9bSReVqsowhBacl5QG8ogDFA1K0xEqUNVqHCicYdU l0oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=cqWLyIxfMpli+7a2OTUj/f4uQb/TIu6jZJJPbjZqC14=; b=aD03Xz0rhSjWQcg1KFAunM6Z8HgKRiD0i0ZT19RUB1JEwpLLXhOgb9AqaAcZFmThMu Pr5IH/Fujuw3tLdhzMaDGkiK1WTnNbQWmOc5TyOK8TV9Jwj1UW65/rRjkEPPukzALLfJ J2pqvANYPMmCC19JHXZqJ3DbO+IT5+UFgxHZIQL7v1kD6GDrbOaUk3eR7+ZrdTDTk4gI cJqLd5WYzzPyr7yJriU2PHAdK7UDU7hj2lYrQ4XRc60XqXyJGVyXIf+TiSE5IvU5uHvs kYwpEMXPZ/ribZ/FtCiYHgDSdR2PlyS4iimniN3RKHqp1K4CRUtgZQn4216dF3U2CGkJ tt6A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u195si2394058pgc.412.2017.06.19.12.37.07; Mon, 19 Jun 2017 12:37:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752776AbdFSTgz (ORCPT + 25 others); Mon, 19 Jun 2017 15:36:55 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:51891 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752487AbdFSSed (ORCPT ); Mon, 19 Jun 2017 14:34:33 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIXG9v014947; Mon, 19 Jun 2017 20:33:16 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , David Howells , Yaowei Bai , James Morris , "Paul E. McKenney" , Andrew Morton , Linus Torvalds , Willy Tarreau Subject: [PATCH 3.10 081/268] cred/userns: define current_user_ns() as a function Date: Mon, 19 Jun 2017 20:29:40 +0200 Message-Id: <1497897167-14556-82-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit 0335695dfa4df01edff5bb102b9a82a0668ee51e upstream. The current_user_ns() macro currently returns &init_user_ns when user namespaces are disabled, and that causes several warnings when building with gcc-6.0 in code that compares the result of the macro to &init_user_ns itself: fs/xfs/xfs_ioctl.c: In function 'xfs_ioctl_setattr_check_projid': fs/xfs/xfs_ioctl.c:1249:22: error: self-comparison always evaluates to true [-Werror=tautological-compare] if (current_user_ns() == &init_user_ns) This is a legitimate warning in principle, but here it isn't really helpful, so I'm reprasing the definition in a way that shuts up the warning. Apparently gcc only warns when comparing identical literals, but it can figure out that the result of an inline function can be identical to a constant expression in order to optimize a condition yet not warn about the fact that the condition is known at compile time. This is exactly what we want here, and it looks reasonable because we generally prefer inline functions over macros anyway. Signed-off-by: Arnd Bergmann Acked-by: Serge Hallyn Cc: David Howells Cc: Yaowei Bai Cc: James Morris Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Willy Tarreau --- include/linux/capability.h | 2 -- include/linux/cred.h | 5 ++++- 2 files changed, 4 insertions(+), 3 deletions(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/include/linux/capability.h b/include/linux/capability.h index 9b4378a..eeb43c4 100644 --- a/include/linux/capability.h +++ b/include/linux/capability.h @@ -40,8 +40,6 @@ struct inode; struct dentry; struct user_namespace; -struct user_namespace *current_user_ns(void); - extern const kernel_cap_t __cap_empty_set; extern const kernel_cap_t __cap_init_eff_set; diff --git a/include/linux/cred.h b/include/linux/cred.h index 6c58dd7..cd3fb73 100644 --- a/include/linux/cred.h +++ b/include/linux/cred.h @@ -345,7 +345,10 @@ extern struct user_namespace init_user_ns; #ifdef CONFIG_USER_NS #define current_user_ns() (current_cred_xxx(user_ns)) #else -#define current_user_ns() (&init_user_ns) +static inline struct user_namespace *current_user_ns(void) +{ + return &init_user_ns; +} #endif From patchwork Mon Jun 19 18:30:03 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105912 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1014642qgd; Mon, 19 Jun 2017 11:51:08 -0700 (PDT) X-Received: by 10.84.178.131 with SMTP id z3mr31481876plb.175.1497898268762; Mon, 19 Jun 2017 11:51:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497898268; cv=none; d=google.com; s=arc-20160816; b=q6HvC8J+9PEC5PFs0E4NmLGq6qbr9VHUtCptmhAvQxGBWl2xUmdH7ZEpBJ/Ay+xSAM grqh59vRfAgPY0OmuzkmNhEZbC1EmWAmuN4wN/YXRx+adH3k1rk2tpVJpkFO4ZEoiKfH mmsEo2QuWCFrYvpGPqE7DqNK6pZFHwA1RvJMmdGPO6tz2NDQyO3eKx0Sa/Me41/ymuMk FoZeM8QPlfRnfgM9NI54WAxKD8F13gWinMMINiDKEhrMI5tAsxhj3KSpQV39gUbe7fRZ R27UHtGSplN5XYU0E2MOVDwfb/wN6GOmhLY1OHlIkli/hU8tcE/qyUSdAiBKm99pEGD9 Iqfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=tsR1yFPe6PuJKoGbiyHLlVlwgbp83o2KouhJ2gDfjII=; b=oCY+C0AkWRVAlUVO2Xrx6EV1aFdBRMzffmJugo1Tt49Y8Rwog/axJ4iSxA+fyuOw+Y gNK3Ro5PSZZSqVSFube9XFbkBu2QXi1rS04PcBDqhQw3EjUx6SI0gCZUrP0UP2H181A/ 2GD2HddU+VTnDK5K+CGKC9xV2L1ooLgm5dMkMjlNFAJcczksTHV+yjW/mcEdMmJOgM2R 7Px1nRO/MfTLEPAmhpoMkK2bc4PTcp2eeifrcKFltgq8zUzcSsjqgSB1oubKUocLKR4L n8Hye5JFGwqeKCIO+S7fCrKV6TJ4F3/fPo8g0YtM/H3FU4gNKkR5KB7CRQ6zsI0gRk/6 bGiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m10si5241864pln.457.2017.06.19.11.51.08; Mon, 19 Jun 2017 11:51:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753436AbdFSSu4 (ORCPT + 25 others); Mon, 19 Jun 2017 14:50:56 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52687 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753768AbdFSSiu (ORCPT ); Mon, 19 Jun 2017 14:38:50 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIXL0U014970; Mon, 19 Jun 2017 20:33:21 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Mark Rutland , Russell King , Russell King , Willy Tarreau Subject: [PATCH 3.10 104/268] ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs Date: Mon, 19 Jun 2017 20:30:03 +0200 Message-Id: <1497897167-14556-105-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mark Rutland commit ddc37832a1349f474c4532de381498020ed71d31 upstream. On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an undefined instruction trap within write_wb_reg. This is because Scorpion CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if the core is not powered down. When DBGPRSR.SPD is set, breakpoint and watchpoint registers are treated as undefined. It's possible to trigger similar crashes later on from userspace, by requesting the kernel to install a breakpoint or watchpoint, as we can go idle at any point between the reset of the debug registers and their later use. This has always been the case. Given that this has always been broken, no-one has complained until now, and there is no clear workaround, disable hardware breakpoints and watchpoints on Scorpion to avoid these issues. Signed-off-by: Mark Rutland Reported-by: Linus Walleij Reviewed-by: Stephen Boyd Acked-by: Will Deacon Cc: Russell King Signed-off-by: Russell King Signed-off-by: Willy Tarreau --- arch/arm/include/asm/cputype.h | 3 +++ arch/arm/kernel/hw_breakpoint.c | 16 ++++++++++++++++ 2 files changed, 19 insertions(+) -- 2.8.0.rc2.1.gbe9624a diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h index dba62cb..f389107 100644 --- a/arch/arm/include/asm/cputype.h +++ b/arch/arm/include/asm/cputype.h @@ -58,6 +58,9 @@ #define ARM_CPU_XSCALE_ARCH_V2 0x4000 #define ARM_CPU_XSCALE_ARCH_V3 0x6000 +/* Qualcomm implemented cores */ +#define ARM_CPU_PART_SCORPION 0x510002d0 + extern unsigned int processor_id; #ifdef CONFIG_CPU_CP15 diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c index 1fd749e..b0b69e9 100644 --- a/arch/arm/kernel/hw_breakpoint.c +++ b/arch/arm/kernel/hw_breakpoint.c @@ -1066,6 +1066,22 @@ static int __init arch_hw_breakpoint_init(void) return 0; } + /* + * Scorpion CPUs (at least those in APQ8060) seem to set DBGPRSR.SPD + * whenever a WFI is issued, even if the core is not powered down, in + * violation of the architecture. When DBGPRSR.SPD is set, accesses to + * breakpoint and watchpoint registers are treated as undefined, so + * this results in boot time and runtime failures when these are + * accessed and we unexpectedly take a trap. + * + * It's not clear if/how this can be worked around, so we blacklist + * Scorpion CPUs to avoid these issues. + */ + if ((read_cpuid_id() & 0xff00fff0) == ARM_CPU_PART_SCORPION) { + pr_info("Scorpion CPU detected. Hardware breakpoints and watchpoints disabled\n"); + return 0; + } + has_ossr = core_has_os_save_restore(); /* Determine how many BRPs/WRPs are available. */ From patchwork Mon Jun 19 18:30:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105909 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1009633qgd; Mon, 19 Jun 2017 11:37:41 -0700 (PDT) X-Received: by 10.99.7.129 with SMTP id 123mr27587588pgh.171.1497897461408; Mon, 19 Jun 2017 11:37:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497897461; cv=none; d=google.com; s=arc-20160816; b=uvs3gbqXLZxtGFz37qIn0uQg6hi8DckJvIPzyIAY2z5bj4IRUdLWcHtVvrwMjbo2af j5j8TLIMJdoMdT0ko+BwAjn635g4npfZoITtAXuaNEPvK3P2UfHFZcojpaKM2RizG7Xy VSP+jBmz5UPRcOAm90clnXifKYNS+bdpRu9ZjOuEQhEIH3GAlx8KyGPw895qJCzC1V46 7qQhhjVGq7ZABI4fKBD8ijOfWKXdoVJK1SMWVs8njxIqp6SgNIN2g8CKmnUJeaB1MkTG t3fIp3cMnW9swbXgsiy86M/fW+L8WSfTMX2HILQyjoORn/NjyWheJp1SUQIslJKfzRLx d5Dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=KTtEYdmaOWQh9h4kEj4U/R2XalVrBsSDOzkgqt1MR/s=; b=nTHOa2AJJyIhwFta9Ws7qcTvsAj7wLy0QRUf8mCgJ5INydOsjQ2WzD+gabL1ON7x00 ZJAu9CnqUXgKUlAYN2s9h4Rc/FMO9C31f1raRrNO/96pCEbMuhK5P8wyQUnJFwT8SteN Am0eWkyVGcR7NJpLslC2B4vYvwww1iBHM7EqBhWU7LFqoeln6VnM4+pmEy4eGnrtu3v8 BJj4pzgo9WCJ+wt8sBDHZn9ymnhubQYuOqKVA3fSINQjx/yn7s8askU4NQjXMiKy/Pou 57opHxUsPJRAs3soeMGshLmIGAE0H0OTZbRy2nRQwsCzR7t01EhudtJwQAb6c+IpNPYt MhRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1si9640186plb.301.2017.06.19.11.37.41; Mon, 19 Jun 2017 11:37:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753693AbdFSShf (ORCPT + 25 others); Mon, 19 Jun 2017 14:37:35 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52519 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753614AbdFSShd (ORCPT ); Mon, 19 Jun 2017 14:37:33 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIXT57015000; Mon, 19 Jun 2017 20:33:29 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Kefeng Wang , "David S . Miller" , Willy Tarreau Subject: [PATCH 3.10 134/268] ipv6: addrconf: Avoid addrconf_disable_change() using RCU read-side lock Date: Mon, 19 Jun 2017 20:30:33 +0200 Message-Id: <1497897167-14556-135-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Kefeng Wang commit 03e4deff4987f79c34112c5ba4eb195d4f9382b0 upstream. Just like commit 4acd4945cd1e ("ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock"), it is unnecessary to make addrconf_disable_change() use RCU iteration over the netdev list, since it already holds the RTNL lock, or we may meet Illegal context switch in RCU read-side critical section. Signed-off-by: Kefeng Wang Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau --- net/ipv6/addrconf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index a3e2c34..9c4aa2e 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -4768,8 +4768,7 @@ static void addrconf_disable_change(struct net *net, __s32 newf) struct net_device *dev; struct inet6_dev *idev; - rcu_read_lock(); - for_each_netdev_rcu(net, dev) { + for_each_netdev(net, dev) { idev = __in6_dev_get(dev); if (idev) { int changed = (!idev->cnf.disable_ipv6) ^ (!newf); @@ -4778,7 +4777,6 @@ static void addrconf_disable_change(struct net *net, __s32 newf) dev_disable_change(idev); } } - rcu_read_unlock(); } static int addrconf_disable_ipv6(struct ctl_table *table, int *p, int newf) From patchwork Mon Jun 19 18:31:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105908 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1009294qgd; Mon, 19 Jun 2017 11:36:43 -0700 (PDT) X-Received: by 10.99.110.132 with SMTP id j126mr27742960pgc.141.1497897403020; Mon, 19 Jun 2017 11:36:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497897403; cv=none; d=google.com; s=arc-20160816; b=Ogakwxzeo7twrk06Bo+DrvvfQJ1y/9/pdsnUL1NDIIIQSPWLMoQJk5CLxlmv9/Jufq N0tJAQWezMevQIoTwEKcwKMxQP8AYRnOqk1tZ+h4EDvOu1efH8H/gHnAHS0p+byBADwS BgVH6nw4cBtZkjIkLRWmPiM/fOtG94PkV/eNXD7LKGz4YTbwrh9ehvYHlX1Rga4stOVO lngV+NolZupsS04n5q+t6DiKzYlPnzRCqaABNESBUkR7ZRhJFCOXm6sdC3KnehmhUYcs HDXZXus2ZbxA+1WyuaZpVH8G7jR4HVrUM+lhX5hyWsefo0/8MkeRy0bJm5zOsNKWJdE3 dHEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=/RqYDPJLgMcHSEDaoV0nTyviGgl3y+BOqYXdJgtdQrE=; b=uzpavPa0BpnuJGh9745ns4wdJ9ersAOWLhYOWAtryS6HeLHlb0MknqfgUChMsGHRA4 6xdXGh/0zJynDE1TlSi446OscUipik5u1bba8yKeheVWUfKdjRKB8zNNINWgdjAczdeB e4yVQsXleHbpHs0awgGUr5YPryLkUMDJMfS4j55Gmo8Mbe8ucJjSR/FGN3X/zu+fTT8V vnkmFZEhhkdYqumbCX3/b1l3XrfM/be6jNewxsfTMdvvPhvq1SOAkFuDiMgpGwMUYQRF kvA9sMP4y0bED4adrsDaj+mFiKq72DUomFrqWZbVHBLs1vT9aiH5E2n6KfqA7aVOMPVL 57dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e10si8718475pga.447.2017.06.19.11.36.42; Mon, 19 Jun 2017 11:36:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753406AbdFSSgg (ORCPT + 25 others); Mon, 19 Jun 2017 14:36:36 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52352 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753380AbdFSSgd (ORCPT ); Mon, 19 Jun 2017 14:36:33 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIXg6A015040; Mon, 19 Jun 2017 20:33:42 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , Ralf Baechle , Herbert Xu , Willy Tarreau Subject: [PATCH 3.10 174/268] crypto: improve gcc optimization flags for serpent and wp512 Date: Mon, 19 Jun 2017 20:31:13 +0200 Message-Id: <1497897167-14556-175-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit 7d6e9105026788c497f0ab32fa16c82f4ab5ff61 upstream. An ancient gcc bug (first reported in 2003) has apparently resurfaced on MIPS, where kernelci.org reports an overly large stack frame in the whirlpool hash algorithm: crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 1024 bytes [-Wframe-larger-than=] With some testing in different configurations, I'm seeing large variations in stack frames size up to 1500 bytes for what should have around 300 bytes at most. I also checked the reference implementation, which is essentially the same code but also comes with some test and benchmarking infrastructure. It seems that recent compiler versions on at least arm, arm64 and powerpc have a partial fix for this problem, but enabling "-fsched-pressure", but even with that fix they suffer from the issue to a certain degree. Some testing on arm64 shows that the time needed to hash a given amount of data is roughly proportional to the stack frame size here, which makes sense given that the wp512 implementation is doing lots of loads for table lookups, and the problem with the overly large stack is a result of doing a lot more loads and stores for spilled registers (as seen from inspecting the object code). Disabling -fschedule-insns consistently fixes the problem for wp512, in my collection of cross-compilers, the results are consistently better or identical when comparing the stack sizes in this function, though some architectures (notable x86) have schedule-insns disabled by default. The four columns are: default: -O2 press: -O2 -fsched-pressure nopress: -O2 -fschedule-insns -fno-sched-pressure nosched: -O2 -no-schedule-insns (disables sched-pressure) default press nopress nosched alpha-linux-gcc-4.9.3 1136 848 1136 176 am33_2.0-linux-gcc-4.9.3 2100 2076 2100 2104 arm-linux-gnueabi-gcc-4.9.3 848 848 1048 352 cris-linux-gcc-4.9.3 272 272 272 272 frv-linux-gcc-4.9.3 1128 1000 1128 280 hppa64-linux-gcc-4.9.3 1128 336 1128 184 hppa-linux-gcc-4.9.3 644 308 644 276 i386-linux-gcc-4.9.3 352 352 352 352 m32r-linux-gcc-4.9.3 720 656 720 268 microblaze-linux-gcc-4.9.3 1108 604 1108 256 mips64-linux-gcc-4.9.3 1328 592 1328 208 mips-linux-gcc-4.9.3 1096 624 1096 240 powerpc64-linux-gcc-4.9.3 1088 432 1088 160 powerpc-linux-gcc-4.9.3 1080 584 1080 224 s390-linux-gcc-4.9.3 456 456 624 360 sh3-linux-gcc-4.9.3 292 292 292 292 sparc64-linux-gcc-4.9.3 992 240 992 208 sparc-linux-gcc-4.9.3 680 592 680 312 x86_64-linux-gcc-4.9.3 224 240 272 224 xtensa-linux-gcc-4.9.3 1152 704 1152 304 aarch64-linux-gcc-7.0.0 224 224 1104 208 arm-linux-gnueabi-gcc-7.0.1 824 824 1048 352 mips-linux-gcc-7.0.0 1120 648 1120 272 x86_64-linux-gcc-7.0.1 240 240 304 240 arm-linux-gnueabi-gcc-4.4.7 840 392 arm-linux-gnueabi-gcc-4.5.4 784 728 784 320 arm-linux-gnueabi-gcc-4.6.4 736 728 736 304 arm-linux-gnueabi-gcc-4.7.4 944 784 944 352 arm-linux-gnueabi-gcc-4.8.5 464 464 760 352 arm-linux-gnueabi-gcc-4.9.3 848 848 1048 352 arm-linux-gnueabi-gcc-5.3.1 824 824 1064 336 arm-linux-gnueabi-gcc-6.1.1 808 808 1056 344 arm-linux-gnueabi-gcc-7.0.1 824 824 1048 352 Trying the same test for serpent-generic, the picture is a bit different, and while -fno-schedule-insns is generally better here than the default, -fsched-pressure wins overall, so I picked that instead. default press nopress nosched alpha-linux-gcc-4.9.3 1392 864 1392 960 am33_2.0-linux-gcc-4.9.3 536 524 536 528 arm-linux-gnueabi-gcc-4.9.3 552 552 776 536 cris-linux-gcc-4.9.3 528 528 528 528 frv-linux-gcc-4.9.3 536 400 536 504 hppa64-linux-gcc-4.9.3 524 208 524 480 hppa-linux-gcc-4.9.3 768 472 768 508 i386-linux-gcc-4.9.3 564 564 564 564 m32r-linux-gcc-4.9.3 712 576 712 532 microblaze-linux-gcc-4.9.3 724 392 724 512 mips64-linux-gcc-4.9.3 720 384 720 496 mips-linux-gcc-4.9.3 728 384 728 496 powerpc64-linux-gcc-4.9.3 704 304 704 480 powerpc-linux-gcc-4.9.3 704 296 704 480 s390-linux-gcc-4.9.3 560 560 592 536 sh3-linux-gcc-4.9.3 540 540 540 540 sparc64-linux-gcc-4.9.3 544 352 544 496 sparc-linux-gcc-4.9.3 544 344 544 496 x86_64-linux-gcc-4.9.3 528 536 576 528 xtensa-linux-gcc-4.9.3 752 544 752 544 aarch64-linux-gcc-7.0.0 432 432 656 480 arm-linux-gnueabi-gcc-7.0.1 616 616 808 536 mips-linux-gcc-7.0.0 720 464 720 488 x86_64-linux-gcc-7.0.1 536 528 600 536 arm-linux-gnueabi-gcc-4.4.7 592 440 arm-linux-gnueabi-gcc-4.5.4 776 448 776 544 arm-linux-gnueabi-gcc-4.6.4 776 448 776 544 arm-linux-gnueabi-gcc-4.7.4 768 448 768 544 arm-linux-gnueabi-gcc-4.8.5 488 488 776 544 arm-linux-gnueabi-gcc-4.9.3 552 552 776 536 arm-linux-gnueabi-gcc-5.3.1 552 552 776 536 arm-linux-gnueabi-gcc-6.1.1 560 560 776 536 arm-linux-gnueabi-gcc-7.0.1 616 616 808 536 I did not do any runtime tests with serpent, so it is possible that stack frame size does not directly correlate with runtime performance here and it actually makes things worse, but it's more likely to help here, and the reduced stack frame size is probably enough reason to apply the patch, especially given that the crypto code is often used in deep call chains. Link: https://kernelci.org/build/id/58797d7559b5149efdf6c3a9/logs/ Link: http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11488 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 Cc: Ralf Baechle Signed-off-by: Arnd Bergmann Signed-off-by: Herbert Xu Signed-off-by: Willy Tarreau --- crypto/Makefile | 2 ++ 1 file changed, 2 insertions(+) -- 2.8.0.rc2.1.gbe9624a diff --git a/crypto/Makefile b/crypto/Makefile index b549165..139e7e0 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_CRYPTO_SHA1) += sha1_generic.o obj-$(CONFIG_CRYPTO_SHA256) += sha256_generic.o obj-$(CONFIG_CRYPTO_SHA512) += sha512_generic.o obj-$(CONFIG_CRYPTO_WP512) += wp512.o +CFLAGS_wp512.o := $(call cc-option,-fno-schedule-insns) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 obj-$(CONFIG_CRYPTO_TGR192) += tgr192.o obj-$(CONFIG_CRYPTO_GF128MUL) += gf128mul.o obj-$(CONFIG_CRYPTO_ECB) += ecb.o @@ -72,6 +73,7 @@ obj-$(CONFIG_CRYPTO_BLOWFISH_COMMON) += blowfish_common.o obj-$(CONFIG_CRYPTO_TWOFISH) += twofish_generic.o obj-$(CONFIG_CRYPTO_TWOFISH_COMMON) += twofish_common.o obj-$(CONFIG_CRYPTO_SERPENT) += serpent_generic.o +CFLAGS_serpent_generic.o := $(call cc-option,-fsched-pressure) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 obj-$(CONFIG_CRYPTO_AES) += aes_generic.o obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia_generic.o obj-$(CONFIG_CRYPTO_CAST_COMMON) += cast_common.o From patchwork Mon Jun 19 18:31:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105921 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1027893qgd; Mon, 19 Jun 2017 12:24:20 -0700 (PDT) X-Received: by 10.98.64.6 with SMTP id n6mr26588023pfa.196.1497900260193; Mon, 19 Jun 2017 12:24:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497900260; cv=none; d=google.com; s=arc-20160816; b=gFIBdmTCfox3DO7YB4a63TgUZupeDL6kHf4Hgo2z2PzW6+QjIiLYSvoN356zVicqE2 /Cd8npREN1NUCQiF22hHZK49R6MTLduNqYNKwSi+pwAMBHvQz6fNiOHejDPSKfpE2HEm vUuIHhRt1KlCf8ftPn4Bl8od3j/Wn23+eOtmB7kVh4h75UWGkX9AGZp51TFwZyXlS5WD 95tqKTZQTd8yF/+4FiFJ065U9S21smgqF/m5u/R9n5lBaqYIpBh03nhU+FT8uHHxCT8X b4V11bfuiOSuoDQ4EJuuQYOkp6h4z7m7UiRv8tkSyPId8cwapA8rxtW56JCF8dTDS/N2 Hn/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=l+mB5+MO11WShgyEiOkVtkAfb1Cm6oas90WSWpS5Y8g=; b=DH0Sp+NvmSUbMxCB+xSQgCG0vBDV4t7cxk0rvjehJ4eJTtEC/WUJiFIBViX0vHx4op xqRWwL7xn9MCVqxu8EZhNWCZznCUbt7xQsJloVPI6YohFrQUvmz6MHZ6vi6yFMVG8in2 e8bI/jI1iGFgk6Rbdw/mtGdWfLBfE75ALlflXCpF0kGGn3va3l2eKcNCKWscNdodx4Rz RagrAeHDzPUW8p0GrQFlkJfzlS51TLtSpR4dPz2urPwQeF6/9r6jJzXDlZh/kjpKbA6B 5OzpnOIpUi1v26iucNpfZLKS2Vd5GL7SizfKDaUHEQmSqr8ein1jcuoHFXrQY9QuPMEo t/AA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e63si8483264pgc.97.2017.06.19.12.24.19; Mon, 19 Jun 2017 12:24:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753282AbdFSTYC (ORCPT + 25 others); Mon, 19 Jun 2017 15:24:02 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52123 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753035AbdFSSfc (ORCPT ); Mon, 19 Jun 2017 14:35:32 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIXg0r015041; Mon, 19 Jun 2017 20:33:42 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , Brian Norris , Willy Tarreau Subject: [PATCH 3.10 175/268] mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy Date: Mon, 19 Jun 2017 20:31:14 +0200 Message-Id: <1497897167-14556-176-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit 906b268477bc03daaa04f739844c120fe4dbc991 upstream. kernelci.org reports a warning for this driver, as it copies a local variable into a 'const char *' string: drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of 'strncpy' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] Using kstrndup() simplifies the code and avoids the warning. Signed-off-by: Arnd Bergmann Acked-by: Marek Vasut Signed-off-by: Brian Norris Signed-off-by: Willy Tarreau --- drivers/mtd/maps/pmcmsp-flash.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/drivers/mtd/maps/pmcmsp-flash.c b/drivers/mtd/maps/pmcmsp-flash.c index f9fa3fa..2051f28 100644 --- a/drivers/mtd/maps/pmcmsp-flash.c +++ b/drivers/mtd/maps/pmcmsp-flash.c @@ -139,15 +139,13 @@ static int __init init_msp_flash(void) } msp_maps[i].bankwidth = 1; - msp_maps[i].name = kmalloc(7, GFP_KERNEL); + msp_maps[i].name = kstrndup(flash_name, 7, GFP_KERNEL); if (!msp_maps[i].name) { iounmap(msp_maps[i].virt); kfree(msp_parts[i]); goto cleanup_loop; } - msp_maps[i].name = strncpy(msp_maps[i].name, flash_name, 7); - for (j = 0; j < pcnt; j++) { part_name[5] = '0' + i; part_name[7] = '0' + j; From patchwork Mon Jun 19 18:31:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105913 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1014734qgd; Mon, 19 Jun 2017 11:51:24 -0700 (PDT) X-Received: by 10.98.156.131 with SMTP id u3mr26819306pfk.16.1497898284781; Mon, 19 Jun 2017 11:51:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497898284; cv=none; d=google.com; s=arc-20160816; b=x3rgKU1w8lzg+y43TcfydfTZR4rZXQ+siBfoRreJ5sE1dAwJP3zTjrzUB18fIUxuhI QSgFqKHEFiOGujWwAkizWGL81IH34Wd9mskysbZucnbxOY+OcCLa1D+xMbDExx051kMv WSZ/nY9VrTpYgEAlS1rCscBZmy8yaAOYyb86mYGn7Kj97DkocZEcyDVWZNwJUJWAHBB9 kwE8FpuBACMbz+mnHTh3A9ywg3nyD07j3xKcRReS+fDS3lzblg/PiRDjYPY0bdJsmcaD eEmJJsqjwkiVng6fU8GL3y8escuDJTlCx5zJIkeJtZpNvAUbYQ9yK7Z633NR0iGObI4a gY8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=88l+asgh/t6q1fFngU9FVZH7zDpeNk0KKUGUDoLoIxQ=; b=U90pOxYnXMQKg4Nl+NQsiAQprnnoznthmpiPORQowVmgmilJ40LkoZWIwbr+1kwfoS qD1+cq3lDwvArCEom6/8OY/bGmOQ6S92hNU8EhyuycKfRLIM1uEkdj9TmxXxAVCJtbdq CcYqt1XeH3LwXnJM/aagxNpzrdcKJejj5AEFWn1H6v+m68QFa5oSzD79u1cLObc5m93A v0HUA6PNZa/E4jSIYuNXrAgQJZs0oyMY3r9q1hnvDckIdEKVK4Q7OYNE+FDK67uP8rN9 E4oTpG1ZzgFROuLj2ITFFBCuDvbNxUVbhIHHkBsNn9ruWaqUDxFSp4jmNn8NkkgNWamg 5qjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l185si8715397pgd.570.2017.06.19.11.51.24; Mon, 19 Jun 2017 11:51:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752733AbdFSSuy (ORCPT + 25 others); Mon, 19 Jun 2017 14:50:54 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52681 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753985AbdFSSiu (ORCPT ); Mon, 19 Jun 2017 14:38:50 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIXg7S015042; Mon, 19 Jun 2017 20:33:42 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , "David S . Miller" , Willy Tarreau Subject: [PATCH 3.10 176/268] cpmac: remove hopeless #warning Date: Mon, 19 Jun 2017 20:31:15 +0200 Message-Id: <1497897167-14556-177-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit d43e6fb4ac4abfe4ef7c102833ed02330ad701e0 upstream. The #warning was present 10 years ago when the driver first got merged. As the platform is rather obsolete by now, it seems very unlikely that the warning will cause anyone to fix the code properly. kernelci.org reports the warning for every build in the meantime, so I think it's better to just turn it into a code comment to reduce noise. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau --- drivers/net/ethernet/ti/cpmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/drivers/net/ethernet/ti/cpmac.c b/drivers/net/ethernet/ti/cpmac.c index 6bcb2b8..922f7dd 100644 --- a/drivers/net/ethernet/ti/cpmac.c +++ b/drivers/net/ethernet/ti/cpmac.c @@ -1242,7 +1242,7 @@ int cpmac_init(void) goto fail_alloc; } -#warning FIXME: unhardcode gpio&reset bits + /* FIXME: unhardcode gpio&reset bits */ ar7_gpio_disable(26); ar7_gpio_disable(27); ar7_device_reset(AR7_RESET_BIT_CPMAC_LO); From patchwork Mon Jun 19 18:31:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105919 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1017029qgd; Mon, 19 Jun 2017 11:58:03 -0700 (PDT) X-Received: by 10.99.0.212 with SMTP id 203mr27221739pga.259.1497898683093; Mon, 19 Jun 2017 11:58:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497898683; cv=none; d=google.com; s=arc-20160816; b=w9ryF2lvnzoc7FnPXKB+uWAbPFKwCARnA/BK13+JUdoYyemFY4oIWjFrdie+iqv0gH 90yaqb1hBtCa+lnqXVS6u0bDVxQnwqzfLX/CcK7gMJIZkm/QQpNhQTNRN8s0Y8aE0Ejo OindhgYI0DF0WC/M7Ha3nn1WvaicjxDUgG8jh90WoWdi60256nPfdOmM8PDt2lOZEHyk VqaEej/JgYHa7SRHvsV4vTk6M9qZ1yPiRW1P/i8FX6KcgsOFu/uO4joC07EZdjrziXlJ aQ1GDIXZ9c5Wvy10WnpITrTBvBKvekUE5W1EnO6EzKuHNlM267yHP6IMtu11wGan5KUF P5sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=CxWdcURlnVhrgy69hdmJJdcIvFbQkblCkh+6nNAZLAQ=; b=T7U9sgqBl6oy+O4vLLFT2P1WaLzPoamXkRr7nANpPsuFB4GlqvVSBPIjOwuPO/mvsZ 5QiA4yiKazzN5vylzeO+vbZyjnoZ353SDmeabMro+wPTdnMa3D9kQS8J2nXqeRz0R0OT hBtp1ipr+bsk/eib1MTwgDfFyUf958LGimbnZdB0Bt5oOwgZXEJ6xH7BfhyIZvbKhJmv GZ70f5HUh5APERhYehUExNs42hxe9JOEfMdlxddZyi1X6ped3WXNeZ+3/iWTApEYbXRG DfmK0vZ61bO7XfQrWY7SWs8VHOXvjrtXkmDI0ToBXr9RXUb2aeASYZFdzK165vbHrgW8 ifmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l22si4672523pgo.408.2017.06.19.11.58.02; Mon, 19 Jun 2017 11:58:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753247AbdFSS5u (ORCPT + 25 others); Mon, 19 Jun 2017 14:57:50 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52591 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753830AbdFSSiA (ORCPT ); Mon, 19 Jun 2017 14:38:00 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIXm0j015078; Mon, 19 Jun 2017 20:33:48 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , "Rafael J . Wysocki" , Willy Tarreau Subject: [PATCH 3.10 212/268] ACPI / power: Avoid maybe-uninitialized warning Date: Mon, 19 Jun 2017 20:31:51 +0200 Message-Id: <1497897167-14556-213-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream. gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state() is enterered at least once, so it assumes that cur_state might not get initialized: drivers/acpi/power.c: In function 'acpi_power_get_inferred_state': drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized] This sets the variable to zero at the start of the loop, to ensure that there is well-defined behavior even for an empty list. This gets rid of the warning. The warning first showed up when the -Os flag got removed in a bug fix patch in linux-4.11-rc5. I would suggest merging this addon patch on top of that bug fix to avoid introducing a new warning in the stable kernels. Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing) Signed-off-by: Arnd Bergmann Signed-off-by: Rafael J. Wysocki Signed-off-by: Willy Tarreau --- drivers/acpi/power.c | 1 + 1 file changed, 1 insertion(+) -- 2.8.0.rc2.1.gbe9624a diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index 288bb27..9954200 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -211,6 +211,7 @@ static int acpi_power_get_list_state(struct list_head *list, int *state) return -EINVAL; /* The state of the list is 'on' IFF all resources are 'on'. */ + cur_state = 0; list_for_each_entry(entry, list, node) { struct acpi_power_resource *resource = entry->resource; acpi_handle handle = resource->device.handle; From patchwork Mon Jun 19 18:32:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105910 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1010900qgd; Mon, 19 Jun 2017 11:40:54 -0700 (PDT) X-Received: by 10.84.178.101 with SMTP id y92mr31165537plb.116.1497897654487; Mon, 19 Jun 2017 11:40:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497897654; cv=none; d=google.com; s=arc-20160816; b=gi3VKHOV5YRTAWIqbfIHPXMf0QB9lcgg2WxPybEK7/Zurhngrd2KMwp80ZAWTm+rrZ 4W8kHstTNqyVgiSn9/sdKJDL/S9wsbF+ETdANJ+ctvVWs8hiYkvfSiKxX+BL0vn6sfTo X63qa7sYi6tkAFppqPlCkYdqT0TMhcS/uGBQcN4h9c16QyPDdsVGsnqKFSNW4AxwHl2L XOZ+4xbk1LyLEVLW6diwb0xwaOYz3RcxF8w9/QCqmeSeGFP90SNrezLNfukFtAPhDDq4 j8Vx8Aj9M8yzOGprRu9J3RSr7HSDWLUikKCG9hWrE2608+H+Ymmb+rycxNjP72y4+3jM 11rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=lrvb8OCbTVi++XZWR5iWjGMG188oTXUrVACMZ2UxHJ4=; b=FGbI52EMwKmrN7VQ/VOWvAkM9wo2d+58kusn1y4Al88AHk3cNc70iQ4BVQk/vQenIc XO2PebOgPp5SSLw3+P/QeVCu3+7y0W68Ihb9zQZYbLyAQkrjeRbfGvsCngpQ8TaWfsW2 nq4X0SbibAIeJoGpd9deCq4XdjiYt9J8O0n/rPnkapqtt52KGA6DdmxEI5iO6iNTPRY3 NJ8WYXIm6uo1b8R8LzwIqiYhzC+FhNxg0IFsCUliCrpu3Tk10X07chUXv4kviKRhWi2u zwGohlxHT5gXobHX9Tac8f2gB51iJpQ61bMh/N7gTCW+jV7Z8EndAt/KmpJOD+j0276f E1xA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r85si8790477pgr.13.2017.06.19.11.40.54; Mon, 19 Jun 2017 11:40:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753742AbdFSSkv (ORCPT + 25 others); Mon, 19 Jun 2017 14:40:51 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52793 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753873AbdFSSkt (ORCPT ); Mon, 19 Jun 2017 14:40:49 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIY1E6015116; Mon, 19 Jun 2017 20:34:01 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , Willy Tarreau Subject: [PATCH 3.10 250/268] tty: nozomi: avoid a harmless gcc warning Date: Mon, 19 Jun 2017 20:32:29 +0200 Message-Id: <1497897167-14556-251-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit a4f642a8a3c2838ad09fe8313d45db46600e1478 upstream. The nozomi wireless data driver has its own helper function to transfer data from a FIFO, doing an extra byte swap on big-endian architectures, presumably to bring the data back into byte-serial order after readw() or readl() perform their implicit byteswap. This helper function is used in the receive_data() function to first read the length into a 32-bit variable, which causes a compile-time warning: drivers/tty/nozomi.c: In function 'receive_data': drivers/tty/nozomi.c:857:9: warning: 'size' may be used uninitialized in this function [-Wmaybe-uninitialized] The problem is that gcc is unsure whether the data was actually read or not. We know that it is at this point, so we can replace it with a single readl() to shut up that warning. I am leaving the byteswap in there, to preserve the existing behavior, even though this seems fishy: Reading the length of the data into a cpu-endian variable should normally not use a second byteswap on big-endian systems, unless the hardware is aware of the CPU endianess. There appears to be a lot more confusion about endianess in this driver, so it probably has not worked on big-endian systems in a long time, if ever, and I have no way to test it. It's well possible that this driver has not been used by anyone in a while, the last patch that looks like it was tested on the hardware is from 2008. Signed-off-by: Arnd Bergmann Signed-off-by: Willy Tarreau --- drivers/tty/nozomi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/drivers/tty/nozomi.c b/drivers/tty/nozomi.c index d6080c3..ce2e5d5 100644 --- a/drivers/tty/nozomi.c +++ b/drivers/tty/nozomi.c @@ -823,7 +823,7 @@ static int receive_data(enum port_type index, struct nozomi *dc) struct tty_struct *tty = tty_port_tty_get(&port->port); int i, ret; - read_mem32((u32 *) &size, addr, 4); + size = __le32_to_cpu(readl(addr)); /* DBG1( "%d bytes port: %d", size, index); */ if (tty && test_bit(TTY_THROTTLED, &tty->flags)) { From patchwork Mon Jun 19 18:32:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105911 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1011025qgd; Mon, 19 Jun 2017 11:41:16 -0700 (PDT) X-Received: by 10.101.70.129 with SMTP id h1mr27775081pgr.50.1497897675882; Mon, 19 Jun 2017 11:41:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497897675; cv=none; d=google.com; s=arc-20160816; b=KqkX0wK2cGjc6KxBkMy5chPrMXJMiTyZUTShRc3mSJuPzEkUcTYUOoSIIqZoWJuTct YA7qtnKiMoXgEWDa5LUOZhvliOEKCcSeiLIeMOUHUXwLWdISdhSkik4TgkiiVR0Th6Pn 7EegbDQwUjMKEi1/KXfiK50llO6/uw2p4cduDof8ZurxbpOS2PZ+Wi5tm/mCWbGFCRgN X4JQ9GSR/9eeEwM4bh32TU0fQBEm7Hvwml8k3ySxzBBj42ZVP485uO/yrymDmhX2E6fM dNz+/39guKx8YWOvvOq4qBbAuWV5WkhSDGaXpvffZttubNJ4E/9zQ0r1FUpcMSnQinSY i5pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=Dnl72v+b5xJnFakvu/V5CICTGSyX2edSrYJsXAMSYKw=; b=m7a7hMeKEvltLuqPr8KhPcbT+WuFFgOuV1/PHkrnYbaxIbVS5lSeXYVTW2iTEdLJGX L95Twe4CXGjyHNuMQpW0lKa/zLsPFPKPqpndnWpJDpi3bMydFO0MHzUSrS8SOEw4QVA/ AaBJ5OuiqgTfBslULY7+DmIBjwFc0T1dWJ0Rwda98fI8PGaXGIqI75e/e8K1SmUmngJK vw1ISO3X4v3L9U073rQP+BM+6mVq4Qlg/LBlWc4w+egJJziTV/MBjuBw6pPE/JZwranl e/fdr/18F5+2yrUqMWnUJwjAPi4EBfLVjpSUY4c8YCek17kaPEBql3ILTeL1u3IRoI8x Xqgg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n1si9396425pld.585.2017.06.19.11.41.15; Mon, 19 Jun 2017 11:41:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754484AbdFSSlM (ORCPT + 25 others); Mon, 19 Jun 2017 14:41:12 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52802 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754090AbdFSSlK (ORCPT ); Mon, 19 Jun 2017 14:41:10 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIY1GP015117; Mon, 19 Jun 2017 20:34:01 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , Kalle Valo , Willy Tarreau Subject: [PATCH 3.10 251/268] hostap: avoid uninitialized variable use in hfa384x_get_rid Date: Mon, 19 Jun 2017 20:32:30 +0200 Message-Id: <1497897167-14556-252-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit 48dc5fb3ba53b20418de8514700f63d88c5de3a3 upstream. The driver reads a value from hfa384x_from_bap(), which may fail, and then assigns the value to a local variable. gcc detects that in in the failure case, the 'rlen' variable now contains uninitialized data: In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0: drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid': drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized] if (le16_to_cpu(rec.len) == 0) { This restructures the function as suggested by Russell King, to make it more readable and get more reliable error handling, by handling each failure mode using a goto. Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Signed-off-by: Willy Tarreau --- drivers/net/wireless/hostap/hostap_hw.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/drivers/net/wireless/hostap/hostap_hw.c b/drivers/net/wireless/hostap/hostap_hw.c index 6307a4e..f863900 100644 --- a/drivers/net/wireless/hostap/hostap_hw.c +++ b/drivers/net/wireless/hostap/hostap_hw.c @@ -836,25 +836,30 @@ static int hfa384x_get_rid(struct net_device *dev, u16 rid, void *buf, int len, spin_lock_bh(&local->baplock); res = hfa384x_setup_bap(dev, BAP0, rid, 0); - if (!res) - res = hfa384x_from_bap(dev, BAP0, &rec, sizeof(rec)); + if (res) + goto unlock; + + res = hfa384x_from_bap(dev, BAP0, &rec, sizeof(rec)); + if (res) + goto unlock; if (le16_to_cpu(rec.len) == 0) { /* RID not available */ res = -ENODATA; + goto unlock; } rlen = (le16_to_cpu(rec.len) - 1) * 2; - if (!res && exact_len && rlen != len) { + if (exact_len && rlen != len) { printk(KERN_DEBUG "%s: hfa384x_get_rid - RID len mismatch: " "rid=0x%04x, len=%d (expected %d)\n", dev->name, rid, rlen, len); res = -ENODATA; } - if (!res) - res = hfa384x_from_bap(dev, BAP0, buf, len); + res = hfa384x_from_bap(dev, BAP0, buf, len); +unlock: spin_unlock_bh(&local->baplock); mutex_unlock(&local->rid_bap_mtx); From patchwork Mon Jun 19 18:32:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105920 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1018421qgd; Mon, 19 Jun 2017 12:01:14 -0700 (PDT) X-Received: by 10.84.175.3 with SMTP id s3mr30896425plb.105.1497898874282; Mon, 19 Jun 2017 12:01:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497898874; cv=none; d=google.com; s=arc-20160816; b=QLm96yU7z89DUba9ZnsUlw/Mm3dRId0qFezlqTS0jzUsORrAw89244nMw2JHEPrz/h nG42uLvTcm44XZoH2aBTH71v8xpDaPo5XGHFVWJ197OPXudKM/6ACRb/xixa5J46Xf06 Y3rjT1kabZixUyGJwj5rKZVOWv2oa/WZqyudNBXIdBSKeBQllDWCrEuwyesloDMWLIXK 6OFYD3TQJKCFnvCGng1SFkkf7nSBi+riWe3jk7uXQRVBB6IUMM3+RdU04zk527x3M/Vr JGS5GfRxzA2GyqAJtvKjlKOWJDMq3f3kG24ZKNETZDcl51/2C9Bam6mBLPHqKLUE11l8 mYbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=/SVrq8ITXShDDoSbJivFJA6i6XaXwhU/cRbrsPzZC0w=; b=CHOQPJP4iVPHROXiMDOGPTRGfVLXcMzNnD1tpEEnuzgJaE9VjV4LvAQU5G8gzhBkUJ W6Fxv0tYecLhqyX5Y4JCN12yKaQlb7klgLavv+vYlnvm/Z8g9o7vKcCBq5+UuHCHWNXg YeynQhzVOGXOrC/U/2xPOvehWKL04Up2LnSwUMBZppOSyaqavJ4AjUG2Gz+lJtKLYZ7Q 7MG04Og6a/D2DMeDcp1hooIPmQUD40UfVQ8faoER2B/C2iCN3sXcEzDymAAdclzBbAtD rKKmfZDSCvSOT4WmRlCliM4H0gTK2w1DhlMsAE+PeZrbXNmcF/4IAbBk3oYGXkeZ+HGl hNSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 7si8597708pfh.150.2017.06.19.12.01.14; Mon, 19 Jun 2017 12:01:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753057AbdFSTBC (ORCPT + 25 others); Mon, 19 Jun 2017 15:01:02 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52555 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753747AbdFSShp (ORCPT ); Mon, 19 Jun 2017 14:37:45 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIY1Er015118; Mon, 19 Jun 2017 20:34:01 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Arnd Bergmann , Bob Peterson , Willy Tarreau Subject: [PATCH 3.10 252/268] gfs2: avoid uninitialized variable warning Date: Mon, 19 Jun 2017 20:32:31 +0200 Message-Id: <1497897167-14556-253-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit 67893f12e5374bbcaaffbc6e570acbc2714ea884 upstream. We get a bogus warning about a potential uninitialized variable use in gfs2, because the compiler does not figure out that we never use the leaf number if get_leaf_nr() returns an error: fs/gfs2/dir.c: In function 'get_first_leaf': fs/gfs2/dir.c:802:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] fs/gfs2/dir.c: In function 'dir_split_leaf': fs/gfs2/dir.c:1021:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] Changing the 'if (!error)' to 'if (!IS_ERR_VALUE(error))' is sufficient to let gcc understand that this is exactly the same condition as in IS_ERR() so it can optimize the code path enough to understand it. Signed-off-by: Arnd Bergmann Signed-off-by: Bob Peterson Signed-off-by: Willy Tarreau --- fs/gfs2/dir.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c index b631c90..9aaa6db 100644 --- a/fs/gfs2/dir.c +++ b/fs/gfs2/dir.c @@ -763,7 +763,7 @@ static int get_first_leaf(struct gfs2_inode *dip, u32 index, int error; error = get_leaf_nr(dip, index, &leaf_no); - if (!error) + if (!IS_ERR_VALUE(error)) error = get_leaf(dip, leaf_no, bh_out); return error; @@ -974,7 +974,7 @@ static int dir_split_leaf(struct inode *inode, const struct qstr *name) index = name->hash >> (32 - dip->i_depth); error = get_leaf_nr(dip, index, &leaf_no); - if (error) + if (IS_ERR_VALUE(error)) return error; /* Get the old leaf block */ From patchwork Mon Jun 19 18:32:35 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 105922 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1030893qgd; Mon, 19 Jun 2017 12:32:35 -0700 (PDT) X-Received: by 10.101.83.197 with SMTP id z5mr18251277pgr.256.1497900754835; Mon, 19 Jun 2017 12:32:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497900754; cv=none; d=google.com; s=arc-20160816; b=IEMRcshZC7c4CwtXOkFUR1Y993cDfei0Cu+G92sQSLcAbe7ZBXOyQBrJ87Skub2Vua GlRrnacd6oC4P8++lqIdWF1ecoKNr75OuJ/RmORZxRxumqtlpwulQyzSfZDoILPCAoa4 ud7LQ0oguU7hmlUpe6myh1/2oaMUnbmai5b4qKNrMj+rP9JAFYUeSS/66EgBV4ul/TH0 pgtrR2DVm076HF3tTQAcZc+xGhcpisklaXZr12Tmo9LWKAeRNltR8hCibcMc1uN8QOV/ alyFbV2jnNH/UWB7NpruXdss4Lv63WsfREEtMUNhVn9UdTRtIuKFakDl8jmWLPuBuAjd xpOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=qnxAqwcEEW79+o92E1RIILmg6OgVwhVMhibRtyjhpuQ=; b=GDkHlydFS7BK5JeVAkJoY3PpImUs89lBIrSqKGo0THLpkkVXdDi4y7i6YW9yXlZDGU Ygorbk5Ik3UjPJECm9hqbsBglKXuz6OLVbVSL2mAGQg558GwQOj2atYsh5sT4cYC/qj3 8GUnHqcAnweY930UH0EAUbL++Na2AzXd8Fk9GNl0KwIFrSxTgy3f+Xc4TprZ96MImI+y 7fvaVQYIUW9YeB+71MwUTpJTKm0823Cl3WxHDAsHrg7DgFR7hmGdJHR5XEg+YJvcj0yj 2HF8icCu5mEynSu7Xby1zM8z9G9ESI3Xn7L1cI0knyS1iRS90mHwb9ugxE37Tv9RKyDR 3D+Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l91si9948707plb.581.2017.06.19.12.32.34; Mon, 19 Jun 2017 12:32:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752919AbdFSTcR (ORCPT + 25 others); Mon, 19 Jun 2017 15:32:17 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:51973 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752710AbdFSSey (ORCPT ); Mon, 19 Jun 2017 14:34:54 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5JIY2tJ015122; Mon, 19 Jun 2017 20:34:02 +0200 From: Willy Tarreau To: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux@roeck-us.net Cc: Corey Minyard , David Daney , linux-mips@linux-mips.org, Ralf Baechle , Julia Lawall , Jiri Slaby , Willy Tarreau Subject: [PATCH 3.10 256/268] MIPS: Fix crash registers on non-crashing CPUs Date: Mon, 19 Jun 2017 20:32:35 +0200 Message-Id: <1497897167-14556-257-git-send-email-w@1wt.eu> X-Mailer: git-send-email 2.8.0.rc2.1.gbe9624a In-Reply-To: <1497897167-14556-1-git-send-email-w@1wt.eu> References: <1497897167-14556-1-git-send-email-w@1wt.eu> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Corey Minyard commit c80e1b62ffca52e2d1d865ee58bc79c4c0c55005 upstream. As part of handling a crash on an SMP system, an IPI is send to all other CPUs to save their current registers and stop. It was using task_pt_regs(current) to get the registers, but that will only be accurate if the CPU was interrupted running in userland. Instead allow the architecture to pass in the registers (all pass NULL now, but allow for the future) and then use get_irq_regs() which should be accurate as we are in an interrupt. Fall back to task_pt_regs(current) if nothing else is available. Signed-off-by: Corey Minyard Cc: David Daney Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13050/ Signed-off-by: Ralf Baechle Cc: Julia Lawall Signed-off-by: Jiri Slaby Signed-off-by: Willy Tarreau --- arch/mips/kernel/crash.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) -- 2.8.0.rc2.1.gbe9624a diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c index 93aa302..c683129 100644 --- a/arch/mips/kernel/crash.c +++ b/arch/mips/kernel/crash.c @@ -15,12 +15,22 @@ static int crashing_cpu = -1; static cpumask_t cpus_in_crash = CPU_MASK_NONE; #ifdef CONFIG_SMP -static void crash_shutdown_secondary(void *ignore) +static void crash_shutdown_secondary(void *passed_regs) { - struct pt_regs *regs; + struct pt_regs *regs = passed_regs; int cpu = smp_processor_id(); - regs = task_pt_regs(current); + /* + * If we are passed registers, use those. Otherwise get the + * regs from the last interrupt, which should be correct, as + * we are in an interrupt. But if the regs are not there, + * pull them from the top of the stack. They are probably + * wrong, but we need something to keep from crashing again. + */ + if (!regs) + regs = get_irq_regs(); + if (!regs) + regs = task_pt_regs(current); if (!cpu_online(cpu)) return;