Re: [PATCH 3/7] linux-user/nios2: Adjust error return

[Peter Maydell]

On Fri, 25 Mar 2022 at 12:12, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Sun, 20 Mar 2022 at 16:06, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> >
> > Follow syscall_set_return_value rather than the kernel assembly
> > in setting the syscall return values.  Only negate ret on error.
> >
> > Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> > ---
> >  linux-user/nios2/cpu_loop.c | 15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/linux-user/nios2/cpu_loop.c b/linux-user/nios2/cpu_loop.c
> > index ac71f4ee47..2ae94f4a95 100644
> > --- a/linux-user/nios2/cpu_loop.c
> > +++ b/linux-user/nios2/cpu_loop.c
> > @@ -48,9 +48,18 @@ void cpu_loop(CPUNios2State *env)
> >                                   env->regs[7], env->regs[8], env->regs[9],
> >                                   0, 0);
> >
> > -                env->regs[2] = abs(ret);
> > -                /* Return value is 0..4096 */
> > -                env->regs[7] = ret > 0xfffff000u;
> > +                /*
> > +                 * See syscall_set_return_value.
> > +                 * Use the QEMU traditional -515 error indication in
> > +                 * preference to the < 0 indication used in entry.S.
> > +                 */
>
> Well, it is traditional, in that we've used it for sparc for
> instance right back to commit 060366c5ad18b3e in 2004, and
> even earlier for ppc since commit 678673089d1b.
> probably for about as long for ppc. But *why* do we use this?
> Well, 516 is ERESTART_RESTARTBLOCK, and that's what the
> arch/sparc/kernel/entry.S code is comparing against (it does a
> greater-than-or-equal check, I think, hence 516, not 515).
>
> For powerpc, however, the kernel handles setting the CCR
> bit in syscall_exit_prepare(), and there it checks against
> -MAX_ERRNO.

This turns out to be because in 2015 kernel commit c3525940cca5
switched powerpc from checking against 515/516 and instead made
them check MAX_ERRNO (4095).

(If anybody cared about seccomp on sparc hosts they'd probably
want to fix the sparc kernel similarly, but presumably nobody
does :-))

The kernel commit message mentions some infrastructure in
the form of force_successful_syscall_return() where syscall
implementations can force that a value above -MAX_ERRNO
is still treated as "success". In theory perhaps we should
have something similar...

-- PMM