[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ikq3jddt.fsf@mpe.ellerman.id.au>
Date: Sat, 25 Jan 2025 23:18:06 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Alexey Gladkov <legion@...nel.org>, "Dmitry V. Levin" <ldv@...ace.io>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>, Oleg Nesterov
<oleg@...hat.com>, Eugene Syromyatnikov <evgsyr@...il.com>, Mike Frysinger
<vapier@...too.org>, Renzo Davoli <renzo@...unibo.it>, Davide Berardi
<berardi.dav@...il.com>, strace-devel@...ts.strace.io, Madhavan Srinivasan
<maddy@...ux.ibm.com>, Nicholas Piggin <npiggin@...il.com>, Naveen N Rao
<naveen@...nel.org>, linuxppc-dev@...ts.ozlabs.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/7] powerpc: properly negate error in
syscall_set_return_value()
Alexey Gladkov <legion@...nel.org> writes:
>
...
> I'm not a powerpc expert but shouldn't be used regs->gpr[3] via a
> regs_return_value() in system_call_exception() ?
Yes I agree.
> notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
> {
> ...
> r0 = do_syscall_trace_enter(regs);
> if (unlikely(r0 >= NR_syscalls))
> return regs->gpr[3];
This is the case where we're expecting the r3 value to be a negative
error code, to match the in-kernel semantics. But after this change it
would be a positive error value. It is probably harmless with the
current code structure, but that's just luck.
cheers
Powered by blists - more mailing lists