This is a good question. For packaging purpose, no, it does not matter much. The people who builds package can choose whatever it is available to them to package. bcc is supposed to work for all major

e.g., in kernel/events/core.c, for perf event overflow handler, we have rcu_read_lock(); ret = BPF_PROG_RUN(event->prog, &ctx); rcu_read_unlock(); out: __this_cpu_dec(bpf_prog_active); if (!ret) retur

<jtu3=hawk.iit.edu@...> wrote: Currently, no. Kernel has support to replace a bpf program, but not kernel function. Replacing kernel functions may easily causing kernel mishehave. There

XDP only tracks raw packet. There is no skb or other meta data is available at that point. You either need to track by yourself or you add another skb or sk level hook.

Maybe you can use sk_local_storage? You can attach a piece of information to the socket during TCP_SYN_RECV and later on during TCP_ESTABLISHED to check that data, and you can delete that data from th

It is possible. See the patch below: https://lore.kernel.org/bpf/20200819042759.51280-1-alexei.starovoitov@... I tried to load a BPF program and pin it in bpffs system. The system could be exte

You can use bpf_obj_get() API to get a reference to the pinned map. BPF_ANNOTATE_KV_PAIR is old way to provide map key/value types, mostly for pretty print. bcc still uses it. libbpf can use more adva

You cannot use the return value. A recent llvm should return an error if you try to use it. There is some preliminary work to have more atomic operations in the BPF ISA. https://reviews.llvm.org/D7218

BPF_XADD is to make one map element inside the kenel to update atomically. Could you filx an issue with more details? This way, we will have a better record. Not sure what do you mean here. yes, one c

Could you file a separate issue so it is easy for people to help? Do you have a minimum reproducible test case? This will make it easy to debug. application without pid should work. A test case will b

Your approach seems okay. You can use two maps or use map-in-map. Using batch operation from user space should speedup the deletion operation.

#bcc

<ys114321=gmail.com@...> wrote: I see the issue now. ip_hdr(skb) eventually transforms to static inline unsigned char *skb_network_header(const struct sk_buff *skb) { return skb->head +

#bcc

You did not show the code which actually caused the problem. There must be code after "if ( (ip_Hdr.protocol != IPPROTO_TCP)) return 0;" . You may need bpf_probe_read() for memory accesses there.

#bcc

The init list is too long. The compiler puts {0, 1, 2, ..., 9} in a readonly section. That is why you got the failure below. If you use native clang compilation and a recent kernel, libbpf should be a

<halivingston@...> wrote: Yes, you can do this.

<halivingston@...> wrote: Perf event ring buffer is per cpu. Yes, it is what it did in the kernel. Each array element holds one ring buffer.

PERF_EVENT_OUTPUT map is to hold per cpu ring buffers created by perf_event_open. That is why its typical size is the number of cpus on the host. <halivingston@...> wrote:

What is your llvm version? What is your cmake output? Looks like llvm libraries are not really linked?

Hi, All, Brenden is on vacation this week. So I am sending out the notice. Does anybody have any agenda to discuss on our pre-schedule 30min meeting on Sept 4, 11:00am - 11:30am? If you do, please rep

<arnaldo.melo@...> wrote: You did not miss anything. Currently, there are no counters to count those drops due to nmi or due to bpf program already running on that cpu. There is effort by Daniel