On Tue, Nov 15, 2022 at 2:04 AM TATSUKAWA KOSUKE(立川 江介)
wrote:
>
> Hi,
>
> I was using nfsslower in bcc tools and noticed that it doesn't print out
> slow commit operations, which sometimes cause long delays in NFS writes.
> I tried adding code to trace slow commit operations and created the
>
Hi, Jules,
Just go to https://github.com/iovisor/bcc/issues and you can find
quite some issues for you to investigate. Thanks!
Yonghong
On Wed, Aug 10, 2022 at 3:02 AM Jules Irenge wrote:
>
> Hi
> I am looking for some bcc issues for newbie.
> Any link ?
>
> Jules
> ..
>
On Tue, Nov 2, 2021 at 7:31 AM Eelco Chaudron wrote:
>
> [Edited Message Follows]
>
> On Tue, Nov 2, 2021 at 03:24 PM, Eelco Chaudron wrote:
>
> Hi,
>
> Was wondering if there is a way to count the number of times
> map.ringbuf_reserve() fails for a BPF_RINGBUF_OUTPUT buffer?
>
> This way I can
On Fri, Oct 22, 2021 at 12:31 AM Federico Parola
wrote:
>
> Thanks for the answer, I wasn't aware of the existence of that helper.
> I have two additional comments:
>
> 1. The documentation of the helper says that passing a length of zero
> should pull the whole length of the packet [1], however
On Tue, Oct 19, 2021 at 8:13 AM Federico Parola
wrote:
>
> Dear all,
> how can I access the payload of the packet in a program attached to the
> TC egress hook (SCHED_CLS attached to clsact qdisc)?
> ctx->data_end points to the end of the L4 header, while on the ingress
> hook it points to the
On Fri, Apr 16, 2021 at 12:56 PM Yonghong Song via lists.iovisor.org
wrote:
>
> On Thu, Apr 15, 2021 at 11:09 PM Bradley Schatz
> wrote:
> >
> > I still digging into this issue, and have hacked memleak/bcc to show
> > addresses when they cant be resolved. In o
On Thu, Apr 15, 2021 at 11:09 PM Bradley Schatz
wrote:
>
> I still digging into this issue, and have hacked memleak/bcc to show
> addresses when they cant be resolved. In other places, I'm seeing jit
> complied java stack frames showing up alongside C ones, which is the expected
> behaviour
On Mon, Apr 5, 2021 at 10:08 PM Bradley Schatz
wrote:
>
> Thanks for the suggestion. I found a tunable to keep the JNI shared library
> in memory after loading. As you can see below, it is no longer showing as
> deleted.
>
> 13238272 bytes in 404 allocations from stack
>
On Wed, Mar 31, 2021 at 11:25 PM Bradley Schatz
wrote:
>
> Hi,
>
>
>
> I’m just starting to come to grips with bcc & perf-map-agent for
> introspecting java on linux, with the goal of identifying what appears to be
> an off-heap memory leak (using memleak).
>
>
>
> I appear to be getting
On Tue, Mar 16, 2021 at 4:00 AM Abel Wu wrote:
>
> Hi, when I looked into the runqlen script yesterday, I found that,
> sadly, I misunderstood the "queue length" all the time not only the
> "length" part but also the "queue" part.
Could you file an "issue" for the question? This issue, the
On Thu, Mar 18, 2021 at 4:49 AM Federico Parola
wrote:
>
> Hi,
> the virtual function you are looking for is perf_submit_skb():
>
> https://github.com/iovisor/bcc/blob/c8de00e1746e242cdcd68b4673a083bb467cd35e/src/cc/export/helpers.h#L193
>
> Strangely it is not documented in the reference guide.
On Wed, Feb 24, 2021 at 12:24 PM wrote:
>
> Hello,
>
> I was wondering if BCC implements the new BPF feature (as of kernel 5.10) to
> allow BPF programs to utilize both BPF tail calls and BPF subprograms. This
> behavior is described near the end of this section of the BPF reference
> guide. I
Unfortunately, the value is defined in Makefile,
```
ifeq ($(CONFIG_KASAN_SW_TAGS), y)
KASAN_SHADOW_SCALE_SHIFT := 4
else ifeq ($(CONFIG_KASAN_GENERIC), y)
KASAN_SHADOW_SCALE_SHIFT := 3
endif
KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
KBUILD_CPPFLAGS +=
On Mon, Feb 15, 2021 at 3:45 AM Raga lahari wrote:
>
> Hi,
>
>
> I am trying to write a BPF perf event program to get CPU runq length. The
> Following is the code snippet. I am observing that a big integer (len is
> 2839296536 ) as queue length in trace output for some instances.
>
>
> Can
On Fri, Jan 15, 2021 at 12:42 PM William Findlay
wrote:
>
> Hi all.
>
> Currently debugging a very strange behaviour with eBPF hash maps and was
> wondering if anyone else has run into a similar issue? I am using libbpf-rs
> with BPF CO-RE and my kernel version is 5.9.14.
>
> My setup: I have a
On Fri, Dec 25, 2020 at 5:41 PM Andrei Matei wrote:
>
> For posterity, I think I can now answer my own question. I suspect
> things were different in 2018 (because otherwise I don’t see how the
> referenced exchange makes sense); here’s my understanding about the
> verifier’s rules for stack
On Wed, Dec 23, 2020 at 2:21 PM Andrei Matei wrote:
>
> Hello Yonghong, all,
>
> I'm curious about a verifier workaround that Yonghong provided two years ago,
> in this thread.
> Brendan Gregg was asking about accessing stack buffers through a register
> with a variable offset, and Yonghong
On Thu, Nov 19, 2020 at 9:57 AM Marinos Dimolianis
wrote:
>
> Thanks for the response.
> LPM is actually the closest solution however I wanted a structure closer to
> the way TCAMs operate in which you can have wildcards also in the interim
> bits.
> I believe that something like that does not
On Wed, Nov 18, 2020 at 6:20 AM wrote:
>
> Hi all, I am trying to find a way to represent wildcards in BPF Map Keys?
> I could not find anything relevant to that, does anyone know anything further.
> Are there any efforts towards that functionality?
The closest map is lpm (trie) map. You may
On Tue, Sep 29, 2020 at 4:14 AM Kanthi P wrote:
>
> Hi,
>
> I am looking for tracking inbound connections on a system using
> tracepoints/kprobes.
>
> I was checking "trace_inet_sock_set_state", with which we can track the state
> changes during connection establishment and closure. It seems
On Sun, Sep 6, 2020 at 7:55 AM Shung-Hsi Yu wrote:
>
> Hi,
>
> Is it possible to load a BPF program at boot time?
It is possible. See the patch below:
https://lore.kernel.org/bpf/20200819042759.51280-1-alexei.starovoi...@gmail.com/
I tried to load a BPF program and pin it in bpffs system. The
On Fri, Aug 14, 2020 at 12:05 PM Ian wrote:
>
> Hello BPF Community!
>
> Hope you are all doing well. I am trying to have a user space program create
> a BPF Hash map with a single element containing its PID. This map could then
> be read by all the BPF programs loaded by the user space
On Sun, Jun 21, 2020 at 4:17 PM Kanthi P wrote:
>
> Thanks Andrii. __sync_fetch_and_add doesn't seem to work as expected, it is
> adding the increment, but it is returning the wrong value.
> I am actually hitting the same issue mentioned here:
>
On Wed, May 6, 2020 at 11:00 PM Yonghong Song via lists.iovisor.org
wrote:
>
> On Wed, May 6, 2020 at 9:26 AM wrote:
> >
> > Hello - I am looking to trace ip_forward_finish. The intent is to trace
> > latency of all TCP connections going through a linux based gateway rou
On Wed, May 6, 2020 at 9:26 AM wrote:
>
> Hello - I am looking to trace ip_forward_finish. The intent is to trace
> latency of all TCP connections going through a linux based gateway router.
> Hence thought of tracing ip_forward_finish kernel function. And capture the
> time-stamp of SYN,
On Mon, Mar 23, 2020 at 10:05 AM Federico Parola wrote:
>
> Hello everybody,
> in my XDP eBPF program I'm trying to initialize an array with a
> brace-enclosed list, however my code is rejected by the verifier.
> Here is a simple piece of code to replicate the problem:
>
> #include
>
> #ifndef
On Sun, Feb 16, 2020 at 8:43 PM Hayden Livingston
wrote:
>
> Imagine I have a per-cpu perf ring buffer for all my cpus.
>
> Now I have two eBPF programs.
>
> In both these eBPF programs I do bpf_update_elem(myFD, ,
> , BPF_ANY)
>
> Will this mean that multiple eBPF programs will be able to write
On Sun, Feb 16, 2020 at 5:09 PM Hayden Livingston
wrote:
>
> Thanks. I had to re-read your reply and the kernel code multiple
> times, but I think I get it now. Please confirm.
>
> It is this call is made by user mode code:
>
> fd = bpf_create_map(BPF_MAP_TYPE_PERF_EVENT_ARRAY, /*key_size*/
>
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.
On Sun, Feb 16, 2020 at 1:52 AM Hayden Livingston
wrote:
>
> I'm very confused why BCC creates a map of number of processors for
> the perf_events
What is your llvm version? What is your cmake output? Looks like llvm
libraries are not really linked?
On Wed, Sep 18, 2019 at 7:56 PM wrote:
>
> Before I started to make a small change to bcc, I thought that I ought to
> verify that 'master' would actually build -- I'm running on Amazon Linux
On Tue, Aug 20, 2019 at 12:05 PM Arnaldo Carvalho de Melo
wrote:
>
> Em Tue, Aug 20, 2019 at 11:22:50AM -0700, Yonghong Song escreveu:
> > On Tue, Aug 20, 2019 at 11:02 AM Matthew Ahrens wrote:
> > > On Tue, Aug 20, 2019 at 10:47 AM Yonghong Song wrote:
> > >
On Tue, Aug 20, 2019 at 11:02 AM Matthew Ahrens wrote:
>
>
>
> On Tue, Aug 20, 2019 at 10:47 AM Yonghong Song wrote:
>>
>> On Tue, Aug 20, 2019 at 10:38 AM Matthew Ahrens wrote:
>> >
>> > On Mon, Aug 19, 2019 at 4:30 PM Yonghong Song wrote:
>>
On Tue, Aug 20, 2019 at 10:38 AM Matthew Ahrens wrote:
>
> On Mon, Aug 19, 2019 at 4:30 PM Yonghong Song wrote:
>>
>> On Mon, Aug 19, 2019 at 1:54 PM wrote:
>> >
>> > Hi all,
>> >
>> > I'm trying to verify that there are no concurrency i
On Mon, Aug 19, 2019 at 1:54 PM 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
On Tue, Aug 6, 2019 at 7:31 AM wrote:
>
> Hello Brenden!
>
> I’m not sure if it counts as an agenda item, but I’m interested in
> recording process events using tracepoints, and I would like to know
> what are the best practices when attempting to do so.
Which tracepoint do you have in mind for
75.097268] ---[ end trace 2937ef4d051e39cd ]---
>
>
>
> I need a couple of days to debug this and then submit the patch if nobody
> finds anything odd in the code.
>
> I hope tomorrow I’ll have good news on this if nobody finds anything odd in
> the code first.
>
>
kup today on how to do it, I'll work on
> that.
> Thank you very much.
>
>
> El vie., 26 de jul. de 2019 01:18, Yonghong Song
> escribió:
>>
>> On Thu, Jul 25, 2019 at 12:11 PM Alexei Starovoitov
>> wrote:
>> >
>> > On Thu, Jul 25, 2019 at 11
; userspace code:
> int32_t * allocArray(size_t ln) { return (int32_t*) malloc(ln *
> sizeof(int32_t)); }
> void sum(int32_t* arr, size_t ln, void* sum) {
> int32_t* s = (int32_t*)sum;
> int i=0;
> for(i=0;i printf("cpu %d: %d\n", i, arr[i]);
>
On Wed, Jul 31, 2019 at 1:34 AM wrote:
>
> Hi all,
>
> I define a BPF_MAP_TYPE_PERCPU_ARRAY and use it to count packets in the xdp
> program. When I read the map from userspace program, I find that the entry
> number doesn't match local CPU numbers. I have 2 CPUs in my VM, but the count
>
On Thu, Jul 25, 2019 at 12:11 PM Alexei Starovoitov
wrote:
>
> On Thu, Jul 25, 2019 at 11:53 AM neirac wrote:
> >
> > Hey Yonghong,
> > I have changed getname_kernel interface to specify the allocation type,
> > all previous callers preserve GFP_KERNEL as the allocation type, after this
> >
On Tue, Jul 23, 2019 at 7:37 AM Carlos Antonio Neira Bustos
wrote:
>
> Hey Yonghong,
> I also needed to replace the call to __getname as allocations on the slab
> cache
> could sleep, that makes getname_kernel the only name cache consumer that does
> not block.
> What do you think ?
Maybe the
Jiri,
Thanks for fixing the issue. Could you submit the patch
as a pull request? The pull request is the standard bcc
review mechanism.
Yonghong
On Mon, Jul 22, 2019 at 1:36 AM Jiri Olsa wrote:
>
> Raghavendra Rao reported that memleak does not display
> proper name of the related kernel
On Fri, Jul 19, 2019 at 6:02 AM cnb wrote:
>
> kern_path is the one, should I move this and dependencies to a new file
> called bfp_namei.c, in there I'll change it to use GFP_ATOMIC or create a new
> function to replace kern_path. What do you think?
I think adding GFP_ATOMIC to function
On Thu, Jul 18, 2019 at 6:21 PM carlos antonio neira bustos
wrote:
>
> Hi,
> Yes, I'm still interested as I need this capability at $WORK, but haven't had
> the time to re-write the dentry functions we need, as currently they could
> sleep.
> I could resume work on this next monday when I get
Hi, Carlos,
Are you still interested in upstreaming this patch? Looks like there
still a desire
to make bcc work inside the containers.
The bpf-next will open next week. If you would like, could you submit again?
I will review the patch on bpf-next as well to make sure we made
forward progress.
Hi, Simon,
Finally got some time to deep dive into the verifier for this issue.
I filed an issue https://github.com/iovisor/bcc/issues/2463 with
possible suggestion to add a new checksum calculation helper
for xdp. I forgot what is your ultimate workaround for this issue.
Could you comment on the
On Thu, May 30, 2019 at 11:26 AM Adam Drescher
wrote:
>
> Thank you for your answer, that makes sense.
>
> This leads me to a follow up question: is there a standard way to see
> if a pinned map has been reloaded, without closing and re-opening the
> map file every time to check? From your
On Mon, May 27, 2019 at 4:04 AM Dorian ROSSE wrote:
>
> Hello everybody,
>
>
> Do you know if I can use a bpf file from bcc for snort ?
You mean a bpf program, right?
Do you mean to have a bpf program to do L7 parsing?
If simple one, it should work. See bcc/examples/networking/http_filter/*.
But
bpf needs 3.7.1 and higher version. Later clang (>= 3.7.1) has more features.
On Tue, May 21, 2019 at 11:13 PM Prashanth Fernando
wrote:
>
> Hi,
>
> The clang version I am using is 3.4.2
>
> clang --version
> clang version 3.4.2 (tags/RELEASE_34/dot2-final)
> Target: x86_64-redhat-linux-gnu
>
On Thu, Apr 11, 2019 at 8:37 AM Simon wrote:
>
> I finally discover that checksum can be calculated via incremental update.
> (see RFC 1624)
>
> Using it, I didn't have to deal with dynamic sized payload and so no more
> issue with the verifier.
Glad you find a solution!
>
> So I go back to
Hi, Jiong,
To follow up the iovisor meeting discussion, the below is my prototype
for an end_loop
instruction in llvm:
https://github.com/yonghong-song/llvm/commit/b83226772100317092cae6478229ed6ca3b9903c
The goal is to help verifier to just focus on these marked cases,
rejecting any other
ot do any optimization, it is simple one insn
each time translation.
>
> On 3/27/19 4:23 PM, Yonghong Song wrote:
> > On Wed, Mar 27, 2019 at 10:17 AM Jiong Wang
> > wrote:
> >>
> >>> On 27 Mar 2019, at 16:43, Simon wrote:
> >>>
> >>> T
need to have bcc installed in the system.
Yonghong
On Tue, Mar 19, 2019 at 11:23 PM Yonghong Song via Lists.Iovisor.Org
wrote:
>
> On Tue, Mar 19, 2019 at 9:06 AM Simon wrote:
> >
> > The compiler is doing optimization which make verifier fail. It is possible
> > an
On Tue, Mar 19, 2019 at 9:06 AM Simon wrote:
>
> The compiler is doing optimization which make verifier fail. It is possible
> an early compiler with less optimizations may work.
>
> Maybe a silly question, but does it make sense to try to change compiler
> optimization option ? (I tried to
On Mon, Mar 18, 2019 at 4:18 AM Simon wrote:
>
> Thx a lot again for your time and your detailed explanation.
>
> About the workaround you proposed, I didn't get where I should repeat __u16
> udp_len = bpf_ntohs(udp->len);.. I tried several spot but didn't succeed to
> make it works.
This is a
On Mon, Mar 11, 2019 at 11:13 PM Yonghong Song via Lists.Iovisor.Org
wrote:
>
> On Mon, Mar 11, 2019 at 4:08 AM Simon wrote:
> >
> > I tried to understand again this verifier error again and probably my
> > previous post does not contain enough informatio
On Mon, Mar 11, 2019 at 4:08 AM Simon wrote:
>
> I tried to understand again this verifier error again and probably my
> previous post does not contain enough information.
>
> I understand that :
>
> 93: (67) r0 <<= 32
> 294: (c7) r0 s>>= 32
> 295: (b7) r1 = 0
> 296: (b7) r2 = 0
> 297: (bf) r3
On Fri, Mar 8, 2019 at 9:22 AM Simon wrote:
>
>
> 35: (69) r3 = *(u16 *)(r7 +38)
> 36: (dc) r3 = be16 r3
>
> r3 get the value from memory, its value could be any one as permitted
> by the type.
>
> Does it mean that r3 is considered as be16 ? I do not understand why as I
> explicitly convert it
On Wed, Mar 6, 2019 at 7:08 AM wrote:
>
> I'm playing with bcc to prototype an UDP load balancer.
>
> I'm facing an issue that I didn't succeed to understand...
>
> In my code I tried to validate my UDP packet using code like this :
>
> struct udphdr *udp;
> udp = iph + 1;
> if (udp +
On Mon, Mar 4, 2019 at 10:45 PM Kanthi P wrote:
>
> Thanks for that!
>
> I think those work because bcc has given utilities to do that.
>
> I am using C and we use libbpf to load programs and to do map operations.
>
> Do you know if we can achieve it in this way too?
You should be able to do the
On Mon, Mar 4, 2019 at 9:52 AM Kanthi P wrote:
>
> Hi,
>
> I have two eBPF programs, each with its own user and kernel programs.
>
> One of the programs defines an eBPF map.
>
> How do I access this map from another eBPF kernel program?
In examples/cpp, we have UseExternalMap.cc, which gives an
On Fri, Feb 8, 2019 at 2:48 PM Mauricio Vasquez
wrote:
>
>
> On 2/7/19 3:49 PM, Yonghong Song wrote:
> > On Thu, Feb 7, 2019 at 8:15 AM Mauricio Vasquez
> > wrote:
> >> Hello folks,
> >>
> >> We have an eBPF program that shares a 64-bits integer
On Thu, Feb 7, 2019 at 8:15 AM Mauricio Vasquez
wrote:
>
> Hello folks,
>
> We have an eBPF program that shares a 64-bits integer with userspace
> using an array map. The eBPF program only reads the integer while the
> user-space application only writes it.
>
> We know this is possible that under
On Thu, Jan 31, 2019 at 12:09 AM Raga lahari wrote:
>
> Hi everyone,
>
>
> I am using BPF_MAP_TYPE_HASH in BPF map definition and my program is working
> as expected.
>
> I have read eBPF-map type BPF_MAP_TYPE_PERCPU_HASH allows for lock free uses
> of hash-tables in eBPF for high performance
This is exactly what `bpftool map` is doing. The source code
https://github.com/torvalds/linux/blob/master/tools/bpf/bpftool/map.c
You can find the map you are interested by iterating all the maps in the system
and then iterating to get all map key/values for that map.
On Mon, Dec 24, 2018 at
On Mon, Dec 3, 2018 at 3:51 AM Aleksei Zakharov wrote:
>
>
>
> 29.11.2018, 07:07, "Y Song" :
> > On Mon, Nov 26, 2018 at 4:29 AM Aleksei Zakharov
> > wrote:
> >> Hi, everyone!
> >> I've written a small script using bcc python lib for qemu block io
> >> latency tracing.
> >> I attach two
On Thu, Nov 29, 2018 at 5:48 AM Pablo Alvarez via Lists.Iovisor.Org
wrote:
>
> Good to know, thanks!
>
> There is no mention of the non-preemption in the bpf or tc-bpf man pages
> or the bcc tutorials. Is it possible to change that? I would be happy to
> add a note about this if pointed in the
On Mon, Nov 26, 2018 at 4:29 AM Aleksei Zakharov wrote:
>
> Hi, everyone!
> I've written a small script using bcc python lib for qemu block io latency
> tracing.
> I attach two uprobes to block_acct_start and block_acct_done.
>
> On some servers i can see unexpectedly high latencies:
> ~#
On Sun, Nov 18, 2018 at 6:55 AM Kanthi P wrote:
>
> Hi,
>
> Can anyone suggest a way to adjust the packet length(for example to strip off
> the payload and have only headers) using eBPF TC program?
You may check helper bpf_skb_change_tail(), which could serve your purpose.
>
> Thanks,
> Kanthi
ntations/KernelRecipes2018/XDP_Kernel_Recipes_2018.pdf
>
> Mauricio:
> - Working to address review comments this week on bpf queue and stackmap
>
> === Attendees ===
> Brenden Blanco
> Yonghong Song
> Jakub Kicinski
> Mauricio Vasquez
> JohnF
> Daniel Borkmann
> J
On Wed, Sep 19, 2018 at 1:20 AM Paul Chaignon wrote:
>
> On Wed, Sept 19, 2018 at 8:17 AM, Yonghong Song wrote:
> > On 9/18/18 12:18 AM, Yutaro Hayakawa wrote:
> > > Hello,
> > >
> > > Paul, thank you for your help. I’m Yutaro a reporter of this issue.
&
On Mon, Sep 17, 2018 at 3:46 PM Alexei Starovoitov
wrote:
>
> On Mon, Sep 17, 2018 at 11:29:13PM +0200, Paul Chaignon wrote:
> > I am sending here as an RFC instead of LLVM's mailing list as I'm not sure
> > this is the intended behavior, and the "fix" may therefore not be needed.
> >
> >
Jiri,
The change looks good. Could you generate a pull request against the
bcc/iovisor github repository?
Thanks!
Yonghong
On Tue, Aug 28, 2018 at 5:01 AM Jiri Olsa wrote:
>
> hi,
> on RHEL7 we are facing timing issues in some bcc-tools
> scripts. The time subsystem might return backward
On Wed, Aug 8, 2018 at 6:32 PM, Carlos Neira wrote:
> Yonghong Song,
> Let me know what you think of this last patch
Looks good. Only one comment in the below. After you addressed it, you can
send the patch to netdev with patch prefix [PATCH bpf-next].
&g
On Wed, Aug 8, 2018 at 2:16 PM, Daniel Borkmann wrote:
> On 08/08/2018 10:57 PM, Brendan Gregg wrote:
>> On Wed, Aug 8, 2018 at 1:28 PM, PJ Waskiewicz
>> wrote:
>>> Hi folks,
>>>
>>> We (Maciek and I) were on the call today, and were experiencing some
>>> audio/mic issues. We're looking for
On Tue, Aug 7, 2018 at 3:47 PM, Carlos Neira wrote:
> Quentin,
>
> Thanks a lot for your feedback, I think I'm getting closer to finish this one.
> I have included the changes suggested, let me know if there is anything else
> that needs to be changed or improved.
>
> From
On Mon, Aug 6, 2018 at 2:52 PM, Raffaele Sommese wrote:
>> Okay, the htab_map_update_elem is indeed called, but you cannot trace it.
>> The following kernel code in kernel/bpf/syscall.c explained the reason:
>>
>> /* must increment bpf_prog_active to avoid kprobe+bpf triggering from
>>
On Mon, Aug 6, 2018 at 11:53 AM, Raffaele Sommese wrote:
> Il giorno lun 6 ago 2018 alle ore 19:40 Y Song ha
> scritto:
>>
>> On Mon, Aug 6, 2018 at 10:17 AM, Raffaele Sommese
>> wrote:
>> >> bpf tracepoints have been removed from recent linux so the you need to
>> >> use kprobe to trace
On Mon, Aug 6, 2018 at 2:44 AM, Krishna Chaitanya
wrote:
> On Mon, Aug 6, 2018 at 3:12 PM Krishna Chaitanya
> wrote:
>>
>> Hi,
>>
>> If we want to use BPF for memory leak for driver modules, we can only
>> print outstanding allocations which could potentially be freed at a
>> later time.
>>
>>
On Thu, Aug 2, 2018 at 10:29 AM, Mauricio Vasquez
wrote:
> Bpf queue map is a new kind of map that provides a LIFO/FIFO queue
> implementation.
>
> In some applications, like a SNAT, it is necessary to keep track of
> a pool of free elemenets, network ports in this case, then a queue
> can be
On Thu, Aug 2, 2018 at 10:30 AM, Mauricio Vasquez
wrote:
> Bpf queue implements a LIFO/FIFO data containers for ebpf programs.
>
> It allows to push an element to the queue by using the update operation
> and to pop an element from the queue by using the lookup operation.
>
> A use case for this
On Thu, Aug 2, 2018 at 10:22 AM, Mauricio Vasquez
wrote:
>
>
> On 08/01/2018 12:41 AM, Y Song wrote:
>>
>> On Tue, Jul 31, 2018 at 1:53 PM, Mauricio Vasquez
>> wrote:
>>>
>>> The example is made by two parts, a eBPF program that consumes elements
>>> from a FIFO queue and prints them in the
On Wed, Aug 1, 2018 at 2:36 AM, Raffaele Sommese wrote:
> Hello everybody,
> I was looking for a similar mechanism,
> I need to trace an event on map update/delete, I have tried with
> tracepoint but I can recover only the file descriptor of map and I
> need the map id too (or the map name).
> Is
On Tue, Jul 31, 2018 at 1:53 PM, Mauricio Vasquez
wrote:
> Bpf queue implements a LIFO/FIFO data containers for ebpf programs.
>
> It allows to push an element to the queue by using the update operation
> and to pop an element from the queue by using the lookup operation.
>
> A use case for this
rectly modify the packet data.
>
> On Tue, Jul 24, 2018 at 12:04 PM, Yonghong Song wrote:
>>
>> On Tue, Jul 24, 2018 at 1:54 AM, François wrote:
>> > On Mon, Jul 23, 2018 at 10:08:08PM +0200, Paul Chaignon wrote:
>> >> On Mon, Jul 23, 2018 at 02
On Tue, Jul 24, 2018 at 9:06 AM, ma...@kevac.org wrote:
>
>
> On Mon, Jul 23, 2018 at 7:48 AM, Y Song wrote:
>>
>>
>> We did not have such an example in BCC. In Facebook, we have a bpf
>> program to catch
>> stack traces for python programs. It is very similar to what you want
>> to achieve in
On Tue, Jul 24, 2018 at 1:54 AM, François wrote:
> On Mon, Jul 23, 2018 at 10:08:08PM +0200, Paul Chaignon wrote:
>> On Mon, Jul 23, 2018 at 02:21:05PM -0400, Andrew Wang wrote:
>> > Hi
>> >
>> > I am writing a bpf program for packet processing and have loaded my ingress
>> > function at BPF.XDP.
On Thu, Jul 19, 2018 at 2:49 PM, Hyunseok wrote:
> Thanks for your reply.
>
> BPF_TABLE("extern") seems to work only if the eBPF program is loaded by the
> same userspace process which creates the map, like in this example.
No. The example uses a locally-created map to illustrate the process,
The following is an example in C++ to import an external map to BPF modules.
https://github.com/iovisor/bcc/blob/master/examples/cpp/UseExternalMap.cc
You can use libbpf function `bpf_obj_get` to get a map fd in the above example.
On Wed, Jul 18, 2018 at 11:48 AM, wrote:
> Hi,
>
> I have an
The kernel needs to a constant offset from the stack for write. The
corresponding kernel verifier code below:
/* stack accesses must be at a fixed offset, so that we can
* determine what type of data were returned.
* See check_stack_read().
On Tue, Jun 19, 2018 at 7:54 AM, William Tu wrote:
> Hi,
>
> I'm trying to run coverage tests on my bpf program and it compiles fails.
> I guess BPF does not support '--coverage' flags?
This will not work.
'-coverage' flag will introduce some additional global functions called
by the program,
On 9/22/17 9:24 AM, Jakub Kicinski wrote:
On Thu, 21 Sep 2017 11:56:55 -0700, Alexei Starovoitov wrote:
On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote:
On 18/09/2017 22:29, Daniel Borkmann wrote:
On 09/18/2017 10:47 PM, Jiong Wang wrote:
Hi,
Currently, LLVM
92 matches
Mail list logo
