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 BFA1BC433EF for ; Thu, 17 Feb 2022 19:15:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3560D6B0081; Thu, 17 Feb 2022 14:15:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 337AF6B0093; Thu, 17 Feb 2022 14:15:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21D036B0095; Thu, 17 Feb 2022 14:15:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0184.hostedemail.com [216.40.44.184]) by kanga.kvack.org (Postfix) with ESMTP id 1363E6B0081 for ; Thu, 17 Feb 2022 14:15:25 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B7E2C181AC9CC for ; Thu, 17 Feb 2022 19:15:24 +0000 (UTC) X-FDA: 79153225368.20.FFB8A4B Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf25.hostedemail.com (Postfix) with ESMTP id 25CD8A0009 for ; Thu, 17 Feb 2022 19:15:23 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id hw13so9518438ejc.9 for ; Thu, 17 Feb 2022 11:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+RZ8CAgnGa1bk5gBxds4oezzFjZLQMV+wOvrmesI1Hw=; b=aC4vKGs+W+TwIvfSuol31sXb0DdwmBd+7ynpizLCKhXxCJFdEAZpxJvcWGa/FztIyE kaM//DxAJXCDh5aNx4GSOgCqArnp/pPXpeZOwL6NCOz09LePB9aHf9rLmhVNdEQhmOfG zcHXwBp2FYlRXI6tXnhZ/KCBgXws1BhNZED9tFrHvUNz3V476fnXQSLMeM+Shpqaev6m W07DvhrokY4sorGqrqwhi0S/cnzs7UTqO0cIGR6WWEAN8VmZadQ9VO/+zsTblOwHPeWg SsUN3Cw66rH7ga20AFYG5KTR6BdWsnByVkv9VANJJ9bhC1jZcqQ2NhN41BgDZLcdhMyk TY3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+RZ8CAgnGa1bk5gBxds4oezzFjZLQMV+wOvrmesI1Hw=; b=Rl2B+05nyl9rrUreAibp7r5EBjsJXNEH0OMiI+9aumtrWpc96lG2FqIpTKIqz5Bxn7 hyg+8cxBob5ZiQeH+4OieR4WIyJ5IckrNI4tF4Oyh7PX6nQH4dmCcHNyiRhmPKMD1cM7 qNyEI2DztjGwHBttnE7LIPiaY8g/cw9gx9c/+nlNyCMqs8XfKN0S+9cqcb4Im43nt5dw xDoDpbxPa/vIAseZVtFfSWlUItekZETQCtbTUelfkTGb09gqJn4eLpUV3Pz19Xb13SJh XPuUTdt9ylkxTNkaDE7a0SUcrtRYAMORh7N7mFMrvn4wV3CY9V+2iCohjbY053xYIEVU u3Ig== X-Gm-Message-State: AOAM530KjJCscDJAUS155QlAZQ4SYX1qPxq3tAb7y7QmoO43JZ1advtC B0vN60JOkq20KVikW8ztGB6eGumdGlQ5fWVRiylvBw== X-Google-Smtp-Source: ABdhPJw48Oadf8QR2zY/o5TdRU0UiMjXS1n08+Rvo/jef0cepMooOXBMnDr3m4SH0a9wsDyMLo89s3cuvktj12QRONA= X-Received: by 2002:a17:906:4b52:b0:6cd:3863:b35e with SMTP id j18-20020a1709064b5200b006cd3863b35emr3488094ejv.415.1645125322737; Thu, 17 Feb 2022 11:15:22 -0800 (PST) MIME-Version: 1.0 References: <20220216131332.1489939-1-arnd@kernel.org> <20220216131332.1489939-14-arnd@kernel.org> In-Reply-To: <20220216131332.1489939-14-arnd@kernel.org> From: Andy Lutomirski Date: Thu, 17 Feb 2022 11:15:11 -0800 Message-ID: Subject: Re: [PATCH v2 13/18] uaccess: generalize access_ok() To: 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 25CD8A0009 X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=amacapital-net.20210112.gappssmtp.com header.s=20210112 header.b=aC4vKGs+; spf=pass (imf25.hostedemail.com: domain of luto@amacapital.net designates 209.85.218.53 as permitted sender) smtp.mailfrom=luto@amacapital.net; dmarc=none X-Stat-Signature: soxmkmj13nisx8t6wxjahqn1t9k851ar X-HE-Tag: 1645125323-740422 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 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.)