"Dmitry V. Levin" <l...@altlinux.org> writes:
> syscall_get_error() is required to be implemented on this
> architecture in addition to already implemented syscall_get_nr(),
> syscall_get_arguments(), syscall_get_return_value(), and
> syscall_get_arch() functions in order to extend the generic
> ptrace API with PTRACE_GET_SYSCALL_INFO request.
>
> Cc: Michael Ellerman <m...@ellerman.id.au>
> Cc: Elvira Khabirova <lineprin...@altlinux.org>
> Cc: Eugene Syromyatnikov <e...@redhat.com>
> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> Cc: Paul Mackerras <pau...@samba.org>
> Cc: Oleg Nesterov <o...@redhat.com>
> Cc: Andy Lutomirski <l...@kernel.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Dmitry V. Levin <l...@altlinux.org>
> ---
>
> Michael, this patch is waiting for ACK since early December.
Sorry, the more I look at our seccomp/ptrace code the more problems I
find :/
This change looks OK to me, given it will only be called by your new
ptrace API.
Acked-by: Michael Ellerman <m...@ellerman.id.au>
> Notes:
> v10: unchanged
> v9: unchanged
> v8: unchanged
> v7: unchanged
> v6: unchanged
> v5: initial revision
>
> This change has been tested with
> tools/testing/selftests/ptrace/get_syscall_info.c and strace,
> so it's correct from PTRACE_GET_SYSCALL_INFO point of view.
>
> This cast doubts on commit v4.3-rc1~86^2~81 that changed
> syscall_set_return_value() in a way that doesn't quite match
> syscall_get_error(), but syscall_set_return_value() is out
> of scope of this series, so I'll just let you know my concerns.
Yeah I think you're right. My commit made it work for seccomp but only
on the basis that seccomp calls syscall_set_return_value() and then
immediately goes out via the syscall exit path. And only the combination
of those gets things into the same state that syscall_get_error()
expects.
But with the way the code is currently structured if
syscall_set_return_value() negated the error value, then the syscall
exit path would then store the wrong thing in pt_regs->result. So I
think it needs some more work rather than just reverting 1b1a3702a65c.
But I think fixing that can be orthogonal to this commit going in as the
code does work as it's currently written, the in-between state that
syscall_set_return_value() creates via seccomp should not be visible to
ptrace.
cheers
> See also
> https://lore.kernel.org/lkml/874lbbt3k6....@concordia.ellerman.id.au/
> for more details on powerpc syscall_set_return_value() confusion.
>
> arch/powerpc/include/asm/syscall.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/syscall.h
> b/arch/powerpc/include/asm/syscall.h
> index a048fed0722f..bd9663137d57 100644
> --- a/arch/powerpc/include/asm/syscall.h
> +++ b/arch/powerpc/include/asm/syscall.h
> @@ -38,6 +38,16 @@ static inline void syscall_rollback(struct task_struct
> *task,
> regs->gpr[3] = regs->orig_gpr3;
> }
>
> +static inline long syscall_get_error(struct task_struct *task,
> + struct pt_regs *regs)
> +{
> + /*
> + * If the system call failed,
> + * regs->gpr[3] contains a positive ERRORCODE.
> + */
> + return (regs->ccr & 0x10000000UL) ? -regs->gpr[3] : 0;
> +}
> +
> static inline long syscall_get_return_value(struct task_struct *task,
> struct pt_regs *regs)
> {
> --
> ldv
