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*
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
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- ........................ *MOHIT VERMA*
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
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#... Dave Hylands
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#...
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
participants (4)
-
Dave Hylands -
mohit verma -
Mulyadi Santosa -
Rajat Sharma