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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DF53C433EF for ; Fri, 18 Feb 2022 07:16:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 200C56B0074; Fri, 18 Feb 2022 02:16:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18A886B0078; Fri, 18 Feb 2022 02:16:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02A6F6B007B; Fri, 18 Feb 2022 02:16:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id E9B916B0074 for ; Fri, 18 Feb 2022 02:16:35 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AB25F60CAD for ; Fri, 18 Feb 2022 07:16:35 +0000 (UTC) X-FDA: 79155042750.05.8BCA64B Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf23.hostedemail.com (Postfix) with ESMTP id D4AF9140003 for ; Fri, 18 Feb 2022 07:16:34 +0000 (UTC) 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 sin.source.kernel.org (Postfix) with ESMTPS id D9ACECE3152 for ; Fri, 18 Feb 2022 07:16:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF533C36AE9 for ; Fri, 18 Feb 2022 07:16:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645168588; bh=q+jKWrJ4jJZ2v7I08P11+5fwNrVng4vZR8KgCaGgNp8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=E7Qj225LkHl4vakpp/86Clw8A8aYCNcpfLrBP+VCQdOQM5BITuaFC8aajiIPA17sq QsQL+tpQFefxmctximGZjJghHIgDs0+5uBmhr8xxAaHPynJ3FAz/VvdJ7A4yiUcYzD cvOPc8xsA1RVRdeBpZvu7iuJPB2dq0pqYhhG0eac2ra/YlTXeM+fTnsQjW5NHDOU4h cinPsKBHoi0lD++02CV6Px7pd6xZwvcPqjj04/ifU1PciDsuXI0NkC0Bbm1nyirKYP OBBXTMFOAcsBgbQTb4NkJ7ZQ5y+D67DT81A8imqE8C6wMfM2VmNDYRx0F0jR7hwP1U QI8LFbE7ThFyQ== Received: by mail-wr1-f41.google.com with SMTP id v12so12982658wrv.2 for ; Thu, 17 Feb 2022 23:16:28 -0800 (PST) X-Gm-Message-State: AOAM532tZv0xD7N4Vr7v744IhwIcbrjJOUiQjtJbh10eftJf0QUYyIjj xKK7CwvmWM/2WEfhhvV5TIhkXCCoeDXIlXu2jjc= X-Google-Smtp-Source: ABdhPJzrsD9ZegAYWxopB2Dqyhs5CbptDH37N4ZCxM0ghQnmxjYRVare/kFAwMrZOPIITOhmBYHifd3MXTFISbjy0gQ= X-Received: by 2002:adf:c406:0:b0:1e4:a5ae:34a3 with SMTP id v6-20020adfc406000000b001e4a5ae34a3mr5120080wrf.407.1645168587142; Thu, 17 Feb 2022 23:16:27 -0800 (PST) MIME-Version: 1.0 References: <20220216131332.1489939-1-arnd@kernel.org> <20220216131332.1489939-14-arnd@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Fri, 18 Feb 2022 08:16:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 13/18] uaccess: generalize access_ok() To: Andy Lutomirski Cc: Linus Torvalds , Christoph Hellwig , linux-arch , Linux-MM , Linux API , Arnd Bergmann , Linux Kernel Mailing List , Al Viro , Russell King - ARM Linux , Will Deacon , Guo Ren , Brian Cain , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , Nick Hu , Greentime Hu , Dinh Nguyen , Stafford Horne , Helge Deller , Michael Ellerman , Peter Zijlstra , Ingo Molnar , Mark Rutland , Heiko Carstens , Rich Felker , David Miller , Richard Weinberger , "the arch/x86 maintainers" , Max Filippov , "Eric W . Biederman" , Andrew Morton , Ard Biesheuvel , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , linux-csky@vger.kernel.org, "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , "open list:BROADCOM NVRAM DRIVER" , Openrisc , Parisc List , linuxppc-dev , linux-riscv , linux-s390 , Linux-sh list , sparclinux , linux-um , "open list:TENSILICA XTENSA PORT (xtensa)" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: D4AF9140003 X-Stat-Signature: 78fe7whh9qu8my8d9ipsmkkybyniibu9 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E7Qj225L; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of arnd@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=arnd@kernel.org X-Rspamd-Server: rspam03 X-HE-Tag: 1645168594-447948 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 17, 2022 at 8:15 PM Andy Lutomirski wrote: > > On Wed, Feb 16, 2022 at 5:19 AM Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > There are many different ways that access_ok() is defined across > > architectures, but in the end, they all just compare against the > > user_addr_max() value or they accept anything. > > > > Provide one definition that works for most architectures, checking > > against TASK_SIZE_MAX for user processes or skipping the check inside > > of uaccess_kernel() sections. > > > > For architectures without CONFIG_SET_FS(), this should be the fastest > > check, as it comes down to a single comparison of a pointer against a > > compile-time constant, while the architecture specific versions tend to > > do something more complex for historic reasons or get something wrong. > > 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.) Thank you for taking a look! As you can see in the patch that changes the algorithm on x86 [1], it was already using TASK_SIZE_MAX as the limit, only the order in which the comparison is done, hopefully leading to better code already. I have looked at trivial examples on x86 that showed an improvement for constant sizes, but only looked at arm64 in detail for the overall result. It may be worth checking if using LONG_MAX as the limit produces better code, but it's probably best to do the optimization in the common code in a portable way to keep it from diverging again. Arnd [1] https://lore.kernel.org/lkml/20220216131332.1489939-7-arnd@kernel.org/