- On Mar 28, 2018, at 3:38 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 28 Mar 2018 15:32:20 -0400
> Steven Rostedt wrote:
>
>> -#define __DO_TRACE(tp, proto, args, cond, rcucheck) \
>> +#define __DO_TRACE(name, proto, args, cond, rcucheck)
>> \
>>
On Wed, 28 Mar 2018 15:32:20 -0400
Steven Rostedt wrote:
> -#define __DO_TRACE(tp, proto, args, cond, rcucheck) \
> +#define __DO_TRACE(name, proto, args, cond, rcucheck)
> \
> do {\
>
On Wed, 28 Mar 2018 15:22:24 -0400 (EDT)
Mathieu Desnoyers wrote:
> > > cache hot/cold argument clearly doesn't apply.
>
> In the current situation I'm fine with adding this extra field
> to struct tracepoint. However, we should keep in mind to move
> all non-required cache-cold fields to a se
On 3/28/18 12:22 PM, Mathieu Desnoyers wrote:
- On Mar 28, 2018, at 2:54 PM, rostedt rost...@goodmis.org wrote:
On Wed, 28 Mar 2018 11:19:34 -0700
Alexei Starovoitov wrote:
On 3/28/18 11:10 AM, Steven Rostedt wrote:
On Wed, 28 Mar 2018 11:03:24 -0700
Alexei Starovoitov wrote:
I can
- On Mar 28, 2018, at 2:54 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 28 Mar 2018 11:19:34 -0700
> Alexei Starovoitov wrote:
>
>> On 3/28/18 11:10 AM, Steven Rostedt wrote:
>> > On Wed, 28 Mar 2018 11:03:24 -0700
>> > Alexei Starovoitov wrote:
>> >
>> >> I can live with this overhe
On Wed, 28 Mar 2018 11:19:34 -0700
Alexei Starovoitov wrote:
> On 3/28/18 11:10 AM, Steven Rostedt wrote:
> > On Wed, 28 Mar 2018 11:03:24 -0700
> > Alexei Starovoitov wrote:
> >
> >> I can live with this overhead if Mathieu insists,
> >> but I prefer to keep it in 'struct tracepoint'.
> >>
>
On 3/28/18 11:10 AM, Steven Rostedt wrote:
On Wed, 28 Mar 2018 11:03:24 -0700
Alexei Starovoitov wrote:
I can live with this overhead if Mathieu insists,
but I prefer to keep it in 'struct tracepoint'.
Thoughts?
I'm fine with keeping it as is. We could probably use it for future
enhancement
On Wed, 28 Mar 2018 11:03:24 -0700
Alexei Starovoitov wrote:
> I can live with this overhead if Mathieu insists,
> but I prefer to keep it in 'struct tracepoint'.
>
> Thoughts?
I'm fine with keeping it as is. We could probably use it for future
enhancements in perf and ftrace.
Perhaps, we shou
On 3/28/18 10:38 AM, Steven Rostedt wrote:
On Wed, 28 Mar 2018 10:10:34 -0700
Alexei Starovoitov wrote:
and have:
u64 tp_offset = (u64)tp - (u64)_sdata;
if (WARN_ON(tp_offset > UINT_MAX)
return -EINVAL;
btp->tp_offset = (u32)tp_offset;
above math
On Wed, 28 Mar 2018 10:10:34 -0700
Alexei Starovoitov wrote:
> > and have:
> >
> > u64 tp_offset = (u64)tp - (u64)_sdata;
> >
> > if (WARN_ON(tp_offset > UINT_MAX)
> > return -EINVAL;
> >
> > btp->tp_offset = (u32)tp_offset;
>
> above math has to be build time constan
- On Mar 28, 2018, at 12:43 PM, Alexei Starovoitov a...@fb.com wrote:
> On 3/28/18 6:49 AM, Mathieu Desnoyers wrote:
>> - On Mar 27, 2018, at 10:11 PM, Alexei Starovoitov a...@fb.com wrote:
>>
>>> From: Alexei Starovoitov
>>>
>>> compute number of arguments passed into tracepoint
>>> at c
On 3/28/18 10:04 AM, Steven Rostedt wrote:
On Wed, 28 Mar 2018 09:43:56 -0700
Alexei Starovoitov wrote:
Given that only eBPF needs this parameter count, we can move
it to the struct bpf_raw_event_map newly introduced by Steven,
right ? This would reduce bloat of struct tracepoint. For instance
On Wed, 28 Mar 2018 09:43:56 -0700
Alexei Starovoitov wrote:
> >
> > Given that only eBPF needs this parameter count, we can move
> > it to the struct bpf_raw_event_map newly introduced by Steven,
> > right ? This would reduce bloat of struct tracepoint. For instance,
> > we don't need to keep thi
On 3/28/18 6:49 AM, Mathieu Desnoyers wrote:
- On Mar 27, 2018, at 10:11 PM, Alexei Starovoitov a...@fb.com wrote:
From: Alexei Starovoitov
compute number of arguments passed into tracepoint
at compile time and store it as part of 'struct tracepoint'.
The number is necessary to check safe
- On Mar 27, 2018, at 10:11 PM, Alexei Starovoitov a...@fb.com wrote:
> From: Alexei Starovoitov
>
> compute number of arguments passed into tracepoint
> at compile time and store it as part of 'struct tracepoint'.
> The number is necessary to check safety of bpf program access that
> is com
From: Alexei Starovoitov
compute number of arguments passed into tracepoint
at compile time and store it as part of 'struct tracepoint'.
The number is necessary to check safety of bpf program access that
is coming in subsequent patch.
Signed-off-by: Alexei Starovoitov
Reviewed-by: Steven Rosted
16 matches
Mail list logo
