yes. That's what bpf iterator of task->vma is for. The prog doesn't need to execute "within process B" to read its memory. I think that is exactly what you need. The iterator can read mm of another pr

Could you describe what prog is going to do? Have you considered using a task iterator parametrized with a particular task?

bcc python is still used by many where they need on the fly compilation. Such cases still exist. One example is USDT support. The libbpf and CO-RE support for USDT is still wip. So such cases have to

<andrii.nakryiko@...> wrote: just running ./test_xdp_veth.sh on the latest bpf-next with the latest clang I see: BTF debug data section '.BTF' rejected: Invalid argument (22)! - Length: 514 Veri

I think this approach won't quite work with fentry because the same fenty type prog cannot be attached to multiple kernel functions. At load time the kernel verifier needs to hold target kernel functi

I think it may break a bunch of people who rely on bcc being a single library. What is the main motiviation to use libbpf as a shared library in libbcc? I think we can have both options. libbpf as git

No agenda means tomorrow conf call is cancelled. And that would be few months in a row. I think we should stop doing this email roll call as well. The conf call was useful for long time, but not any m

please figure out how to get pidns_info w/o calling into getname_kernel().

Brenden, thanks for the bi-weekly reminders! All, if you have any topics to discuss, please email them to the list, so folks have better idea what to expect tomorrow. Thanks!

perfect. let's agree on the use case first... would be great to have. no doubt. and bpf_map_info returns btf_key_type_id and btf_value_type_id Are you saying btf_key_type_id will return single u32 wit

In your examples above does netdev with corresponding ifindex exist before map is created? Does prog_fd exist ? and socket? In all cases yes. they do. Hence creation of 'map' (even pseudo map) is an u

It's certainly an interesting idea. I think we need to agree on use cases and goals first before bikesheding on the solution. this bit show cases advantage of BTF nicely. this one starting to become a

I think we're all on the same page. Just to reiterate few points: The source of truth of libbpf is in the kernel tree. github/libbpf is a mirror of kernel sources plus few headers that neceesary for t

please define 'unsafe'

reasonably simple? ;) I suspect it doesn't support bpf-to-bpf calls and BTF, right? These were major additions that folks with custom loader will be missing. A lot more stuff to come with BTF, relocat

make sense to me, but I wonder why pahole's dwarf->btf converter doesn't have this issue. Could you describe what exactly are you trying to do with llvm generated elf file?

Here is good summary of why using lgpl in apache product is not a great option: https://issues.apache.org/jira/browse/LEGAL-192?focusedCommentId=13907462&page=com.atlassian.jira.plugin.system.issuetab

<palvarez=akamai.com@...> wrote: I added a comment to bugzilla. Thank you for bringing it up. It was considered a known quirk before, but we should improve it. __sync_add_and_fetch seman

is this a typo? you probably meant 10K rule updates a second ? Last time I've dealt with these algorithms we had 100K acl updates a second. It was an important metric that we were optimizing for. I'm

Thank you for sharing the patches. my opinion on the above two didn't change. To recap: A. Non scalable megaflow map is no go. I'd like to see packet classification algorithm like hicuts or efficuts t