lkml.org 
[lkml]   [2016]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 05/19] arm64: rename COMPAT to AARCH32_EL0 in Kconfig
    On Sat, Aug 13, 2016 at 06:17:03PM +0300, Yury Norov wrote:
    > On Fri, Aug 12, 2016 at 03:36:12PM +0100, Catalin Marinas wrote:
    > > On Thu, Aug 11, 2016 at 10:29:03PM +0200, Arnd Bergmann wrote:
    > > > On Thursday, August 11, 2016 5:30:03 PM CEST Catalin Marinas wrote:
    > > > > > > > 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)?
    > > > >
    > > > > As I said above, some of them have the same name (which may be a good
    > > > > thing at a first look) but we don't have an architecture guarantee that
    > > > > the feature is present in both AArch32 and AArch64 modes (e.g. AES may
    > > > > only be available in AArch64).
    > > >
    > > > Is this the case on actual implementations that exist today? If they
    > > > are actually always both present, we might be able to get away with it.
    > >
    > > It may be fine on current implementations but what would we do when/if
    > > we actually find such discrepancy? It's not just ARM Ltd designing the
    > > chips, so as long as the architecture doesn't mandate it you may find
    > > strange implementations.
    > >
    > > Imposing such restriction in the architecture doesn't make sense if the
    > > only reason is the /proc/cpuinfo file (and I can't think of any other
    > > reason why this should be enforced).
    > >
    > > What I'm worried about is 32-bit apps running on an arm64 kernel and
    > > making use of the 64-bit /proc/cpuinfo without any guarantee that the
    > > AArch32 state has such features. In my patch proposal linked above I
    > > wanted to always force the compat /proc/cpuinfo for 32-bit tasks.
    >
    > The link doesn't work for me. Is there other link, or what's the
    > maillist there?

    With lkml.kernel.org, just change the 'g' with an 'r':

    http://lkml.kernel.org/r/1464706504-25224-3-git-send-email-catalin.marinas@arm.com

    It was on linux-arm-kernel.

    > So, what we decided finally? Is my understanding correct that we leave
    > everything as is in ilp32 series, and it will be resolved separately?

    ILP32 is not affected by this since the hwcap for ILP32 should match
    native. It was more a question about whether AArch32 tasks should ever
    have access to AArch64 hwcaps (and potential misuse).

    --
    Catalin

    \
     
     \ /
      Last update: 2016-09-17 09:56    [W:2.559 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site