Re: [iovisor-dev] [PATCH v2 2/5] BPF: Rearrange instruction classes

On Thu, Jun 23, 2016 at 3:52 PM, Richard Henderson via iovisor-dev wrote: > Avoid duplicating lots of field definitions. > > Signed-off-by: Richard Henderson > --- > lib/Target/BPF/BPFInstrFormats.td | 39 ++- > lib/Target/BPF/BPFInstrInfo.td

Re: [iovisor-dev] [PATCH, BPF 1/5] BPF: Use a provisional ELF e_machine value

On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev wrote: > This same value for EM_BPF is being propagated to glibc, > elfutils, and binutils. great! Can you share the link to glibc and the other patches? > diff --git a/include/llvm/Support/ELF.h

Re: [iovisor-dev] [PATCH, BPF 2/5] BPF: Rearrange instruction classes

On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev wrote: > Avoid duplicating lots of field definitions. > > Signed-off-by: Richard Henderson > --- > lib/Target/BPF/BPFInstrFormats.td | 45 +++- > lib/Target/BPF/BPFInstrInfo.td

Re: [iovisor-dev] [PATCH, BPF 4/5] BPF: Add 32-bit move patterns

On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev wrote: > Since all 32-bit operations zero-extend, the move operations are > immediately usable for loading unsigned constants and zero-extension. > > Signed-off-by: Richard Henderson

Re: [iovisor-dev] Todays call & filtering probes on strings

On Wed, Jul 13, 2016 at 4:17 PM, Kyle Laracey via iovisor-dev wrote: > > An additional issue brought up on the call (I apologize for forgetting by > whom) was that any comparisons on long strings would bloat the program, > perhaps beyond the maximum allowed program

Re: [iovisor-dev] BCC: bpf_probe_read read function arguments

On Fri, Aug 12, 2016 at 4:50 PM, Brenden Blanco via iovisor-dev wrote: > > > On Fri, Aug 12, 2016 at 4:46 PM, Mark Drayton via iovisor-dev > wrote: >> >> Here’s a version that works: >> >> >> >>

Re: [iovisor-dev] Todays call & filtering probes on strings

On Mon, Jul 18, 2016 at 01:57:24PM -0700, Kyle Laracey wrote: > Alexei, > > > > What is your use case that needs strings? > > > We are trying to filter on SQL query strings at USDT probes in our product > (a database). We would like to be able to compare a string probe parameter > to another

Re: [iovisor-dev] XDP seeking input from NIC hardware vendors

On Sat, Jul 09, 2016 at 01:27:26PM +0200, Jesper Dangaard Brouer wrote: > On Fri, 8 Jul 2016 18:51:07 +0100 > Jakub Kicinski wrote: > > > On Fri, 8 Jul 2016 09:45:25 -0700, John Fastabend wrote: > > > The only distinction between VFs and queue groupings on my side

Re: [iovisor-dev] XDP eBPF extending with an input parameter?

On Wed, Jul 06, 2016 at 05:21:53PM +0200, Jesper Dangaard Brouer wrote: > > How easy is it to extend the XDP/eBPF program with a new input > parameter? trivial. do git blame include/uapi/linux/bpf.h and see commits for struct __sk_buff We've been adding input md fields non stop without breaking

Re: [iovisor-dev] XDP seeking input from NIC hardware vendors

On Thu, Jul 07, 2016 at 03:18:11PM +, Fastabend, John R wrote: > Hi Jesper, > > I have done some previous work on proprietary systems where we used hardware > to do the classification/parsing then passed a cookie to the software which > used the cookie to lookup a program to run on the

Re: [iovisor-dev] XDP seeking input from NIC hardware vendors

On Thu, Jul 07, 2016 at 09:05:29PM -0700, John Fastabend wrote: > On 16-07-07 07:22 PM, Alexei Starovoitov wrote: > > On Thu, Jul 07, 2016 at 03:18:11PM +, Fastabend, John R wrote: > >> Hi Jesper, > >> > >> I have done some previous work on proprietary systems where we > >> used hardware to do

