signals, syscalls and schedule()
Hi all. I have several doubts about signals and syscalls. When a signal handler gets involved? About signal, I think I have figured it out, maybe? I checked the source code, and found that when call `prepare_exit_to_usermode` -> `exit_to_usermode_loop`, then `do_signal` gets involved. So when switch to user mode, the signal handler get called before restart the syscall if needed. That means when return from a syscall or the process scheduled, we could handle the signal. Interruptible syscalls, they check the process signal state by themselves and return -ERESTARTSYS or -EINTR, is that why we call them interruptible syscalls? When a syscall running, and then the time slice runs out, does it switch to a new process or wait until the system call returns? If switch to a new process, when the interrupted process runs again, is it still in kernel mode to finish the syscall? Is that to say, a signal is handled when return from a syscall or the process scheduled and it is in usermode? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
A question about kprobe/kretprobe and kmalloc/kzalloc
Hi everyone. I wrote a kernel module to test something. The module uses kprobe and kretprobe, here is a bug I met today. The pre_handler of kprobe, calls `do_something`. The probed instructions are in the middle of a function. The entry_handler of kretprobe, also calls `do_something`. `do_something` calls `kmalloc`+`memset`. Back to userspace, when I have all the functions probed, then the test program cause a high CPU usage, and the keyboard doesn't work. The system does not panic when I set softlockup_panic=1. If `do_something` is called by entry_handler of kretprobe, the module works fine. The bug happens when `do_something` called by the pre_handler of kprobe. So I use "#if 0" to locate the bug. It turns out to be `kmalloc`+`memset`. When I change that to `kzalloc`, problem solved. Then I get confused. `kzalloc` just calls `kmalloc` with a `__GFP_ZERO`. Why the bug only happens when pre_handler of kprobe gets called? Is it necessary to post the source code here? Thanks. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A question about kprobe/kretprobe and kmalloc/kzalloc
Sorry, I thought I solved the problem. Using `kzalloc` doesn't work all the time, I need to add `sleep(1)` in the test case after each syscall, like perf_event_open(...); sleep(1); ioctl(...); sleep(1); ioctl(...); sleep(1); read(...); I have tried these: 1) with `sleep(1)`, both kprobe and kretprobe are enabled 2) without `sleep(1)`, both kprobe and kretprobe are enabled 3) without `sleep(1)`, disable pre_handler of kprobe 4) same as 1), after the first run, comment the `sleep(1)` lines, and run the test again and 1) 3) 4) look fine, On 12/21/2016 07:35 PM, zerons wrote: > Hi everyone. > > I wrote a kernel module to test something. The module > uses kprobe and kretprobe, here is a bug I met today. > > The pre_handler of kprobe, calls `do_something`. The probed > instructions are in the middle of a function. > The entry_handler of kretprobe, also calls `do_something`. > `do_something` calls `kmalloc`+`memset`. > > Back to userspace, when I have all the functions probed, > then the test program cause a high CPU usage, and the > keyboard doesn't work. The system does not panic when > I set softlockup_panic=1. > > If `do_something` is called by entry_handler of kretprobe, > the module works fine. > The bug happens when `do_something` called by the pre_handler > of kprobe. > > So I use "#if 0" to locate the bug. It turns out to > be `kmalloc`+`memset`. When I change that to `kzalloc`, > problem solved. > > Then I get confused. > `kzalloc` just calls `kmalloc` with a `__GFP_ZERO`. > Why the bug only happens when pre_handler of kprobe gets called? > > Is it necessary to post the source code here? Thanks. > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
