[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: syscall -1?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]