Re: [iovisor-dev] bpf verification fails when accessing an array element

On Mon, Aug 8, 2016 at 11:29 AM, William Tu wrote: > Hi Alexei, > > Thanks. >> >> This patch does direct packet access from helpers (like lookup and csum): >> https://git.kernel.org/cgit/linux/kernel/git/ast/bpf.git/commit/?id=d2c24a2769693524d >> it's waiting for net-next to

Re: [iovisor-dev] Accessing __string fields in tracepoints

On Tue, Jan 31, 2017 at 4:19 AM, Sasha Goldshtein via iovisor-dev wrote: > Hi all, > > I'm trying to attach a BPF program to a tracepoint that has a __string > field, such as net:net_dev_start_xmit. This tracepoint has the following > format (from

Re: [iovisor-dev] Documentation on eBPF map types?

On Tue, Jan 31, 2017 at 9:54 AM, Jesper Dangaard Brouer via iovisor-dev wrote: > > On Sat, 28 Jan 2017 10:14:58 +1100 Brendan Gregg > wrote: > >> I did some in the bcc ref guide, but it's incomplete, and the bcc versions: >>

Re: [iovisor-dev] reminder: IO Visor TSC/Dev Meeting

On Tue, Feb 7, 2017 at 4:07 PM, Brenden Blanco via iovisor-dev wrote: > > === IO Visor Dev/TSC Meeting === > Every 2 weeks on Wednesday, from Wednesday, January 25, 2017, to no end date > 11:00 am | Pacific Standard Time (San Francisco, GMT-08:00) | 1 hr i have

Re: [iovisor-dev] Documentation on eBPF map types?

On Fri, Feb 3, 2017 at 5:52 AM, Jesper Dangaard Brouer wrote: > On Thu, 2 Feb 2017 20:27:15 -0800 > Alexei Starovoitov wrote: > >> On Thu, Feb 02, 2017 at 06:00:09PM +0100, Jesper Dangaard Brouer wrote: > [...] >> Comments below: > [...] > >> >

Re: [iovisor-dev] Accessing __string fields in tracepoints

On Wed, Feb 1, 2017 at 1:25 AM, Sasha Goldshtein wrote: > > Do you expect the data_loc field structure to change? E.g., do you expect > the size to be != 4 bytes, and the two words (length, offset) to mean > something > else in the future? I don't expect it to change any time

Re: [iovisor-dev] Handling a set of free elements with current map implementations

dhcp function is a slow path and has quite a bit of complexity that is not appropriate for datapath. Normal dhcp is handled by user space dhclient. So I think it would be better to do the same in your case. As an orthogonal discussion it would be useful indeed to have push()/pop() like logic in

Re: [iovisor-dev] bpf invalid stack off=-528

On Fri, Feb 10, 2017 at 9:08 AM, William Tu wrote: > my program is too huge so I start with simple example using xdp1_kern.c > I tried adding an ethernet header as local variable: > > --- a/samples/bpf/xdp1_kern.c > +++ b/samples/bpf/xdp1_kern.c > @@ -51,10 +51,19 @@ int

Re: [iovisor-dev] bpf invalid stack off=-528

On Thu, Feb 9, 2017 at 8:43 AM, William Tu via iovisor-dev wrote: > > $(CLANG) \ > -D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \ > -Wno-compare-distinct-pointer-types \ > -Wno-gnu-variable-sized-type-not-at-end \ >

Re: [iovisor-dev] Question about XDP on multiple NICs with the same driver

On Mon, Aug 22, 2016 at 4:26 PM, William Tu via iovisor-dev wrote: > Hi, > > I'm not sure if we discussed this before, but I'm thinking that if I > have two identical NICs (ex: two e1000 cards with ifindex 1 and 2), > and I load the e1000.ko driver. At userspace, I

Re: [iovisor-dev] README: [PATCH RFC 11/11] net/mlx5e: XDP TX xmit more

On Mon, Sep 12, 2016 at 01:30:25PM +0200, Jesper Dangaard Brouer wrote: > On Thu, 8 Sep 2016 23:30:50 -0700 > Alexei Starovoitov wrote: > > > On Fri, Sep 09, 2016 at 07:36:52AM +0200, Jesper Dangaard Brouer wrote: > [...] > > > Imagine you have packets intermixed

