On Fri, Jul 10, 2026 at 01:40:43PM +0200, Oleg Nesterov wrote: > On 07/10, Michal Suchánek wrote: > > > > On Wed, Jul 08, 2026 at 10:34:38PM +0200, Thomas Gleixner wrote: > > > > > > 1) The set in stone rule is that if the entry code returns -1L as the > > > syscall number then the architecture code has to skip the syscall > > > invocation _and_ is not supposed to change the return value. > > > > Which stone? > > > > Pics or it did not happen. > > > > > > > > 2) There is no guarantee and never has been that any of the involved > > > mechanisms (ptrace, seccomp, tracing) will change the return value > > > when it sets the syscall number to -1L. > > > > For ptrace to correctly emulate a syscall it needs to set the syscall nr > > to an invalid value on entry, and the desired result if the syscall on > > exit AFAICT. > > I can only say that ptrace users do want to skip the syscall and set the > return value on entry. > > See > [PATCH v5 1/2] ptrace: add PTRACE_SET_SYSCALL_INFO syscall skipping > support > https://lore.kernel.org/all/[email protected]/ > > The changelog explains that currently this doesn't work because > among the arches which define HAVE_ARCH_TRACEHOOK (at least) arch/mips is > broken in this regard.
Or it could be documented that setting the return value has to be done in the exit trace, and that would than work on any architecture AFAICT. With ppc and s390 using the same register for the syscall number and syscall return value it's very much impossible to poke the return value on entry into a register using the generic register access function. As of now there is no place to store the value ot of the return value outside of the registers, either. And the current PTRACE_SET_SYSCALL_INFO indeed sets the syscall nr and arguments on entry and the syscall return value on exit, that disctincion is implemented. Not sure how the patchset you point out is relevant, it only adds changes in the exit case. Thanks Michal
