From patchwork Mon Feb 14 16:34:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 1592703 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=d1GDmxBk; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=JVfOMM7v; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:e::133; helo=bombadil.infradead.org; envelope-from=linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Jy91R1TlMz9ryY for ; Tue, 15 Feb 2022 03:39:52 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3U6W2SnTqDdBsCjryJuKsQVs6qGgZ8xUW3cKgnOmPng=; b=d1GDmxBkeINi6B m2zFc8LqabKkxtflnaJWUsGuJS2HRE+cfMLXodNnS7C2rmkWkP8i/8132ms/01zRBu7OO8wrW9jrI PhnjPuNWGLmZtUGPqIzaZOvTVydqeJItneOfkPy2rtLyaP0IaU1z7oPFNeXTdu7rcR5kuh4A45UuV oulavO2VnEGtoZFlz+B3EQF0RLMnXaZhHzoUp92BmqUKKHp3dHSpAtx59kvKU49e6vNx1dxxtMDjf GROuQt/M9Tpyiqmv8NeZ7ENea+FeNm0IA2x0sBK36LK2FgCgFJKvTKW5txfH/oejP2gr3U7JphY5B BLKFYA7d6m5+RYGH1hwA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJeOC-00G4mn-1S; Mon, 14 Feb 2022 16:39:48 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJeLN-00G327-KB; Mon, 14 Feb 2022 16:37:00 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1365761500; Mon, 14 Feb 2022 16:36:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A67DEC340F1; Mon, 14 Feb 2022 16:36:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644856612; bh=XYviTV8III28kBrCQmsfuK51xOc09ZOif7iEHrUTuIg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JVfOMM7vTqw4XdpMNlrmm2jS83mfS0hYdjkQzrKj6vrH9+Dvn0L42AdShO8RRf9Zt dCgJRVDvimHn/Uhy8K6/LoOqKmFRoenKTwmfXsum/yC+2647Q4iFanRlWF3K/xS92S gCEmlRiZlTgkTyjEKX3J6/tBJHCW3fBRdNZcGJninmBDlMLvinDaCzw9S7lbmfV8Yj asCqU2GVX1KEmy6ol6Y4c8F7ub3PAxvrL7Bv3Yonu/G0OWA7/HKZkm9UtkPubPBkfM dXhuOWxE8SbyX8yNCneVJdVo8zXW4C1x2+08uIEcESmpPYEb+YIs98IFRoa3DME4D0 G0ya2TSp8tVbQ== From: Arnd Bergmann To: Linus Torvalds , Christoph Hellwig , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, arnd@arndb.de, linux-kernel@vger.kernel.org Cc: linux@armlinux.org.uk, will@kernel.org, guoren@kernel.org, bcain@codeaurora.org, geert@linux-m68k.org, monstr@monstr.eu, tsbogend@alpha.franken.de, nickhu@andestech.com, green.hu@gmail.com, dinguyen@kernel.org, shorne@gmail.com, deller@gmx.de, mpe@ellerman.id.au, peterz@infradead.org, mingo@redhat.com, mark.rutland@arm.com, hca@linux.ibm.com, dalias@libc.org, davem@davemloft.net, richard@nod.at, x86@kernel.org, jcmvbkbc@gmail.com, ebiederm@xmission.com, akpm@linux-foundation.org, ardb@kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, linux-xtensa@linux-xtensa.org Subject: [PATCH 06/14] mips: use simpler access_ok() Date: Mon, 14 Feb 2022 17:34:44 +0100 Message-Id: <20220214163452.1568807-7-arnd@kernel.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20220214163452.1568807-1-arnd@kernel.org> References: <20220214163452.1568807-1-arnd@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220214_083653_775537_68853C4E X-CRM114-Status: GOOD ( 19.05 ) X-Spam-Score: -5.4 (-----) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: From: Arnd Bergmann Before unifying the mips version of __access_ok() with the generic code, this converts it to the same algorithm. This is a change in behavior on mips64, as now address in the user segment, the lower 2 [...] Content analysis details: (-5.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/, high trust [2604:1380:4641:c500:0:0:0:1 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.2 DKIMWL_WL_HIGH DKIMwl.org - High trust sender X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Arnd Bergmann Before unifying the mips version of __access_ok() with the generic code, this converts it to the same algorithm. This is a change in behavior on mips64, as now address in the user segment, the lower 2^62 bytes, is taken to be valid, relying on a page fault for addresses that are within that segment but not valid on that CPU. The new version should be the most effecient way to do this, but it gets rid of the special handling for size=0 that most other architectures ignore as well. Signed-off-by: Arnd Bergmann --- arch/mips/include/asm/uaccess.h | 22 ++++------------------ 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h index db9a8e002b62..d7c89dc3426c 100644 --- a/arch/mips/include/asm/uaccess.h +++ b/arch/mips/include/asm/uaccess.h @@ -19,6 +19,7 @@ #ifdef CONFIG_32BIT #define __UA_LIMIT 0x80000000UL +#define TASK_SIZE_MAX __UA_LIMIT #define __UA_ADDR ".word" #define __UA_LA "la" @@ -33,6 +34,7 @@ extern u64 __ua_limit; #define __UA_LIMIT __ua_limit +#define TASK_SIZE_MAX XKSSEG #define __UA_ADDR ".dword" #define __UA_LA "dla" @@ -42,22 +44,6 @@ extern u64 __ua_limit; #endif /* CONFIG_64BIT */ -/* - * Is a address valid? This does a straightforward calculation rather - * than tests. - * - * Address valid if: - * - "addr" doesn't have any high-bits set - * - AND "size" doesn't have any high-bits set - * - AND "addr+size" doesn't have any high-bits set - * - OR we are in kernel mode. - * - * __ua_size() is a trick to avoid runtime checking of positive constant - * sizes; for those we already know at compile time that the size is ok. - */ -#define __ua_size(size) \ - ((__builtin_constant_p(size) && (signed long) (size) > 0) ? 0 : (size)) - /* * access_ok: - Checks if a user space pointer is valid * @addr: User space pointer to start of block to check @@ -79,9 +65,9 @@ extern u64 __ua_limit; static inline int __access_ok(const void __user *p, unsigned long size) { unsigned long addr = (unsigned long)p; - unsigned long end = addr + size - !!size; + unsigned long limit = TASK_SIZE_MAX; - return (__UA_LIMIT & (addr | end | __ua_size(size))) == 0; + return (size <= limit) && (addr <= (limit - size)); } #define access_ok(addr, size) \