Re: [iovisor-dev] README: [PATCH RFC 11/11] net/mlx5e: XDP TX xmit more

On Mon, Sep 12, 2016 at 10:56:55AM +0200, Jesper Dangaard Brouer wrote: > On Thu, 8 Sep 2016 23:30:50 -0700 > Alexei Starovoitov wrote: > > > On Fri, Sep 09, 2016 at 07:36:52AM +0200, Jesper Dangaard Brouer wrote: > > > > > Lets do bundling/bulking from the start!

Re: [iovisor-dev] Explaining RX-stages for XDP

On Wed, Sep 28, 2016 at 12:44:31PM +0200, Jesper Dangaard Brouer wrote: > > The idea is quite different. It has nothing to do with Edward's > proposal[3]. The RX packet-vector is simply an array, either of pointers > or index numbers (into the RX-ring). The needed changes are completely >

Re: [iovisor-dev] Explaining RX-stages for XDP

On Tue, Sep 27, 2016 at 11:32:37AM +0200, Jesper Dangaard Brouer wrote: > > Let me try in a calm way (not like [1]) to explain how I imagine that > the XDP processing RX-stage should be implemented. As I've pointed out > before[2], I'm proposing splitting up the driver into RX-stages. This > is

Re: [iovisor-dev] clear/empty a bpf hash map

On Mon, Oct 24, 2016 at 10:42:44PM -0700, William Tu wrote: > Hi Alexei, > Thanks for your reply. > > On Mon, Oct 24, 2016 at 7:01 PM, Alexei Starovoitov > wrote: > > On Mon, Oct 24, 2016 at 2:22 PM, William Tu via iovisor-dev > >

Re: [iovisor-dev] clear/empty a bpf hash map

On Mon, Oct 24, 2016 at 2:22 PM, William Tu via iovisor-dev wrote: > Hi, > > Is there an easy way to clear all entries in a BPF hash map? > > My use case: > When my BPF userspace program and kernel BPF is running, I want to > dynamically adding a new BPF hash map.

Re: [iovisor-dev] Unable to attach tracepoint to syscalls event

On Sat, Nov 19, 2016 at 9:45 AM, Mazhar Naqvi via iovisor-dev wrote: > Hi, > > > I am trying to attach my function to a tracepoint. I followed brendangregg's > script "urandomread.py" and modified it to attach to > syscalls:sys_enters_socket but the program gives me

Re: [iovisor-dev] arm64: LLVM ERROR: Inline asm not supported

On Thu, Dec 8, 2016 at 8:20 AM, Ming Lei via iovisor-dev wrote: > Hi, > > Bcc can be installed on ubuntu 16.04/arm64 successfully, but when > I try to trace, the folllowing failure[1] is triggered. > > So is bcc not ready for arm64? Or something is wrong? > > BTW,

Re: [iovisor-dev] arm64: LLVM ERROR: Inline asm not supported

On Sun, Dec 11, 2016 at 5:27 PM, Ming Lei via iovisor-dev wrote: > On Sun, Dec 11, 2016 at 9:21 AM, Chaiken, Alison via iovisor-dev > wrote: >> Ming Lei inquires: >> >> Bcc can be installed on ubuntu

Re: [iovisor-dev] arm64: LLVM ERROR: Inline asm not supported

On Tue, Dec 13, 2016 at 8:43 AM, Brenden Blanco wrote: > > > On Mon, Dec 12, 2016 at 10:38 PM, Alexei Starovoitov > wrote: >> >> On Mon, Dec 12, 2016 at 10:33 PM, Ming Lei wrote: >> > On Tue, Dec 13, 2016 at 2:11 PM,

Re: [iovisor-dev] rpbf: Rust port of uBPF (user space VM for eBPF)

