[RFC PATCH 08/11] perf: add perf_output_begin_forward_in_page

2019-05-20 Thread Kris Van Hees
ge is filled with 0s. A new function perf_output_begin_forward_in_page() is to be used to commence output that cannot cross page boundaries. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/linux/perf_event.h | 3 ++ kernel/events/ring_b

[RFC PATCH 09/11] bpf: mark helpers explicitly whether they may change the context

2019-05-20 Thread Kris Van Hees
. This way, whenever a new helper is added that may change the content of the context, there is no need to update a hardcoded list of functions. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/linux/bpf.h| 1 + include/linux/filter.h | 1 - kernel/bpf/core.c | 5

Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

2019-03-15 Thread Kris Van Hees
On Wed, Mar 13, 2019 at 09:30:02AM -0700, Brendan Gregg wrote: > On Tue, Mar 12, 2019 at 9:54 AM Kris Van Hees > wrote: > > > > On Mon, Mar 11, 2019 at 11:03:10PM -0700, Brendan Gregg wrote: > > > On Mon, Mar 11, 2019 at 8:24 PM Kris Van Hees > > > wrote:

Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

2019-03-12 Thread Kris Van Hees
On Mon, Mar 11, 2019 at 11:03:10PM -0700, Brendan Gregg wrote: > On Mon, Mar 11, 2019 at 8:24 PM Kris Van Hees > wrote: > > > > On Mon, Mar 11, 2019 at 06:29:55PM -0700, Brendan Gregg wrote: > > > On Mon, Mar 11, 2019 at 7:21 AM Kris Van Hees > > > wrote:

Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

2019-03-11 Thread Kris Van Hees
On Mon, Mar 11, 2019 at 06:29:55PM -0700, Brendan Gregg wrote: > On Mon, Mar 11, 2019 at 7:21 AM Kris Van Hees > wrote: > > > > On Thu, Mar 07, 2019 at 01:30:37PM -0800, Alexei Starovoitov wrote: > > > On Tue, Mar 05, 2019 at 09:03:57PM -0500, Kris Van Hees wrote: >

Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

2019-03-11 Thread Kris Van Hees
On Thu, Mar 07, 2019 at 01:30:37PM -0800, Alexei Starovoitov wrote: > On Tue, Mar 05, 2019 at 09:03:57PM -0500, Kris Van Hees wrote: > > > > So in summary, I am trying to solve two (related) problems: > > > > - Ensure that unprivileged tracing can obtain informati

Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

2019-03-05 Thread Kris Van Hees
On Tue, Mar 05, 2019 at 10:59:52AM -0800, Alexei Starovoitov wrote: > On Tue, Feb 26, 2019 at 01:46:01AM -0500, Kris Van Hees wrote: > > On Mon, Feb 25, 2019 at 10:18:25PM -0800, Alexei Starovoitov wrote: > > > On Mon, Feb 25, 2019 at 07:54:13AM -0800, Kris Van Hees wrote: &g

Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

2019-02-25 Thread Kris Van Hees
On Mon, Feb 25, 2019 at 10:18:25PM -0800, Alexei Starovoitov wrote: > On Mon, Feb 25, 2019 at 07:54:13AM -0800, Kris Van Hees wrote: > > > > The goal is to further extend the BPF_PROG_TYPE_GTRACE implementation to > > support what tracers commonly need, and I am also looki

[PATCH 2/2] bpf: initial implementation for BPF_PROG_TYPE_GTRACE

2019-02-25 Thread Kris Van Hees
e the context is only initialised when the program is called through a tail-call from a different (supported) program type. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/linux/bpf_gtrace.h | 27 + include/linux/bpf_types.h | 3 + include/uapi/linux/bpf.h

[PATCH 1/2] bpf: context casting for tail call

2019-02-25 Thread Kris Van Hees
do not implement this new feature. A JIT implementation is not available yet in this first iteration. Signed-off-by: Kris Van Hees Reviewed-by: Nick Alcock --- include/linux/bpf.h | 4 kernel/bpf/core.c | 27 ++- kernel/bpf/syscall.c | 2 +- kernel/bpf

[PATCH 0/2] bpf: context casting for tail call and gtrace prog type

2019-02-25 Thread Kris Van Hees
The patches in this set are part of an effort to provide support for tracing tools beyond attaching programs to probes and events and working with the context data they provide. It is also aimed at avoiding adding new helpers for every piece of task information that tracers may want to include in

Re: Potential memory leak in htab_map_update_elem?

2019-01-11 Thread Kris Van Hees
On Fri, Jan 11, 2019 at 09:12:57AM +0100, Daniel Borkmann wrote: > Hi Kris, > > On 01/11/2019 06:08 AM, Kris Van Hees wrote: > > Maybe I am missing something trivial here, but it looks to me that there is > > a leak of htab elements in htab_map_update_elem when you are upd

Potential memory leak in htab_map_update_elem?

2019-01-10 Thread Kris Van Hees
Maybe I am missing something trivial here, but it looks to me that there is a leak of htab elements in htab_map_update_elem when you are updating an existing element. After the new element is linked into the bucket list, the following code snippet is found: if (l_old) { hl