Re: [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs

Will Deacon
2020-10-21T15:39:40Z

On Wed, Oct 21, 2020 at 04:10:06PM +0100, Catalin Marinas wrote:
> On Wed, Oct 21, 2020 at 03:45:43PM +0100, Will Deacon wrote:
> > On Wed, Oct 21, 2020 at 03:09:46PM +0100, Catalin Marinas wrote:
> > > Anyway, if the task placement is entirely off the table, the next thing
> > > is asking applications to set their own mask and kill them if they do
> > > the wrong thing. Here I see two possibilities for killing an app:
> > >
> > > 1. When it ends up scheduled on a non-AArch32-capable CPU
> >
> > That sounds fine to me. If we could do the exception return and take a
> > SIGILL, that's what we'd do, but we can't so we have to catch it before.
>
> Indeed, the illegal ERET doesn't work for this scenario.
>
> > > 2. If the user cpumask (bar the offline CPUs) is not a subset of the
> > > aarch32_mask
> > >
> > > Option 1 is simpler but 2 would be slightly more consistent.
> >
> > I disagree -- if we did this for something like fpsimd, then the consistent
> > behaviour would be to SIGILL on the cores without the instructions.
>
> For fpsimd it makes sense since the main ISA is still available and the
> application may be able to do something with the signal. But here we
> can't do much since the entire AArch32 mode is not supported. That's why
> we went for SIGKILL instead of SIGILL but thinking of it, after execve()
> the signals are reset to SIG_DFL so SIGILL cannot be ignored.
>
> I think it depends on whether you look at this fault as a part of ISA
> not being available or as the overall application not compatible with
> the system it is running on. If the latter, option 2 above makes more
> sense.

Hmm, I'm not sure I see the distinction in practice: you still have a binary
application that cannot run on all CPUs in the system. Who cares if some of
the instructions work?

> > > There's also the question on whether the kernel should allow an ELF32 to
> > > be loaded (and potentially killed subsequently) if the user mask is not
> > > correct on execve().
> >
> > I don't see the point in distinguishing between "you did execve() on a core
> > without 32-bit" and "you did execve() on a core with 32-bit and then
> > migrated to a core without 32-bit".
>
> In the context of option 2 above, its more about whether execve()
> returns -ENOEXEC or the process gets a SIGKILL immediately.

I just don't see what we gain by returning -ENOEXEC except for extra code
and behaviour in the ABI (and if you wanted consistentcy you'd also need
to fail attempts to widen the affinity mask to include 64-bit-only cores
from a 32-bit task).

In other words, I don't think the kernel needs to hold userspace's hand
for an opt-in feature that requires userspace to handle scheduling for
optimal power/performance _anyway_. Allowing the affinity to be set
arbitrarily and then killing the task if it ends up trying to run on the
wrong CPU is both simple and sufficient.

Will