On Mon, Jan 9, 2017 at 8:00 AM, Quentin Monnet via iovisor-dev wrote: > Hello, > > Just in case some people might be interested, I ported the user space > eBPF implementation from Rich Lane (uBPF, in C, > https://github.com/iovisor/ubpf/) to Rust, and it is

Re: [iovisor-dev] [iovisor/bcc] Dealing with long path names (#900)

On Wed, Jan 11, 2017 at 4:23 PM, Konstantin Bukin wrote: > Here is a diff against kernel 4.9.2: > > build-test1:linux-4.9.2$git diff > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > index c201017..64516be 100644 > --- a/include/linux/bpf.h > +++

Re: [iovisor-dev] Build Docker image for iovisor/bcc

On Tue, Nov 29, 2016 at 10:21 AM, Alban Crequy via iovisor-dev wrote: > Hi, > > I think that's a good idea to make it easier to try bcc. > > There is this Docker image but I don't know who is managing it: > https://github.com/zlim/bcc-docker >

Re: [iovisor-dev] reminder: IO Visor TSC and Dev Members Call

sorry. I cannot make it tomorrow. On Tue, Nov 29, 2016 at 8:58 PM, Brenden Blanco via iovisor-dev < iovisor-dev@lists.iovisor.org> wrote: > Hi All, > > Please join us for our bi-weekly call. This meeting is open to everybody > and completely optional. > > *IOVisor TSC/Dev Meeting* > Every 2

Re: [iovisor-dev] LLVM error: couldn't allocate output register for constraint 'r' at line 473618

"couldn't allocate output register for constraint 'r' " means that inline asm was used. Try preprocessing C and look for inline asm usage. On Fri, Jan 6, 2017 at 1:30 PM, William Tu via iovisor-dev wrote: > thanks > the code is at >

Re: [iovisor-dev] [LPC] User Space Dynamic Tracing

On Mon, Nov 14, 2016 at 7:34 AM, Joe Lawrence wrote: > On 11/11/2016 09:41 PM, Alexei Starovoitov wrote: >> On Thu, Nov 10, 2016 at 7:36 AM, Joe Lawrence >> wrote: >>> On 11/09/2016 11:11 PM, Alexei Starovoitov wrote: On Wed, Nov 9, 2016 at

Re: [iovisor-dev] Reading src/dst addresses in reuseport programs

On Tue, Mar 28, 2017 at 7:08 PM, Marek Vavruša via iovisor-dev wrote: > Hi, > > so I was tinkering with programs attached to reuseport groups again, and > simple decisions work as expected. > The problem comes when I want to make decisions based on source or >

Re: [iovisor-dev] Can we attach an IOmodule to a pcap file?

On Mon, Mar 20, 2017 at 10:08:57AM +0100, Fulvio Risso via iovisor-dev wrote: > Dear all, > > perhaps a naive question. > > Instead of attaching an Iomodule to a NIC and perform statistics/whatever, > can we attach the Iomodule to a pcap file? > > The classical BPF (with libpcap) has this

Re: [iovisor-dev] Iovisor and Real-time Llinux scheduler

On Mon, Apr 10, 2017 at 9:18 AM, Fulvio Risso via iovisor-dev wrote: > Dear all, > > since IOVisor is an in-kernel paradigm, is there anyone aware of any study > regarding how RT scheduling within the linux kernel is impacted by the > presence (and operation) of

Re: [iovisor-dev] Iovisor and Real-time Llinux scheduler

On Tue, Apr 11, 2017 at 1:06 PM, Fulvio Risso wrote: > > Is there any documentation that presents the interrupt context in which the > different iomodules operate, according to the attaching point? BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_XDP programs run in softirq.

Re: [iovisor-dev] Wrong size-extension check in BPFDAGToDAGISel::SelectAddr

On Tue, Apr 11, 2017 at 8:48 PM, Nadav Amit wrote: > Using the LLVM backend of BPF, I sometimes get the wrong code to be > generated. > > For example, for the following program: > > int bpf_prog1(void *ign) > { > volatile unsigned long t = 0x8983984739ull; >

Re: [iovisor-dev] Wrong size-extension check in BPFDAGToDAGISel::SelectAddr

On Thu, Apr 13, 2017 at 2:53 PM, Nadav Amit wrote: > > I sent a patch to https://reviews.llvm.org/D32055 . > > I do not know the LLVM test-suite, so please prepare a test based on the > example and the bug-fix. pushed with the test. Do you mind sharing how did you find

Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary

On Tue, Mar 7, 2017 at 3:07 AM, Jesper Dangaard Brouer <jbro...@redhat.com> wrote: > On Mon, 6 Mar 2017 16:14:06 -0800 > Alexei Starovoitov via iovisor-dev <iovisor-dev@lists.iovisor.org> wrote: > >> On Mon, Mar 6, 2017 at 10:29 AM, Jesper Dangaard Brouer >> <jb

Re: [iovisor-dev] [PATCH v3 net-next 00/12] bpf: rewrite value tracking in verifier

On Wed, Jun 28, 2017 at 10:38:02PM +0200, Daniel Borkmann wrote: > On 06/28/2017 04:11 PM, Edward Cree wrote: > > On 28/06/17 14:50, Daniel Borkmann wrote: > > > Hi Edward, > > > > > > Did you also have a chance in the meantime to look at reducing complexity > > > along with your unification? I

Re: [iovisor-dev] [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 8/18/17 7:16 AM, Edward Cree wrote: On 18/08/17 04:21, Alexei Starovoitov wrote: On 8/15/17 12:34 PM, Edward Cree wrote: State of a register doesn't matter if it wasn't read in reaching an exit; a write screens off all reads downstream of it from all explored_states upstream of it. This

Re: [iovisor-dev] [PATCH net-next 2/4] bpf/verifier: remove varlen_map_value_access flag

On 8/22/17 6:26 AM, Edward Cree wrote: The optimisation it does is broken when the 'new' register value has a variable offset and the 'old' was constant. I broke it with my pointer types unification (see Fixes tag below), before which the 'new' value would have type PTR_TO_MAP_VALUE_ADJ and

Re: [iovisor-dev] [PATCH net-next 4/4] bpf/verifier: document liveness analysis

On 8/22/17 8:55 AM, Edward Cree wrote: On 22/08/17 16:42, Alexei Starovoitov wrote: On 8/22/17 6:27 AM, Edward Cree wrote: static bool do_propagate_liveness(const struct bpf_verifier_state *state, struct bpf_verifier_state *parent) { @@ -3457,6 +3463,15 @@ static bool

Re: [iovisor-dev] [PATCH net-next 4/4] bpf/verifier: document liveness analysis

On 8/22/17 6:27 AM, Edward Cree wrote: The liveness tracking algorithm is quite subtle; add comments to explain it. Signed-off-by: Edward Cree --- include/linux/bpf_verifier.h | 13 + kernel/bpf/verifier.c| 28 +++- 2 files

Re: [iovisor-dev] minutes: IO Visor TSC/Dev Meeting

On Wed, May 17, 2017 at 2:14 PM, Brenden Blanco via iovisor-dev wrote: > Hi All, > > Thanks for attending the call today, here are the notes. thanks a lot for taking and publishing these notes! > CFP for Linux Plumbers > Sept 13-15, Los Angeles > Tracing

Re: [iovisor-dev] [RFC PATCH net-next 3/5] bpf/verifier: feed pointer-to-unknown-scalar casts into scalar ALU path

On Wed, Jun 07, 2017 at 03:58:50PM +0100, Edward Cree wrote: > If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES, > treat the pointer as an unknown scalar and try again, because we might be > able to conclude something about the result (e.g. pointer & 0x40 is either > 0

Re: [iovisor-dev] [RFC PATCH net-next 4/5] bpf/verifier: track signed and unsigned min/max values

On Wed, Jun 07, 2017 at 03:59:25PM +0100, Edward Cree wrote: > Allows us to, sometimes, combine information from a signed check of one > bound and an unsigned check of the other. > We now track the full range of possible values, rather than restricting > ourselves to [0, 1<<30) and considering

Re: [iovisor-dev] More BPF verifier questions

On 6/2/17 7:42 AM, Edward Cree wrote: Also, I feel I haven't fully understood the semantics of {min,max}_value and signed vs. unsigned comparisons. It seems that currently reg_set_min_max [_inv] assumes that any given register-value will either only be used as signed, or only be used as

Re: [iovisor-dev] [PATCH RFC v2] bpf: allow map helpers access to map values directly

On Sat, Sep 09, 2017 at 04:31:16PM +0200, Paul Chaignon wrote: > Helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only > access stack and packet memory. Allow these helpers to directly access map > values by passing registers of type PTR_TO_MAP_VALUE. > > This change removes

Re: [iovisor-dev] reminder: IO Visor TSC/Dev Meeting

I won't be able to make it. On Tue, Sep 19, 2017 at 7:53 PM, Brenden Blanco via iovisor-dev wrote: > Please join us tomorrow for our bi-weekly call. As usual, this meeting is > open to everybody and completely optional. > You might be interested to join if: > You

Re: [iovisor-dev] [PATCH RFC v2] bpf: allow map helpers access to map values directly

On Mon, Sep 18, 2017 at 11:14 AM, Paul Chaignon wrote: >> > + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, >> > + offsetof(struct test_val, foo)), >> >> there are few bugs here. >> 1. it adds 4 byte, so it should have been rejected

Re: [iovisor-dev] [PATCH RFC 0/4] Initial 32-bit eBPF encoding support

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 eBPF backend always generate code in 64-bit mode, > > > this may > > > cause troubles

Re: [iovisor-dev] Accessing user memory and minor page faults

On Mon, Oct 02, 2017 at 07:29:51PM -0700, Gianluca Borello via iovisor-dev wrote: > On Sun, Oct 1, 2017 at 7:00 PM, Alexei Starovoitov > wrote: > > > > my understanding of speculative page fault patch is that the whole > > get_user_pages will operate under srcu, so

Re: [iovisor-dev] [PATCH RFC] bpf: allow map helpers access to map values directly

On Fri, Sep 08, 2017 at 10:42:06PM +0200, Paul Chaignon wrote: > Helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only > access stack and packet memory. Allow these helpers to directly access map > values by passing registers of type PTR_TO_MAP_VALUE. thanks for the patch.

Re: [iovisor-dev] Accessing user memory and minor page faults

On Thu, Aug 31, 2017 at 01:41:11PM -0700, Gianluca Borello via iovisor-dev wrote: > Hi > > I wanted to share my recent experience with troubles accessing user memory > when page faults occur, and ask for opinions. > > A bit of introduction first. It's no surprise that a very good portion of >

Re: [iovisor-dev] [PATCH RFC 0/4] Initial 32-bit eBPF encoding support

On Sat, Sep 23, 2017 at 10:41:25AM +0200, Jakub Kicinski wrote: > > > Thinking about next steps - do we expect the 32b operations to clear the > > > upper halves of the registers? The interpreter does it, and so does > > > x86. I don't think we can load 32bit-only programs on 64bit hosts, so > >

Re: [iovisor-dev] Accessing user memory and minor page faults

On Sun, Oct 01, 2017 at 02:08:36PM -0700, Gianluca Borello via iovisor-dev wrote: > On Mon, Sep 25, 2017 at 9:36 AM, Alexei Starovoitov > wrote: > > > > this issue was discussed at Plumbers and it seems there may be > > a solution in sight. The work on 'speculative

Re: [iovisor-dev] [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 8/21/17 2:00 PM, Daniel Borkmann wrote: On 08/21/2017 10:44 PM, Edward Cree wrote: On 21/08/17 21:27, Daniel Borkmann wrote: On 08/21/2017 08:36 PM, Edward Cree wrote: On 19/08/17 00:37, Alexei Starovoitov wrote: [...] I'm tempted to just rip out env->varlen_map_value_access and always

Re: [iovisor-dev] minutes: IO Visor TSC/Dev Meeting

On Wed, Aug 23, 2017 at 4:40 PM, Brenden Blanco via iovisor-dev wrote: > Hi All, > > Thanks for joining in to the call today. We shared a round of updates, which > are > included in the notes below. > > Also please remember that Plumbers is right around the corner!

Re: [iovisor-dev] [PATCH v2 net-next 5/5] bpf/verifier: document liveness analysis

On 8/23/17 7:11 AM, Edward Cree wrote: The liveness tracking algorithm is quite subtle; add comments to explain it. Signed-off-by: Edward Cree Acked-by: Alexei Starovoitov ___ iovisor-dev mailing list

Re: [iovisor-dev] [PATCH v2 net-next 1/5] selftests/bpf: add a test for a bug in liveness-based pruning

On 8/23/17 7:09 AM, Edward Cree wrote: Writes in straight-line code should not prevent reads from propagating along jumps. With current verifier code, the jump from 3 to 5 does not add a read mark on 3:R0 (because 5:R0 has a write mark), meaning that the jump from 1 to 3 gets pruned as safe

Re: [iovisor-dev] [PATCH v2 net-next 2/5] bpf/verifier: when pruning a branch, ignore its write marks

On 8/23/17 7:10 AM, Edward Cree wrote: The fact that writes occurred in reaching the continuation state does not screen off its reads from us, because we're not really its parent. So detect 'not really the parent' in do_propagate_liveness, and ignore write marks in that case. Fixes:

Re: [iovisor-dev] [PATCH RFC] bpf: add connection tracking helper functions

On Fri, Sep 1, 2017 at 4:30 AM, William Tu wrote: > + > + /* TODO: conntrack expectation */ > + > + nf_ct_zone_init(, info->zone_id, > + NF_CT_DEFAULT_ZONE_DIR, 0); > + tmpl = nf_ct_tmpl_alloc(net, , GFP_KERNEL); did you test with

Re: [iovisor-dev] Question about backward jump in bpf

On Tue, Oct 3, 2017 at 9:26 PM, zhiting zhu via iovisor-dev wrote: > Hi, > > What's the use case for backward jump of ebpf? The verifier will reject the > backward edge which makes the backward jump not useful. Am I missing > something? > > Also, from what I read

[iovisor-dev] netdev 2.2 live streaming on facebook

https://www.facebook.com/Kosslab/videos/1503387596414541/ ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev

Re: [iovisor-dev] Incorrect "invalid indirect read" error from verifier?

On Wed, May 9, 2018 at 4:48 AM, Paul Chaignon via iovisor-dev wrote: > Hi, > > I'm getting an "invalid indirect read from stack" when trying to run the > following bcc script: > > paul$ cat tmp.py > from bcc import BPF > bpf_text = """ > #include > #include >

Re: [iovisor-dev] Incorrect "invalid indirect read" error from verifier?

On Wed, May 9, 2018 at 7:43 AM, Paul Chaignon wrote: > > On Wed, May 9, 2018 at 4:38 PM, Paul Chaignon > wrote: >> >> On Wed, May 09, 2018 at 07:26:17AM -0700, Alexei Starovoitov wrote: >> > On Wed, May 9, 2018 at 4:48 AM, Paul Chaignon via

Re: [iovisor-dev] How to use USDT probes without having to pass the pid of the traced program?

I think it should be possible to abuse uprobe kernel logic to flip the semaphore value. Instead of writing into /proc/pid/mem we can uprobe on that exact location. Though it's not text, but data section. It may work ? On Wed, Jan 17, 2018 at 8:57 AM, Sasha Goldshtein via iovisor-dev

Re: [iovisor-dev] How to use USDT probes without having to pass the pid of the traced program?

yep. uprobe is always 'int 3' so far, since kernel needs to take control. we can add something like writing arbitrary value as long as that address is in the file and accessed via inode. If semaphore is in bss then kernel changes would be required. I hope we can try such approach without changing

Re: [iovisor-dev] BPF hackfest in Berlin end of September 2018?

On Fri, Mar 23, 2018 at 7:49 AM, Alban Crequy via iovisor-dev wrote: > Hi, > > I’d like to suggest a BPF hackfest in Berlin in the days before the > All Systems Go! Conference which will take place September 28-30. All > Systems Go! is the user-space Linux