Thread (8 messages) 8 messages, 4 authors, 2011-01-12

syscall trace at kernel land

From: Dave Hylands <hidden>
Date: 2011-01-12 07:34:26

Hi Rajat,

On Tue, Jan 11, 2011 at 9:26 PM, Rajat Sharma [off-list ref] wrote:
Hi Dave,

My understanding was based out of linux/errno.h. Maybe the below
comment is in context of glibc abstracting out ERESTART* error codes.

#ifdef __KERNEL__

/*
?* These should never be seen by user programs. ?To return one of ERESTART*
?* codes, signal_pending() MUST be set. ?Note that ptrace can observe these
?* at syscall exit tracing, but they will never be left for the debugged user
?* process to see.
?*/
#define ERESTARTSYS ? ? 512
#define ERESTARTNOINTR ?513
#define ERESTARTNOHAND ?514 ? ? /* restart if no handler.. */
#define ENOIOCTLCMD ? ? 515 ? ? /* No ioctl command */
#define ERESTART_RESTARTBLOCK 516 /* restart by calling sys_restart_syscall */
Yeah - that's consistent with my understanding. The code flow would be
something like this

user-mode program calls ioctl
    ioctl does some stuff
    signal happens
    ioctl detects signal (typically by a call returning -EINTR) and
decides to return -ERESTARTSYS
    sys handler detects pending signal
        user-mode signal handler is called
    sys handler re-issues ioctl
    ioctl does some stuff
    ioctl returns normally
user mode program sees normal reutrn code

So ioctl returns -ERESTARTSYS, but the user mode program is completely
oblivious to the fact that this happened.

glibc doesn't even get to know that the -ERESTARTSYS code was returned
by ioctl. It gets intercepted and processed by the kernel.

Dave Hylands
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help