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 F4226C27C79 for ; Thu, 20 Jun 2024 07:54:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:Subject:Cc:To: From:Date:References:In-Reply-To:Message-Id:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JHeenBGKjo00Vy0Wx71C86ZiG2/JTmE9tVuHD5MJIGk=; b=oJYYecJUshz31+WpVXCagQId2h SI0lPUPtt4ADhEgydIqjTDbE0aBk9/JIkKwNeL1uA3TFEPBbex8qPs406aZEBNfUTJ2cBavapnyw5 RX0z7+eYoDyszb+bhVPOefAB0pQLbM9O0hj8SlEdo1ZFK7zlRwn/xA2J4OBwXkDmEoSnVOs31/ugh jCoCQtMZtImZSux+GNrTzIdUf3WjdN0uSrgYIcwtqQ0VRVXJhBamIz/OjiHVnS5NVwaaHaZJEHWiX halNQ3WPU9Pd9AcJB/5zfbXXxQebD3yUbPkjrmQjlj6/gGN+OTKnjFnbK4xpHYwNDAeq4Md4WkVsN B+uRnNhA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sKCcA-000000042hG-40af; Thu, 20 Jun 2024 07:53:51 +0000 Received: from wfout1-smtp.messagingengine.com ([64.147.123.144]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sKCc7-000000042g4-13AC for linux-arm-kernel@lists.infradead.org; Thu, 20 Jun 2024 07:53:48 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.west.internal (Postfix) with ESMTP id 0D2951C000CC; Thu, 20 Jun 2024 03:53:41 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Thu, 20 Jun 2024 03:53:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1718870021; x=1718956421; bh=JHeenBGKjo 00Vy0Wx71C86ZiG2/JTmE9tVuHD5MJIGk=; b=VSD7g5YbPKYvbulY+H627IMewJ S+zKo7lxSktkGbThFsKKNVcWFKUtZd/foreDwev/pCcboYVqMzg5kC2Iw/p5X/ka hSxV3fiKFDFW6mHgzsKC9DnknS5dsJ1nWodOHvD0YbsE6hnUfECajYGB7MSQ6yOx 1GS5J6qhRAbMEpvtf0Y/AYIqijHaJ5iWxbgn54qbIfiTJQbqKJno536uaRINu5Vo YckPP5HmfVJtKQvGqqJdoF8Zxp0kvImXxJ7VdK+DQv9hLGQHXwePEw8kQvb1gx7U su1mrta0Eja8MWshos+8sc9PrsDTgJq5lY6baR+AvQ0DkUGJ5KtjRCtqnFMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1718870021; x=1718956421; bh=JHeenBGKjo00Vy0Wx71C86ZiG2/J TmE9tVuHD5MJIGk=; b=sJmwN0waefIXKVlS9ErM0QVu/7TH+k/XcfXRLRtwNAnR xhDTK09nxxe9FFVqbhUT8jtRDiVDqGSyMyy+ZrcWlmPxuGQd4Ss6/OjLXgjatBfq WtBimqZ5nCAXST5rLTYUZVyukGCk/R2Y8Z2Qcet0+dkOSNILj/8BgL4Io06A3nGH bq/uSi24hbPrJxTMPqzYmnhHduB/G5G25IF6hfkb6f8QTYWl6BUewSeuI7fltckp i2GV+OSTZlyWBNLDlf7Jb1H8vEGfSPUPySXsrK/W99RsY9uIJGdxLfC+BYuBnDBt He0rcqsJtH3vX6/TjJCA2dE+1voUvGCNZnzbL2QVCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeefuddguddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdet rhhnugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrg htthgvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedt keetffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grrhhnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0866FB6008D; Thu, 20 Jun 2024 03:53:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-522-ga39cca1d5-fm-20240610.002-ga39cca1d MIME-Version: 1.0 Message-Id: <90b46873-f60f-4ece-bef6-b8eed3b68ac1@app.fastmail.com> In-Reply-To: References: Date: Thu, 20 Jun 2024 09:53:20 +0200 From: "Arnd Bergmann" To: "Linus Torvalds" , "Christian Brauner" , "Alexander Viro" Cc: linux-fsdevel , "the arch/x86 maintainers" , "Linux ARM" , "Linux Kernel Mailing List" , "Alexei Starovoitov" Subject: Re: FYI: path walking optimizations pending for 6.11 Content-Type: text/plain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240620_005347_554296_942206B4 X-CRM114-Status: GOOD ( 15.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jun 19, 2024, at 22:25, Linus Torvalds wrote: > The arm64-uaccess branch is just what it says, and makes a big > difference in strncpy_from_user(). The "access_ok()" change is > certainly debatable, but I think needs to be done for sanity. I think > it's one of those "let's do it, and if it causes problems we'll have > to fix things up" things. I'm a bit worried about the access_ok() being so different from the other architectures, after I previously saw all the ways it could go wrong because of subtle differences. I don't mind making the bit that makes the untagging unconditional, and I can see how this improves code generation. I've tried comparing your version against the more conventional static inline int access_ok(const void __user *p, unsigned long size) { return likely(__access_ok(untagged_addr(p), size)); } Using gcc-13.2, I see your version is likely better in all cases, but not by much: for the constant-length case, it saves only one instruction (combining the untagging with the limit), while for a variable length it avoids a branch. On a 24MB kernel image, I see this add up to a size difference of 12KB, while the total savings from avoiding the conditional untagging are 76KB. Do you see a measurable performance difference between your version and the one above? On a related note, I see that there is one caller of __access_ok() in common code, and this was added in d319f344561d ("mm: Fix copy_from_user_nofault()."). I think that one should just go back to using access_ok() after your 6ccdc91d6af9 ("x86: mm: remove architecture-specific 'access_ok()' define"). In the current version, it otherwise misses the untagging on arm64. Arnd