On Tue, Aug 20, 2019 at 11:23 AM Y Song <[email protected]> wrote: > On Tue, Aug 20, 2019 at 11:02 AM Matthew Ahrens <[email protected]> > wrote: > > > > > > > > On Tue, Aug 20, 2019 at 10:47 AM Yonghong Song <[email protected]> > wrote: > >> > >> On Tue, Aug 20, 2019 at 10:38 AM Matthew Ahrens <[email protected]> > wrote: > >> > > >> > On Mon, Aug 19, 2019 at 4:30 PM Yonghong Song <[email protected]> > wrote: > >> >> > >> >> On Mon, Aug 19, 2019 at 1:54 PM <[email protected]> wrote: > >> >> > > >> >> > Hi all, > >> >> > > >> >> > 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? > >> >> > >> >> preemption is a kernel thing, bcc does not disable it. You need to > >> >> 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 > >> happen. > >> > >> 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. > >> > > > > Great, thanks Yonghong! And I get that this is part of the > infrastructure that calls into the bpf code (e.g. perf_events), not bcc. > > > > > Also we have per cpu counter to prevent when bpf program interrupted > then another bpf to run for tracing programs. > > > > I think that means that if an interrupt fires while the bpf program is > run, the interrupt will run, but if the interrupt causes another tracing > event to fire, the associated bpf program will not run (i.e. the event will > be ignored / dropped). Is that right? > > Yes. See > > https://github.com/torvalds/linux/blob/master/kernel/trace/bpf_trace.c#L88-L97
Thanks for the pointer to the code! --matt -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1781): https://lists.iovisor.org/g/iovisor-dev/message/1781 Mute This Topic: https://lists.iovisor.org/mt/32960072/21656 Group Owner: [email protected] Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
