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;
Date:   Wed, 6 May 2020 08:31:56 -0700
From:   Nathan Chancellor <natechancellor@gmail.com>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Torsten Duwe <duwe@lst.de>, Mark Rutland <mark.rutland@arm.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        Amit Daniel Kachhap <amit.kachhap@arm.com>,
        Torsten Duwe <duwe@suse.de>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        AKASHI Takahiro <takahiro.akashi@linaro.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Julien Thierry <jthierry@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Marc Zyngier <maz@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Alexandre Ghiti <alex@ghiti.fr>,
        Kristina Martsenko <kristina.martsenko@arm.com>,
        Ionela Voinescu <ionela.voinescu@arm.com>,
        Steve Capper <steve.capper@arm.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>,
        Fangrui Song <maskray@google.com>
Subject: Re: [PATCH] arm64: disable patchable function entry on big-endian
 clang builds
Message-ID: <20200506153156.GA1213645@ubuntu-s3-xlarge-x86>
References: <20200505141257.707945-1-arnd@arndb.de>
 <20200505142556.GF82823@C02TD0UTHF1T.local>
 <20200505194243.5bfc6ec6@blackhole>
 <20200506034523.GA564255@ubuntu-s3-xlarge-x86>
 <CAK8P3a24EiEvGAenL0FdgGakmwWi=giReOJuiisnzkgC_SuhZg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK8P3a24EiEvGAenL0FdgGakmwWi=giReOJuiisnzkgC_SuhZg@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, May 06, 2020 at 12:22:58PM +0200, Arnd Bergmann wrote:
> On Wed, May 6, 2020 at 5:45 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> > On Tue, May 05, 2020 at 07:42:43PM +0200, Torsten Duwe wrote:
> > > On Tue, 5 May 2020 15:25:56 +0100 Mark Rutland <mark.rutland@arm.com> wrote:
> > > > On Tue, May 05, 2020 at 04:12:36PM +0200, Arnd Bergmann wrote:
> > > > 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.
> 
> I don't think any of the binary distros ship big endian ARM64. There are
> a couple of users that tend to build everything from source using Yocto
> or similar embedded distros, but as far as I can tell this is getting less
> common over time as applications get ported to be compatible with
> big-endian, or get phased out and replaced by code running on regular
> little-endian systems.
> 
> The users we see today are likely in telco, military or aerospace
> settings (While earth is mostly little-endian these days, space is
> definitely big-endian) that got ported from big-endian hardware, but
> often with a high degree of customization and long service life.

Ah yes, that makes sense, thanks for the information and background.
Helps orient myself for the future.

> My policy for Arm specific kernel code submissions is generally that
> it should be written so it can work on either big-endian or little-endian
> using the available abstractions (just like any architecture independent
> code), but I don't normally expect it to be tested on big endian.
> 
> There are some important examples of code that just doesn't work
> on big-endian because it's far too hard, e.g. the UEFI runtime services.
> That is also ok, if anyone really needs it, they can do the work.
> 
> > > 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?
> 
> I definitely want all randconfig kernels to build without warnings,
> and I agree with you that making it just fail at build time is not
> a good solution.
> 
> > That said, I do think we should hold off on this patch until we hear
> > from the LLVM developers.
> 
> +1
> 
>       Arnd

Glad we are on the same page.

Cheers,
Nathan