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 66318C2BD09 for ; Tue, 9 Jul 2024 18:31:12 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: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=IAxoHN3sgPUbQRzuIw8P2CVgkSA4m8jnufuEJfhriJQ=; b=RkVOZC1WCy88PesefbH+mgJ2tm S8yUa66ZDmiIStFKuS4NswUjM4/3rVUarff16bNQSgA4IsKQht6e9VIax5tjEOBFlbuD/hva8HCY3 k0i/GmnHHAaxvtMvx1xlYHqZYi7JxpwhhNuOrXKUfN/iOYLcxKz8k8ocgwp/wwLhXPiimk5pc5bms bq8Nxm/CDD9se6z3ctO9PBCEGWN1aQj3BAGWv3vSH6DESp8M2jVJh9FhvSOJ91Yxc17D9OFvYrYSg vYKlmQI3FzVQZYH3ioINmeVlDgt5Xpdj2HlpmmanpTcIbMEe6ieMYyauaPpTT06u3e/MGDRSsUpc2 yL9wdwwQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRFcD-00000008IYg-0knY; Tue, 09 Jul 2024 18:31:01 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRFbx-00000008IVF-36DM for linux-arm-kernel@lists.infradead.org; Tue, 09 Jul 2024 18:30:46 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 0FDCE6149D; Tue, 9 Jul 2024 18:30:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 030F1C3277B; Tue, 9 Jul 2024 18:30:42 +0000 (UTC) Date: Tue, 9 Jul 2024 19:30:40 +0100 From: Catalin Marinas To: Linus Torvalds Cc: Mark Rutland , Linux ARM Subject: Re: arm64 uaccess series Message-ID: References: <20240709161022.1035500-1-torvalds@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240709_113045_864789_46600CEC X-CRM114-Status: GOOD ( 28.35 ) 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 Tue, Jul 09, 2024 at 10:12:34AM -0700, Linus Torvalds wrote: > On Tue, 9 Jul 2024 at 09:52, Catalin Marinas wrote: > > On Tue, Jul 09, 2024 at 09:01:58AM -0700, Linus Torvalds wrote: > > > I've been running variations of this on my Altra machine for the last > > > month or more, but admittedly my loads are trivial and uninteresting (ie > > > mostly kernel builds). So my test coevrage is not very wide. > > > > I can temporarily pull this branch and 'runtime-constants' into arm64 > > 'for-kernelci'. It's an unstable branch, it doesn't end up in -next. > > It's just pointed at by various CI systems to get some wider testing. I > > can even pull all four branches if you think it's useful. > > Pulling all four branches is probably just as well. The only one that > doesn't have any arm64 changes at all is the link_path_walk one, but > looking at code generation of link_parh_walk (and strncpy_from_user()) > was why the three other branches exist, so they are related in that > way ;) Done, pushed the branch. It's usually picked up by CI systems in a day or two. > > We are still debating this. I don't think the ABI change is that bad > > but, OTOH, user programs with MTE enabled (which would relax the > > access_ok()) haven't been tested much. As a kind of precaution, we could > > enforce the current behaviour via the sysctl abi.tagged_addr_disabled > > and wire it up via a static key. Currently this sysctl only prevents > > setting of the TIF_TAGGED_ADDR flag (and implicitly enforces stricter > > checks in access_ok()). > > I'd actually be interested to hear if anybody really notices. If the > plan is to make a future sane ABI wrt this, wouldn't it be nice if it > turns out nobody even cares about the odd legacy behavior and we can > just leave it behind? > > IOW, why go to extra pain if it turns out that there really are no > reasons to do that? It depends on how late we find out some weird application relying on the current behaviour. The sysctl would have been a quick hack for a distro to restore the old behaviour without patching the kernel. But I agree that most likely it's just an unnecessary extra pain. We can try our luck. -- Catalin