On Tue, Aug 20, 2019 at 10:38 AM Matthew Ahrens <mahrens@...> wrote:
On Mon, Aug 19, 2019 at 4:30 PM Yonghong Song <ys114321@...> wrote:
On Mon, Aug 19, 2019 at 1:54 PM <brad.lewis@...> wrote:
preemption is a kernel thing, bcc does not disable it. You need to
I'm trying to verify that there are no concurrency issues with an approach I'm using cpu_id as a key to a HASH_MAP. My understanding is that bcc disables preemption but the details are fuzzy and I haven't been able to find anything in the code. Can anyone shed some light on this?
check kernel configuration CONFIG_PREEMPT in your host.
When running bpf code from a kprobe / kretprobe, does anything ensure that cpu_id doesn't change while the bpf is running (e.g. due to preemption)? Does anything ensure that no other bpf code runs on this CPU while this kprobe is running (e.g. due to an interrupt firing and hitting a different kprobe)? If either of those things can happen, it seems difficult to atomically increment an entry in a HASH_MAP (even when using the cpu_id as a key).
bpf program run is wrapped in preempt_disable()/preempt_enable()
region. Also we have per cpu counter to prevent when bpf program
interrupted then another bpf to run for tracing programs. Therefore,
for tracing programs, the situation you mentioned in the above won't
The only thing which can happen is networking and tracing program
share the same map, e.g.,
networking bpf program can be nmi interrupted and a bpf tracing
program (perf_event type) may be running.