Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1423206ybj; Tue, 5 May 2020 20:49:32 -0700 (PDT) X-Google-Smtp-Source: APiQypKbKOShVMX+FF1WBh1xOlR2VOJCrtvi0nBaKoX4miDip2g4UGUAgg/5Dl841N2tIhZ5BR7h X-Received: by 2002:a17:906:4714:: with SMTP id y20mr5822264ejq.5.1588736972010; Tue, 05 May 2020 20:49:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588736972; cv=none; d=google.com; s=arc-20160816; b=RFUPCUZ4q26Un0FlBsad/8Nba02tMKAejXAv+qXeTqNmcCanAayZEg3bFKO6+hRRnq 7oaQ4QHbf30njRRnPt0Cp5+iEq0cBSSrMm5dS1bLWWD6ELPbYUh/9PTyJqrcISKaIZOP 4c8CeB/dntrlFRWFoZn6keL8KPuhYlZU+U/oUML9OiiRXI10pSm+GnKmiBdYqlUSHEB5 FiFWD9pcyiVGNqSSLmVRo7NS92PU35DrtAhMr+GOERVO+Tg5nMJJ8EWdDSRaM1ngxQ45 6mReDfEg+j9Q/7U+lV+QzR/enbFtGU5O971e4nUL/9Ds+aZxjuR1PPY3pdXd6xbVskKz 8LMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=zWB6cWjMNsKtRxqY/kkJuBnxLsHqY4CSraBHoWMjqp4=; b=AuJwFpIEDERz0oyzVLkP9VQHLUn19B3GsPHUYBRaXuh18ofsOUtjCUlXsjIGeiJwRb ZpPcYN4M5CLY3o8t7BDRIdqeOzNGng5LIIuJEDdVhn0pglDtQsLPnuuyBiyzHFJpMI09 UC7vTGVtfpZo4J6uwfRqPAi2o00q9TRyOa6JQD5Y5H2HVFrLwKB0ang6kesJRGG3X9rT peJ55SZD1znBodrmZqhKWanlKuC5MIioIdTmqTgqdJAUSG84udfNsHg0YqPtUrOufzLw PaTf0QbN0qGzYUYNlEkc2na5easRv7OkGmpAHuFI/IX065fkD9cv0DCi+MeRyz6J7gtr RFzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OKN4zkBY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 62si394668edc.305.2020.05.05.20.49.06; Tue, 05 May 2020 20:49:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OKN4zkBY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726712AbgEFDp0 (ORCPT + 99 others); Tue, 5 May 2020 23:45:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725908AbgEFDp0 (ORCPT ); Tue, 5 May 2020 23:45:26 -0400 Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D82CC061A0F for ; Tue, 5 May 2020 20:45:26 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id k133so320010oih.12 for ; Tue, 05 May 2020 20:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zWB6cWjMNsKtRxqY/kkJuBnxLsHqY4CSraBHoWMjqp4=; b=OKN4zkBYDIz62lBDvEf3XM4DOuCpBniwoB2/yAFzUSYvxGBnmfmk4quJbCwxjP8DU4 xLekmYvvK98w1NXnfe18epulQwaf2+My7yXmRnUncgTNHmX6BQEZFqAgF3JFDGeHWa8+ Wbau+QfB/sZDYuLIB3bjX1iQJUToyR1I+k0IZkqJm/07hUnUAQQ1vRXD5CJ+h0n/aq+L 3uf/30GOdRyiYkrNxBtM2huEyCGf5lQYugw3kkdLFna922yF/1J0v3s/y0DXrYoXzVzX f9rUeMCQmbgu9sXAYqxrKEs8BEJWpnKOVhsxzZo5g2Pj2d9a0C3KmGNJIMHH4kQRfRLk gY3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zWB6cWjMNsKtRxqY/kkJuBnxLsHqY4CSraBHoWMjqp4=; b=YkYJYwNHKeej7uw/Ij+Rxfvsn42sMOhdvjllIguUHZbjfMLZ2Nyqc4s5i4XxdiO2eR 4ohIghuj/Zkxi7W98L0xHhZ4tnEUPkyHHMrZSTcgVKHxSa7oAbXIwVkkAKHdDjnRqGBj poj+XmU5Ya64GlcbHsWua3FdOf439d+/wnV9ZwtjrWDTSfYRsn5LTG36lKLBx3/bdvaM hEtRGbsDQ1c8KsdrHCeKwyDmY0oK6rst54ZsG8ysz8AzI+RdwpO9jawRi3EjEn4rSm0K NxoTuGc30/fkT7tl2GSqGYVbxAoB5KiyAd8qYa/o9qNjYsMMV1qXDihiJ34C8atn+ErH f5lQ== X-Gm-Message-State: AGi0PubsttBn6cJlVWliDpGn+IbJZqocuwOgecJieNIjrY9CswK5rf+B NTkqwZVscOuWSHTj9+wsVio= X-Received: by 2002:a54:409a:: with SMTP id i26mr1403854oii.50.1588736725456; Tue, 05 May 2020 20:45:25 -0700 (PDT) Received: from ubuntu-s3-xlarge-x86 ([2604:1380:4111:8b00::1]) by smtp.gmail.com with ESMTPSA id r6sm304439oom.26.2020.05.05.20.45.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 20:45:24 -0700 (PDT) Date: Tue, 5 May 2020 20:45:23 -0700 From: Nathan Chancellor To: Torsten Duwe Cc: Mark Rutland , Arnd Bergmann , Catalin Marinas , Will Deacon , Ard Biesheuvel , Amit Daniel Kachhap , Torsten Duwe , Ard Biesheuvel , AKASHI Takahiro , Josh Poimboeuf , Julien Thierry , Andrew Morton , Marc Zyngier , Kees Cook , Alexandre Ghiti , Kristina Martsenko , Ionela Voinescu , Steve Capper , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com, Fangrui Song Subject: Re: [PATCH] arm64: disable patchable function entry on big-endian clang builds Message-ID: <20200506034523.GA564255@ubuntu-s3-xlarge-x86> References: <20200505141257.707945-1-arnd@arndb.de> <20200505142556.GF82823@C02TD0UTHF1T.local> <20200505194243.5bfc6ec6@blackhole> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200505194243.5bfc6ec6@blackhole> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org + Fangrui, who implemented patchable_function_entry in LLVM/clang On Tue, May 05, 2020 at 07:42:43PM +0200, Torsten Duwe wrote: > Hi Arnd, Mark and others, > > this may not be worth arguing but I'm currently fighting excessive > workarounds in another area and so this triggers me, so I have to make > a remark ;-) > > On Tue, 5 May 2020 15:25:56 +0100 > Mark Rutland wrote: > > > On Tue, May 05, 2020 at 04:12:36PM +0200, Arnd Bergmann wrote: > > > Clang only supports the patchable_function_entry attribute on > > > little-endian arm64 builds, but not on big-endian: > > > > > > include/linux/kasan-checks.h:16:8: error: unknown attribute > > > 'patchable_function_entry' ignored [-Werror,-Wunknown-attributes] > > > > > > Disable that configuration with another dependency. Unfortunately > > > the existing check is not enough, as $(cc-option) at this point does > > > not pass the -mbig-endian flag. > > > > Well that's unfortunate. :( > > > > Do we know if this is deliberate and/or likely to change in future? I am not sure this is deliberate, I don't see anything about endianness in the commits that added this: https://github.com/llvm/llvm-project/commit/4d1e23e3b3cd7c72a8b24dc5acb7e13c58a8de37 https://github.com/llvm/llvm-project/commit/22467e259507f5ead2a87d989251b4c951a587e4 https://github.com/llvm/llvm-project/commit/06b8e32d4fd3f634f793e3bc0bc4fdb885e7a3ac > > This practically rules out a BE distro kernel with things like PAC, > > which isn't ideal. To be fair, are there big endian AArch64 distros? https://wiki.debian.org/Arm64Port: "There is also a big-endian version of the architecture/ABI: aarch64_be-linux-gnu but we're not supporting that in Debian (so there is no corresponding Debian architecture name) and hopefully will never have to. Nevertheless you might want to check for this by way of completeness in upstream code." OpenSUSE and Fedora don't appear to have support for big endian. > But still better than cumulating workarounds. If clang's flags aren't > orthogonal then that's a bug in clang. If I get a vote here I'm against > it. > > > > Fixes: 3b23e4991fb6 ("arm64: implement ftrace with regs") > > > Signed-off-by: Arnd Bergmann > > > > This looks fine for now, and we can add a version check in future, so: > ^^^^^^^^^^^^^^^^^^^ > see what I mean? And in the end another line of code you'll never again > get rid of. That's a rather pessimistic attitude to have. We've been rather good about trying to fix stuff in the compiler rather than hacking up the kernel. > I suggest to get a quote from clang folks first about their schedule and > regarded importance of patchable-function-entries on BE, and leave it as > is: broken on certain clang configurations. It's not the kernel's fault. We can file an upstream PR (https://bugs.llvm.org) to talk about this (although I've CC'd Fangrui) but you would rather the kernel fail to work properly than prevent the user from being able to select that option? Why even have the "select" or "depends on" keyword then? That said, I do think we should hold off on this patch until we hear from the LLVM developers. > > Acked-by: Mark Rutland > > > > Mark. > > > > > --- > > > arch/arm64/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > > index 4b256fa6db7a..a33d6402b934 100644 > > > --- a/arch/arm64/Kconfig > > > +++ b/arch/arm64/Kconfig > > > @@ -151,7 +151,7 @@ config ARM64 > > > select HAVE_DMA_CONTIGUOUS > > > select HAVE_DYNAMIC_FTRACE > > > select HAVE_DYNAMIC_FTRACE_WITH_REGS \ > > > - if $(cc-option,-fies on y=2) > > > + if $(cc-option,-fpatchable-function-entry=2) && > > > !(CC_IS_CLANG && CPU_BIG_ENDIAN) select > > > HAVE_EFFICIENT_UNALIGNED_ACCESS select HAVE_FAST_GUP > > > select HAVE_FTRACE_MCOUNT_RECORD > > > -- > > > 2.26.0 > > > > Cheers, Nathan