sys_exit: NR -1

[Paul Clarke]

On 6/13/19 4:00 PM, Paul Clarke wrote:
> On 6/12/19 1:32 AM, Naveen N. Rao wrote:
>> Paul Clarke wrote:
>>> What are the circumstances in which raw_syscalls:sys_exit reports "-1" for the syscall ID?
>>>
>>>     perf  5375 [007] 59632.478528:   raw_syscalls:sys_enter: NR 1 (3, 9fb888, 8, 2d83740, 1, 7ffff)
>>>     perf  5375 [007] 59632.478532:    raw_syscalls:sys_exit: NR 1 = 8
>>>     perf  5375 [007] 59632.478538:   raw_syscalls:sys_enter: NR 15 (11, 7ffffca734b0, 7ffffca73380, 2d83740, 1, 7ffff)
>>>     perf  5375 [007] 59632.478539:    raw_syscalls:sys_exit: NR -1 = 8
>>>     perf  5375 [007] 59632.478543:   raw_syscalls:sys_enter: NR 16 (4, 2401, 0, 2d83740, 1, 0)
>>>     perf  5375 [007] 59632.478551:    raw_syscalls:sys_exit: NR 16 = 0
>>
>> Which architecture?
>> For powerpc, see:
>>
>> static inline int syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
>> {
>>     /*
>>      * Note that we are returning an int here. That means 0xffffffff, ie.
>>      * 32-bit negative 1, will be interpreted as -1 on a 64-bit kernel.
>>      * This is important for seccomp so that compat tasks can set r0 = -1
>>      * to reject the syscall.
>>      */
>>     return TRAP(regs) == 0xc00 ? regs->gpr[0] : -1;
>> }
> 
> So, that's intentional?  And has some special meaning?  (I confess I don't understand what the comment is saying exactly.)
> 
> Is this documented?  Does something depend on this ABI?
> 
> To me, it just makes parsing more difficult, both by humans and machines.

I should've noted that the instance I encountered was on x86.

PC