A question about kprobe/kretprobe and kmalloc/kzalloc
zerons
sironhide0null at gmail.com
Wed Dec 21 21:30:59 EST 2016
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.
>
More information about the Kernelnewbies
mailing list