Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1343320

Re: [PATCH net-next 2/3] bpf: introduce BPF_MAP_TYPE_STACK_TRACE

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH net-next 2/3] bpf: introduce BPF_MAP_TYPE_STACK_TRACE
Date 2016-02-25 18:00 +0100
Message-ID <r67qH-6DX-23@gated-at.bofh.it> (permalink)
References <r3nV0-87u-5@gated-at.bofh.it> <r3nV0-87u-13@gated-at.bofh.it> <r655w-54N-21@gated-at.bofh.it> <r67gZ-6Ay-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Feb 25, 2016 at 08:42:40AM -0800, Alexei Starovoitov wrote:
> On 2/25/16 6:23 AM, Peter Zijlstra wrote:
> >>+	id = hash & (smap->n_buckets - 1);
> >Its not at all clear where the corresponding rcu_read_lock() is at.
> >
> >>>+	bucket = rcu_dereference(smap->buckets[id]);
> 
> bpf programs of all types are always executing under rcu_read_lock().
> This is fundamental for maps and majority of the helpers
> that's why there is no WARN_ON(rcu_read_lock_held) in this helper,
> since we already have it in many other places.
> The rcu_read_lock() for kprobe type is in trace_call_bpf().

OK, just not clear from reading this patch in isolation I suppose.

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH net-next 2/3] bpf: introduce BPF_MAP_TYPE_STACK_TRACE Peter Zijlstra <peterz@infradead.org> - 2016-02-25 15:30 +0100
  Re: [PATCH net-next 2/3] bpf: introduce BPF_MAP_TYPE_STACK_TRACE Alexei Starovoitov <ast@fb.com> - 2016-02-25 17:50 +0100
    Re: [PATCH net-next 2/3] bpf: introduce BPF_MAP_TYPE_STACK_TRACE Peter Zijlstra <peterz@infradead.org> - 2016-02-25 18:00 +0100

csiph-web