syscall trace at kernel land

[Rajat Sharma]

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 */
...

#endif

Rajat

On Tue, Jan 11, 2011 at 9:32 PM, Dave Hylands <dhylands at gmail.com> wrote:
> Hi Rajat,
>
> On Tue, Jan 11, 2011 at 2:10 AM, Rajat Sharma <fs.rajat at gmail.com> wrote:
>>> is there any procedure in kernel to check for the interrupt vector number which caused it to be invoked?
>> Its actually very architecture dependent, on x86, its 'int $0x80'
>> which causes user space to call system calls handlers. Recent intel
>> architectures have callgate mechanism to enter into system call, look
>> for sysenter instruction.
>> Anyways, are you interested in interrupt number or the system call number?
>>
>>> i mean like one of my friends said that when  kernel is about to restart a
>>> syscall then it raises signal -ERESTARTSYS signal for signal handler.
>>
>> Thats totally wrong. Like any other error code, its just an error code
>> which waiting API return if process was interrupted while waiting on
>> semaphore, e.g.
>
> On the ARM platform, at least, if a syscall (like ioctl) returns
> -ERESTARTSYS, then the ioctl will be reissued after the signal handler
> runs.
>
> I know this to be true, as I've verified it's functionality
> emperically. This is further supported by the kernel documentation
> http://lxr.linux.no/linux+v2.6.37/Documentation/DocBook/kernel-hacking.tmpl#L346
>
> Dave Hylands
>