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 <apinski@xxxxxxxxxx>
> > > >
> > > > 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 <ddaney@xxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Andrew Pinski <Andrew.Pinski@xxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Philipp Tomsich <philipp.tomsich@xxxxxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Christoph Muellner <christoph.muellner@xxxxxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@xxxxxxxxxx>
> > > > Signed-off-by: Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx>
> > > ...
> > > > 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@xxxxxxx
>
> (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
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
