* syscall trace at kernel land @ 2011-01-11 7:06 mohit verma 2011-01-11 7:39 ` Mulyadi Santosa 0 siblings, 1 reply; 8+ messages in thread From: mohit verma @ 2011-01-11 7:06 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* syscall trace at kernel land 2011-01-11 7:06 syscall trace at kernel land mohit verma @ 2011-01-11 7:39 ` Mulyadi Santosa 2011-01-11 10:10 ` Rajat Sharma 0 siblings, 1 reply; 8+ messages in thread From: Mulyadi Santosa @ 2011-01-11 7:39 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* syscall trace at kernel land 2011-01-11 7:39 ` Mulyadi Santosa @ 2011-01-11 10:10 ` Rajat Sharma 2011-01-11 10:41 ` mohit verma 2011-01-11 16:02 ` Dave Hylands 0 siblings, 2 replies; 8+ messages in thread From: Rajat Sharma @ 2011-01-11 10:10 UTC (permalink / raw) To: kernelnewbies > 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* syscall trace at kernel land 2011-01-11 10:10 ` Rajat Sharma @ 2011-01-11 10:41 ` mohit verma 2011-01-11 11:18 ` Mulyadi Santosa 2011-01-11 16:02 ` Dave Hylands 1 sibling, 1 reply; 8+ messages in thread From: mohit verma @ 2011-01-11 10:41 UTC (permalink / raw) To: 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 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* syscall trace at kernel land 2011-01-11 10:41 ` mohit verma @ 2011-01-11 11:18 ` Mulyadi Santosa 0 siblings, 0 replies; 8+ messages in thread From: Mulyadi Santosa @ 2011-01-11 11:18 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* syscall trace at kernel land 2011-01-11 10:10 ` Rajat Sharma 2011-01-11 10:41 ` mohit verma @ 2011-01-11 16:02 ` Dave Hylands 2011-01-12 5:26 ` Rajat Sharma 1 sibling, 1 reply; 8+ messages in thread From: Dave Hylands @ 2011-01-11 16:02 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* syscall trace at kernel land 2011-01-11 16:02 ` Dave Hylands @ 2011-01-12 5:26 ` Rajat Sharma 2011-01-12 7:34 ` Dave Hylands 0 siblings, 1 reply; 8+ messages in thread From: Rajat Sharma @ 2011-01-12 5:26 UTC (permalink / raw) To: kernelnewbies 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* syscall trace at kernel land 2011-01-12 5:26 ` Rajat Sharma @ 2011-01-12 7:34 ` Dave Hylands 0 siblings, 0 replies; 8+ messages in thread From: Dave Hylands @ 2011-01-12 7:34 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-01-12 7:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-01-11 7:06 syscall trace at kernel land mohit verma 2011-01-11 7:39 ` Mulyadi Santosa 2011-01-11 10:10 ` Rajat Sharma 2011-01-11 10:41 ` mohit verma 2011-01-11 11:18 ` Mulyadi Santosa 2011-01-11 16:02 ` Dave Hylands 2011-01-12 5:26 ` Rajat Sharma 2011-01-12 7:34 ` Dave Hylands
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.