syscall trace at kernel land

syscall trace at kernel land

[mohit verma]

hi ,

let me explain myself :
 for example , open syscall calls sys_open then do_sys_open so
like: do_sys_open -> do_filp_open -> link_path_walk -> so on.
so while the cpu is executing the link_path_walk , is there any procedure in
kernel to check for the interrupt vector number which caused it to be
invoked?
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. but i
think it is for
something went wrong and kernel wanna start the syscall again. but in
between a syscall  routine is it possible to get vector number (i repeat
,sorry) ??

thanks in advance for help

-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110111/4b17a157/attachment-0001.html 

syscall trace at kernel land

[Mulyadi Santosa]

just to avoid confusion 1st...

On Tue, Jan 11, 2011 at 14:06, mohit verma <mohit89mlnc@gmail.com> wrote:
> 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. but i
> think it is for
> something went wrong and kernel wanna start the syscall again. but in
> between a syscall? routine is it possible to get vector number (i repeat
> ,sorry) ??

allow me to rephrase it: if an interrupt crosses by during the
execution of that code path, you wanna find out the interrupt number?

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

syscall trace at kernel land

[Rajat Sharma]

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

rc = wait_event_inetrruptible(..);
if (rc == -ERESTARTSYS) {
    /*
     * your driver should take corrective measure, may be to retry the
code path again,
     * or do some error recovery and send appropriate error code to user space.
     * Note that conventionally -ERESTARTSYS should never be returned
to user space
     */
}

Although name is misleading, its an internal kernel error and is not
at all related to system call restart.

Rajat

On Tue, Jan 11, 2011 at 1:09 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> just to avoid confusion 1st...
>
> On Tue, Jan 11, 2011 at 14:06, mohit verma <mohit89mlnc@gmail.com> wrote:
>> 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. but i
>> think it is for
>> something went wrong and kernel wanna start the syscall again. but in
>> between a syscall? routine is it possible to get vector number (i repeat
>> ,sorry) ??
>
> allow me to rephrase it: if an interrupt crosses by during the
> execution of that code path, you wanna find out the interrupt number?
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

syscall trace at kernel land

[mohit verma]

thanks  rajat,
and of course mulyadi , sorry for the confusion.
@ mulyadi : u got me right as u always do. :)
except system dependencies is there anything which should be taken care of
before implementing this  task??

On Tue, Jan 11, 2011 at 3:40 PM, Rajat Sharma <fs.rajat@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.
>
> rc = wait_event_inetrruptible(..);
> if (rc == -ERESTARTSYS) {
>    /*
>     * your driver should take corrective measure, may be to retry the
> code path again,
>     * or do some error recovery and send appropriate error code to user
> space.
>     * Note that conventionally -ERESTARTSYS should never be returned
> to user space
>     */
> }
>
> Although name is misleading, its an internal kernel error and is not
> at all related to system call restart.
>
> Rajat
>
> On Tue, Jan 11, 2011 at 1:09 PM, Mulyadi Santosa
> <mulyadi.santosa@gmail.com> wrote:
> > just to avoid confusion 1st...
> >
> > On Tue, Jan 11, 2011 at 14:06, mohit verma <mohit89mlnc@gmail.com>
> wrote:
> >> 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.
> but i
> >> think it is for
> >> something went wrong and kernel wanna start the syscall again. but in
> >> between a syscall  routine is it possible to get vector number (i repeat
> >> ,sorry) ??
> >
> > allow me to rephrase it: if an interrupt crosses by during the
> > execution of that code path, you wanna find out the interrupt number?
> >
> > --
> > regards,
> >
> > Mulyadi Santosa
> > Freelance Linux trainer and consultant
> >
> > blog: the-hydra.blogspot.com
> > training: mulyaditraining.blogspot.com
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>



-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110111/ecced732/attachment.html 

syscall trace at kernel land

[Mulyadi Santosa]

Hi Mohit....

On Tue, Jan 11, 2011 at 17:41, mohit verma <mohit89mlnc@gmail.com> wrote:
> thanks? rajat,
> and of course mulyadi , sorry for the confusion.
> @ mulyadi : u got me right as u always do. :)
> except system dependencies is there anything which should be taken care of
> before implementing this? task??

Are you aware that again you do top posting? Please, don't do that.
It's the common rule here. Maybe you don't like it...fine...but we
live here as one single community, so please obey the rule. Alright?

OK, assuming you wanna to track last (or maybe few latest irq number
that has been shot). I think, without certain instrumention, you can't
do that. AFAIK, irq number is pushed in the kernel stack before it
hits the upper half. But it could be clobbered by another one...

I think ftrace or systemtap could help you on that matter...or if you
wanna do freestyle hacking, kprobe will help too as always.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

syscall trace at kernel land

[Dave Hylands]

Hi Rajat,

On Tue, Jan 11, 2011 at 2:10 AM, Rajat Sharma <fs.rajat@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

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@gmail.com> wrote:
> Hi Rajat,
>
> On Tue, Jan 11, 2011 at 2:10 AM, Rajat Sharma <fs.rajat@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
>

syscall trace at kernel land

[Dave Hylands]

Hi Rajat,

On Tue, Jan 11, 2011 at 9:26 PM, Rajat Sharma <fs.rajat@gmail.com> 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