From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752650AbcHKPSN (ORCPT ); Thu, 11 Aug 2016 11:18:13 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:50075 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751392AbcHKPSL (ORCPT ); Thu, 11 Aug 2016 11:18:11 -0400 From: Arnd Bergmann To: Catalin Marinas Cc: "Zhangjian (Bamvor)" , Yury Norov , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arch@vger.kernel.org, libc-alpha@sourceware.org, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, pinskia@gmail.com, broonie@kernel.org, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com, szabolcs.nagy@arm.com, klimov.linux@gmail.com, Nathan_Lynch@mentor.com, agraf@suse.de, Prasun.Kapoor@caviumnetworks.com, kilobyte@angband.pl, geert@linux-m68k.org, philipp.tomsich@theobroma-systems.com, manuel.montezelo@gmail.com, linyongting@huawei.com, maxim.kuvyrkov@linaro.org, davem@davemloft.net, Andrew Pinski , Andrew Pinski , Bamvor Jian Zhang , Hanjun Guo Subject: Re: [PATCH 05/19] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Date: Thu, 11 Aug 2016 17:16:45 +0200 Message-ID: <6457502.FRufylo3sd@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-31-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160811145000.GB18366@e104818-lin.cambridge.arm.com> References: <1466207668-10549-1-git-send-email-ynorov@caviumnetworks.com> <3043310.yXUR8Er0VK@wuerfel> <20160811145000.GB18366@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:7Z7qtC+7JSp+EPNMqIcMSjXEpQ37OsXwUKfoxc6lN/tdzmVWgXW wRfdyo1oWzaYT33qbxFbztnnGF6LdGZu/z/tTsL058/Pw7r0HQPYGnk1tMArVc0pHEvKDHo E4425E4LkR770aaqpFSW59fEOZDqCjSC9xQNYTzJNEjM7mWIEMdE1JdqbEywbnEMUtMabsE Eo7ouxJptHwfdqECu+/mA== X-UI-Out-Filterresults: notjunk:1;V01:K0:gav7ANVHsoA=:POFXU4wZKtoKSE49wFxMDS pyHYD992F0dAe9RYYyEXNNE2BoOTRyZmMpGiluQ8fAf1I86dIs6EmWfmSszjn3vXMNRHsAi5H sDnmif2/V9iQJHpuw/2rrQTdGh4+KBBZW5OZqsUQdczMpfk9S39M9RT3dlb5yVs2FfG05nyML 4ZdMaO5mYhPtXx8rUcpzK5AlrFUB60YOjp6xGVjpOLsHE3UKaKBnE4sXfl5Ov1Zz2w8sDXxZu TNlESgf5xwAYj/fGo2C1Eds4POKl+/P/V0wSddsQMm9lQIQM7D3MhhmaHhkxLNlZjrhaOhaqO +L+pKfCJ6GIqPx0ZdMBFmypVrG5Ej5C3B18JEAS2O973fd2gV/Ka2bC6cev4nkiBjMPLTCCTN vGkusu/rLt3UkYM/VtD005TJjppQdsjj2Q9Hci5dw55x2xw0tD0Ynif5CmDG6anQXvaujajqF yvcASvGE+7V44r+TyH6BneZ/Oya3//vRiJFlxaW/xQKPVlr1owQeBYnUevfGskQC52sSLy4+m C5n+Qvoru4Rnekzu2E3A6OkXUoXmMJkbUOekZBKiPFASpbf+tEbRJ52CkMloamOBwdZRfjiT3 z2M23F4RN9xjwAa9XrYGHbss1JQOX3LvIKBnxSooMOqb3EmuMXqaDoMxZBA4oyf8RHJ80Cq9H VhVFjFR8BJqJ14ZaiLJ8nwGJZ1dpPhRrfrO4dfNLrMBb8mnFG9O5VSpmYhN1ZmQp0OrqxeodC cwxKQ/b0+boYRUh2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, August 11, 2016 3:50:00 PM CEST Catalin Marinas wrote: > On Thu, Aug 11, 2016 at 10:53:01AM +0200, Arnd Bergmann wrote: > > On Thursday, August 11, 2016 3:35:01 PM CEST Zhangjian (Bamvor) wrote: > > > On 2016/6/18 7:54, Yury Norov wrote: > > > > From: Andrew Pinski > > > > > > > > In this patchset ILP32 ABI support is added. Additionally to AARCH32, > > > > which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible. > > > > > > > > From now, AARCH32_EL0 (former COMPAT) config option means the support of > > > > AARCH32 userspace, ARM64_ILP32 - support of ILP32 ABI (see next patches), > > > > and COMPAT indicates that one of them, or both, is enabled. > > > > > > > > Where needed, CONFIG_COMPAT is changed over to use CONFIG_AARCH32_EL0 instead > > > > > > > > Reviewed-by: David Daney > > > > Signed-off-by: Andrew Pinski > > > > Signed-off-by: Philipp Tomsich > > > > Signed-off-by: Christoph Muellner > > > > Signed-off-by: Bamvor Jian Zhang > > > > Signed-off-by: Yury Norov > > > ... > > > > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c > > > > index c173d32..af200a8 100644 > > > > --- a/arch/arm64/kernel/cpuinfo.c > > > > +++ b/arch/arm64/kernel/cpuinfo.c > > > > @@ -134,15 +134,17 @@ static int c_show(struct seq_file *m, void *v) > > > > */ > > > > seq_puts(m, "Features\t:"); > > > > if (compat) { > > > > -#ifdef CONFIG_COMPAT > > > > - for (j = 0; compat_hwcap_str[j]; j++) > > > > - if (compat_elf_hwcap & (1 << j)) > > > > - seq_printf(m, " %s", compat_hwcap_str[j]); > > > > - > > > > - for (j = 0; compat_hwcap2_str[j]; j++) > > > > - if (compat_elf_hwcap2 & (1 << j)) > > > > - seq_printf(m, " %s", compat_hwcap2_str[j]); > > > > -#endif /* CONFIG_COMPAT */ > > > > +#ifdef CONFIG_AARCH32_EL0 > > > I saw that compat_hwcap_str and compat_hwcap2_str is defined when > > > "CONFIG_COMPAT" is true. Why we only change it to CONFIG_AARCH32_EL0 > > > in c show()? > > > > + if (personality(current->personality) == PER_LINUX32) { > > > And "compat" is "personality(current->personality) == PER_LINUX32;", > > > it seems that there is no need to add this twice. > > > > I think it would be best to remove the #ifdef here completely, > > the PER_LINUX32 concept is not strictly tied to the emulation > > of ARM binaries, it literally just changes the output of > > /proc/cpuinfo and 'uname', > > It's not strictly related to ARM binaries, however it is related to > AArch32 CPU features being supported and detected by the kernel. > Currently, with CONFIG_COMPAT disabled, we won't have access to a > (meaningful) compat_elf_hwcap. Ah, makes sense. In that case, using CONFIG_AARCH32_EL0 sounds like the right thing to do here, though I guess we can just drop the "if (compat)" check, as we specifically want to print the supported features of the CPU, and they are still present even if a process with PER_LINUX reads them. > > and you can have ARM binaries with > > PER_LINUX (using the arm64 uname) just like you can have > > arm64 binaries running with PER_LINUX32. > > I was actually looking to enforce the 32-bit binaries to only see > PER_LINUX32, though with a risk of breaking the ABI. OTOH, people are > abusing this and write 32-bit apps relying on the 64-bit /proc/cpuinfo: > > http://lkml.kernel.org/g/1464706504-25224-3-git-send-email-catalin.marinas@arm.com > > (you were summoned on that discussion couple of times ;)) Hmm, I thought I saw the thread and didn't have any good idea for the uname information, but didn't notice it was for /proc/cpuinfo. What's wrong with always showing both the 32-bit and the 64-bit hwcap strings here (minus the duplicates, which hopefully have the same meaning here)? Arnd