From patchwork Mon Apr 15 19:00:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 162253 Delivered-To: patch@linaro.org Received: by 2002:a02:c6d8:0:0:0:0:0 with SMTP id r24csp3300698jan; Mon, 15 Apr 2019 12:12:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqxRuNnfR2pV9iGpyeB7KIFrAsB6MUASlWF57/yXHgfdMAIBZoXctA3msrme2hDVNQHzSeT7 X-Received: by 2002:a17:902:ab87:: with SMTP id f7mr76919592plr.85.1555355535124; Mon, 15 Apr 2019 12:12:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555355535; cv=none; d=google.com; s=arc-20160816; b=eyBYsXUA5TTyAAGB1u2OHqNXNKOY6/C/ZXTHmuk6MnUyXYAXyjzI5IYqaupa+6y7Jy 4PRhm8xJs1MPQivM7o24XN9hQrZzmSOLo7J9tmRztnVAuLhQ7Q40tivjqZ0bYLL1sH3+ iExqQZaaU/tbZxAGIjSZ2yawzH2MRQHFF+dOCHAlnOETP0pmh01YLBqNDm9iCk8v7h6a TOxuVlLVXEvA/SSyHsMRuMP5F3G6cvmGjh3lUEuo2FaftfC8qfLx9YqtCcN3V51yhLq+ 94suCRX/0HRwg4sNQjvEA8EMVyR2pakIXSoyQrsNj8ZkYQO391UXlS9DhyFpno5jtJin t07w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=nbad2nwe9PZMRwciM/HEv/a228W0p6So1yZBRbh04Jg=; b=qtG/lq5oGCrNlnv+2/aHtFSoWcZ3Aft0kNoIQJ+nrdJe/lXz95tU6J4eLxl1AIfGvI EImFseUSf+4ICZ4SW9z0DLQE1c89Q1KRN0PHME1pHqoDbM1vys+glN6SU1TA5vGrSQ4n kA5j3E6totNExetA2/q44yVqWUpPlXBnJ5o2CMDwSmj+KgDwtLpkX8z6QETixcacEq7z k+ggYHnLHRc+NXNUWnw8H19sIKbu/F1CtD/9FI7oXDlT6Czn7beBLxiSpnCtRaxrPsCS KQuhJ9Y55W553r3zoO/JwuTMCj2fsbGnqCN6+rpEYkirQ7pi64KhplZ7OFPUiVCMTYgA q46g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="eJ/zWOFO"; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 72si12399373plb.165.2019.04.15.12.12.14; Mon, 15 Apr 2019 12:12:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="eJ/zWOFO"; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731356AbfDOTMN (ORCPT + 14 others); Mon, 15 Apr 2019 15:12:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:49428 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731350AbfDOTMM (ORCPT ); Mon, 15 Apr 2019 15:12:12 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6DF30218A1; Mon, 15 Apr 2019 19:12:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555355530; bh=kCpm+MyXmaaPxl+WAR7wPjIj+5TZtAOJr4Lre1+Vvms=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eJ/zWOFOmRVwV/rvCbmNpHvCKO5Z09WLJwuPMJvqLVxq8DKTOMBaXprI/yip/iXiT 43IVl1CaMuuXtt07bzbQ4QA+PPv2YbJs+KuL1bm0N2m6I/3Dz+Z1f1Kk2CFIks1Vfn pzRHfZzRTiInGF3L9YAjV2B0DEW1PK1PzUxwUAE4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Nick Desaulniers , Zhao Qiang , Yalin Wang , Andrew Morton , Linus Torvalds Subject: [PATCH 5.0 070/117] include/linux/bitrev.h: fix constant bitrev Date: Mon, 15 Apr 2019 21:00:40 +0200 Message-Id: <20190415183748.523340749@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190415183744.887851196@linuxfoundation.org> References: <20190415183744.887851196@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Arnd Bergmann commit 6147e136ff5071609b54f18982dea87706288e21 upstream. clang points out with hundreds of warnings that the bitrev macros have a problem with constant input: drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] u8 crc = bitrev8(data->val_status & 0x0F); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8' __constant_bitrev8(__x) : \ ~~~~~~~~~~~~~~~~~~~^~~~ include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8' u8 __x = x; \ ~~~ ^ Both the bitrev and the __constant_bitrev macros use an internal variable named __x, which goes horribly wrong when passing one to the other. The obvious fix is to rename one of the variables, so this adds an extra '_'. It seems we got away with this because - there are only a few drivers using bitrev macros - usually there are no constant arguments to those - when they are constant, they tend to be either 0 or (unsigned)-1 (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and give the correct result by pure chance. In fact, the only driver that I could find that gets different results with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver for fairly rare hardware (adding the maintainer to Cc for testing). Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction") Signed-off-by: Arnd Bergmann Reviewed-by: Nick Desaulniers Cc: Zhao Qiang Cc: Yalin Wang Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- include/linux/bitrev.h | 46 +++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) --- a/include/linux/bitrev.h +++ b/include/linux/bitrev.h @@ -34,41 +34,41 @@ static inline u32 __bitrev32(u32 x) #define __constant_bitrev32(x) \ ({ \ - u32 __x = x; \ - __x = (__x >> 16) | (__x << 16); \ - __x = ((__x & (u32)0xFF00FF00UL) >> 8) | ((__x & (u32)0x00FF00FFUL) << 8); \ - __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \ - __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \ - __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \ - __x; \ + u32 ___x = x; \ + ___x = (___x >> 16) | (___x << 16); \ + ___x = ((___x & (u32)0xFF00FF00UL) >> 8) | ((___x & (u32)0x00FF00FFUL) << 8); \ + ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \ + ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \ + ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \ + ___x; \ }) #define __constant_bitrev16(x) \ ({ \ - u16 __x = x; \ - __x = (__x >> 8) | (__x << 8); \ - __x = ((__x & (u16)0xF0F0U) >> 4) | ((__x & (u16)0x0F0FU) << 4); \ - __x = ((__x & (u16)0xCCCCU) >> 2) | ((__x & (u16)0x3333U) << 2); \ - __x = ((__x & (u16)0xAAAAU) >> 1) | ((__x & (u16)0x5555U) << 1); \ - __x; \ + u16 ___x = x; \ + ___x = (___x >> 8) | (___x << 8); \ + ___x = ((___x & (u16)0xF0F0U) >> 4) | ((___x & (u16)0x0F0FU) << 4); \ + ___x = ((___x & (u16)0xCCCCU) >> 2) | ((___x & (u16)0x3333U) << 2); \ + ___x = ((___x & (u16)0xAAAAU) >> 1) | ((___x & (u16)0x5555U) << 1); \ + ___x; \ }) #define __constant_bitrev8x4(x) \ ({ \ - u32 __x = x; \ - __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \ - __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \ - __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \ - __x; \ + u32 ___x = x; \ + ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \ + ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \ + ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \ + ___x; \ }) #define __constant_bitrev8(x) \ ({ \ - u8 __x = x; \ - __x = (__x >> 4) | (__x << 4); \ - __x = ((__x & (u8)0xCCU) >> 2) | ((__x & (u8)0x33U) << 2); \ - __x = ((__x & (u8)0xAAU) >> 1) | ((__x & (u8)0x55U) << 1); \ - __x; \ + u8 ___x = x; \ + ___x = (___x >> 4) | (___x << 4); \ + ___x = ((___x & (u8)0xCCU) >> 2) | ((___x & (u8)0x33U) << 2); \ + ___x = ((___x & (u8)0xAAU) >> 1) | ((___x & (u8)0x55U) << 1); \ + ___x; \ }) #define bitrev32(x) \ From patchwork Mon Apr 15 19:01:01 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 162254 Delivered-To: patch@linaro.org Received: by 2002:a02:c6d8:0:0:0:0:0 with SMTP id r24csp3301606jan; Mon, 15 Apr 2019 12:13:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxy/hYTvFNTHHtVMXL6XRP0MbCA6o35QZ5IlwLtVIQffG4AM9RO9R/w36b09pKuyQnfLwim X-Received: by 2002:a17:902:364:: with SMTP id 91mr64765493pld.72.1555355589221; Mon, 15 Apr 2019 12:13:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555355589; cv=none; d=google.com; s=arc-20160816; b=sFerZW/DHB3Do7Qvm7k1mblWn1k6EZU3XcbP0I3LvOQ2igtSD71c09iCNr2OPm9gzs uCohbyx9uJFyQ/Wo6oK8q8+3B6sSOWYbLv7c1mCPJq8D1iz9za5QlXrqWJOqsE7DIK2S CPB6B31EnGORySzv/IZcMAccj+S0FiyDRo22Z4598ncXzJ30V9rJ97xTODZkOnYO4HHC nH8AB5p6BNOffJdrmQe6pfBdvemvjkJS17YejPvn2g4QTVqnHdI3r936apHxU8lZ+6wn gMm3Nm90GXXuiUmKi5lc2PRG1SnE4KwVzsIDdGkzC1Cz9IDP4fGKTzZNy5Wi2oabpPi2 l8Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=rlRsJJi7P3ntkMcQCUea3lyipPhHID8kdCGeGyjLvzc=; b=YUOAcbxARDg3OB/O6ajDaPUHWhzT17l5P2cegrdi1dA33QoyC28VtwtQ1H2SZUnAa8 fuXSU/ZkTYZucfN5u4A/ZWTS+COlRk9lBsgh7yT2i/wOgGVhcCMjaIE4iwWwyklOiotf fYOEuXtIiFkfNtIEtO0ZnEBhtBXOfU7KAh0ZXdsLCKqbrg7ED6kCANJRol9/y9fCuCvF LwvGuSiDbYIUaldgcVgGgedD5Rl3z+MMHazrP+UFL4NcWN9/gRw7h6BQGie+nlCh9px6 yJRdbrHWS34qRfD5ercTVKwOfPkfFtkf5d1ftWvFP8P/hGal681VcUAJUnVQZjlkjUoX K+lQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Eg1QbtwO; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 t4si40745591pgu.544.2019.04.15.12.13.08; Mon, 15 Apr 2019 12:13:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Eg1QbtwO; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731495AbfDOTNI (ORCPT + 14 others); Mon, 15 Apr 2019 15:13:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:50718 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731141AbfDOTNI (ORCPT ); Mon, 15 Apr 2019 15:13:08 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 10AE320880; Mon, 15 Apr 2019 19:13:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555355586; bh=2d021XjXqrApmCc0tAWeYZHebctEUMdgkcjJfV2+07I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Eg1QbtwOL8Kzk0mvEx63q6Sp9K8nxJ1bZwTX8zJmKikh7jTYDXmqQurJLzaxdpgj/ VlV8+5y5ZA29x2QokOjsbVno81fiL6j+iw4/4Y4687Cx3koYW9iZSuseXAsivBdSK5 DFQjOrHsezLKxmfJJYMxxYSrc5IE6bn5riegsn0g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Will Deacon Subject: [PATCH 5.0 091/117] arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value Date: Mon, 15 Apr 2019 21:01:01 +0200 Message-Id: <20190415183749.494366460@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190415183744.887851196@linuxfoundation.org> References: <20190415183744.887851196@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Will Deacon commit 045afc24124d80c6998d9c770844c67912083506 upstream. Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't explicitly set the return value on the non-faulting path and instead leaves it holding the result of the underlying atomic operation. This means that any FUTEX_WAKE_OP atomic operation which computes a non-zero value will be reported as having failed. Regrettably, I wrote the buggy code back in 2011 and it was upstreamed as part of the initial arm64 support in 2012. The reasons we appear to get away with this are: 1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get exercised by futex() test applications 2. If the result of the atomic operation is zero, the system call behaves correctly 3. Prior to version 2.25, the only operation used by GLIBC set the futex to zero, and therefore worked as expected. From 2.25 onwards, FUTEX_WAKE_OP is not used by GLIBC at all. Fix the implementation by ensuring that the return value is either 0 to indicate that the atomic operation completed successfully, or -EFAULT if we encountered a fault when accessing the user mapping. Cc: Fixes: 6170a97460db ("arm64: Atomic operations") Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman --- arch/arm64/include/asm/futex.h | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/arch/arm64/include/asm/futex.h +++ b/arch/arm64/include/asm/futex.h @@ -30,8 +30,8 @@ do { \ " prfm pstl1strm, %2\n" \ "1: ldxr %w1, %2\n" \ insn "\n" \ -"2: stlxr %w3, %w0, %2\n" \ -" cbnz %w3, 1b\n" \ +"2: stlxr %w0, %w3, %2\n" \ +" cbnz %w0, 1b\n" \ " dmb ish\n" \ "3:\n" \ " .pushsection .fixup,\"ax\"\n" \ @@ -50,30 +50,30 @@ do { \ static inline int arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *_uaddr) { - int oldval = 0, ret, tmp; + int oldval, ret, tmp; u32 __user *uaddr = __uaccess_mask_ptr(_uaddr); pagefault_disable(); switch (op) { case FUTEX_OP_SET: - __futex_atomic_op("mov %w0, %w4", + __futex_atomic_op("mov %w3, %w4", ret, oldval, uaddr, tmp, oparg); break; case FUTEX_OP_ADD: - __futex_atomic_op("add %w0, %w1, %w4", + __futex_atomic_op("add %w3, %w1, %w4", ret, oldval, uaddr, tmp, oparg); break; case FUTEX_OP_OR: - __futex_atomic_op("orr %w0, %w1, %w4", + __futex_atomic_op("orr %w3, %w1, %w4", ret, oldval, uaddr, tmp, oparg); break; case FUTEX_OP_ANDN: - __futex_atomic_op("and %w0, %w1, %w4", + __futex_atomic_op("and %w3, %w1, %w4", ret, oldval, uaddr, tmp, ~oparg); break; case FUTEX_OP_XOR: - __futex_atomic_op("eor %w0, %w1, %w4", + __futex_atomic_op("eor %w3, %w1, %w4", ret, oldval, uaddr, tmp, oparg); break; default: