ovisor/bcc/issues/1072
Signed-off-by: Alban Crequy
---
Documentation/trace/kprobetrace.txt | 4 +++-
kernel/trace/trace_kprobe.c | 34 +-
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/Documentation/trace/kprobetrace.txt
b/Documenta
Thanks for the review,
On Tue, Mar 28, 2017 at 5:23 PM, Masami Hiramatsu wrote:
> On Tue, 28 Mar 2017 15:52:22 +0200
> Alban Crequy wrote:
>
>> When a kretprobe is installed on a kernel function, there is a maximum
>> limit of how many calls in parallel it can catch
On Thu, Mar 30, 2017 at 8:53 AM, Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
>> > So this is something I missed while the original code was merged, but the
>> > concept
>> > looks a bit weird: why do we do any "allocation" while a handler is
>> > executing?
>> >
>> > That's fundamentally
d-off-by: Masami Hiramatsu
I tested this patch with my kretprobe on "inet_csk_accept" when there
are many processes waiting in the accept() syscall. I can now
successfully see the nmissed counter in
/sys/kernel/debug/tracing/kprobe_profile being incremented when the
kretprobe
nsupported: 0
> # of xfailed: 0
> # of undefined(test bug): 0
BugLink: https://github.com/iovisor/bcc/issues/1072
Signed-off-by: Alban Crequy
---
Changes since v1:
- Remove "(*)" from documentation. (Review from Masami Hiramatsu)
- Fix support for "r100" without th
From: Alban Crequy
When a kretprobe is installed on a kernel function, there is a maximum
limit of how many calls in parallel it can catch (aka "maxactive"). A
kernel module could call register_kretprobe() and initialize maxactive
(see example in samples/kprobes/kretprobe_example.c).
