Please always mention the kernel version and machine you are using when asking any question like this. The output of "uname -a" is a good, concise way to include everything I'll need to see. When reporting about a 64-bit kernel, it is also crucial to mention whether the user binaries in question are 32-bit or 64-bit.
I deduced from your use of "orig_ax" that you are talking about x86. I deduced from the example syscall numbers that it's i386 (x86-32), or at least 32-bit binaries if a 64-bit kernel. For real code, you should be using syscall_get_nr (asm/syscall.h), not your own magic arch knowledge. (Of course, using ->orig_ax in temporary printk hacks is always fine.) The short answer is that syscall_get_nr only gives a meaningful syscall number when you are at the syscall entry stop (or blocked inside the syscall, as in task_current_syscall's calls). By exit tracing time, you can't expect to get a meaningful value. The generic details are that the call number is not necessarily anywhere any more. On some arch's the pt_regs slot containing the call number at entry tracing is something else entirely (like the return value). The specifics on x86 are that sigreturn is a special system call. After entry, the real meaning of orig_ax is "the call number to be restarted if the return value is -ERESTART*". For normal calls, the return value register (ax) indicates whether the call returned an error; if it's a small negative number, that's a negated errno code. When orig_ax >= 0 and ax==-ERESTART*, then the call can be restarted. However, sigreturn and other such calls don't put a return value in that register--they're restoring some user value that might be anything (including -ERESTARTSYS). So, sigreturn resets orig_ax=-1 to indicate that there is no syscall that might be restarted. This ensures that the ax value (and ip value) restored by sigreturn remain as they are unmolested all the way back to user mode. In summary, what you are seeing is perfectly normal and expected behavior. Thanks, Roland
