From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D4435C433F5 for ; Fri, 18 Feb 2022 09:36:58 +0000 (UTC) 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:In-Reply-To:References: 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=RKhP7D9UwZsU4mRAUYUKfmq5h742JZCvh5fab6unvto=; b=cAbw902l7lzc7a YMLlNMzSs4QybJqHibhqGJ7LWrHTm8zlmeJ/DpP3wzIyz4FHNFL0Q/1lROXSJ9lRe2BukS71aNPZV vr7CDIwEQW7FX8iKWpXMMSl/EyVZYC9KqPULvFehzb8IKhCumIv2cJIPxww0/enkK86Mzr8mu/bQP YLD1591tr5oJFYlS+RiQKQ8YHSPfIhN1anSRZWdpRatjA9rvh3VEC7QXhQF+ZIUWsGg5UJP9n9lZB wydwc8UT+71z+fD6+Zf+VV0Nbn5iz94fKSzgt3iRfTrjt5t57G13ZHhz4CCLtWb/UR1FZkMSodfVf kGkXXK3t16A9EHifLlJg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKzh2-00DbRS-TC; Fri, 18 Feb 2022 09:36:48 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKzb4-00DYNS-2j for linux-riscv@lists.infradead.org; Fri, 18 Feb 2022 09:30:40 +0000 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-129-Mn8CKvyFPNSuM9Bkc4i3uw-1; Fri, 18 Feb 2022 09:30:35 +0000 X-MC-Unique: Mn8CKvyFPNSuM9Bkc4i3uw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Fri, 18 Feb 2022 09:30:32 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.028; Fri, 18 Feb 2022 09:30:32 +0000 From: David Laight To: 'Andy Lutomirski' , Arnd Bergmann CC: 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" , "viro@zeniv.linux.org.uk" , "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-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: RE: [PATCH v2 13/18] uaccess: generalize access_ok() Thread-Topic: [PATCH v2 13/18] uaccess: generalize access_ok() Thread-Index: AQHYJDLDvIZKe0fPGEirizFtCzB+zayZCg2g Date: Fri, 18 Feb 2022 09:30:32 +0000 Message-ID: <93a1ee797e9d4f789dff85a3c0f0c232@AcuMS.aculab.com> References: <20220216131332.1489939-1-arnd@kernel.org> <20220216131332.1489939-14-arnd@kernel.org> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220218_013038_465338_AB16139C X-CRM114-Status: GOOD ( 15.53 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org From: Andy Lutomirski > Sent: 17 February 2022 19:15 ... > This isn't actually optimal. On x86, TASK_SIZE_MAX is a bizarre > constant that has a very specific value to work around a bug^Wdesign > error^Wfeature of Intel CPUs. TASK_SIZE_MAX is the maximum address at > which userspace is permitted to allocate memory, but there is a huge > gap between user and kernel addresses, and any value in the gap would > be adequate for the comparison. If we wanted to optimize this, simply > checking the high bit (which x86 can do without any immediate > constants at all) would be sufficient and, for an access known to fit > in 32 bits, one could get even fancier and completely ignore the size > of the access. (For accesses not known to fit in 32 bits, I suspect > some creativity could still come up with a construction that's > substantially faster than the one in your patch.) > > So there's plenty of room for optimization here. > > (This is not in any respect a NAK -- it's just an observation that > this could be even better.) For 64bit arch that use the top bit to separate user/kernel you can test '(addr | size) >> 62)'. The compiler optimises out constant sizes. This has all been mentioned a lot of times. You do get different fault types. OTOH an explicit check for constant size (less than something big) can use the cheaper test of the sign bit. Big constant sizes could be compile time errors. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv