RE: [syzbot] WARNING: refcount bug in sk_psock_get

syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:9c54130c Add linux-next specific files for 20210406 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=17d8d7aad0 > kernel config: https://syzkaller.appspot.com/x/.config

Re: [Patch bpf-next] sock_map: fix a potential use-after-free in sock_map_close()

Cong Wang wrote: > On Thu, Apr 8, 2021 at 5:26 PM John Fastabend > wrote: > > > > Cong Wang wrote: > > > From: Cong Wang > > > > > > The last refcnt of the psock can be gone right after > > > sock_map_remove_links(), so sk_psock_sto

RE: [PATCH v8 bpf-next 00/14] mvneta: introduce XDP multi-buffer support

Lorenzo Bianconi wrote: > This series introduce XDP multi-buffer support. The mvneta driver is > the first to support these new "non-linear" xdp_{buff,frame}. Reviewers > please focus on how these new types of xdp_{buff,frame} packets > traverse the different layers and the layout design. It is on

RE: [Patch bpf-next] sock_map: fix a potential use-after-free in sock_map_close()

eported-by: syzbot+7b6548ae483d6f4c6...@syzkaller.appspotmail.com > Fixes: 799aa7f98d53 ("skmsg: Avoid lock_sock() in sk_psock_backlog()") > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- > net/core/sock_map

RE: [Patch bpf-next] skmsg: pass psock pointer to ->psock_update_sk_prot()

> Reported-and-tested-by: syzbot+320a3bc8d80f478c3...@syzkaller.appspotmail.com > Fixes: 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()") > Cc: John Fastabend > Cc: Eric Dumazet > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Baue

Re: [PATCHv4 bpf-next 2/4] xdp: extend xdp_redirect_map with broadcast support

Toke Høiland-Jørgensen wrote: > John Fastabend writes: > > > Toke Høiland-Jørgensen wrote: > >> John Fastabend writes: > >> > >> > Toke Høiland-Jørgensen wrote: > >> >> Hangbin Liu writes: > >> >> > >> >&g

Re: [PATCHv4 bpf-next 2/4] xdp: extend xdp_redirect_map with broadcast support

Toke Høiland-Jørgensen wrote: > John Fastabend writes: > > > Toke Høiland-Jørgensen wrote: > >> Hangbin Liu writes: > >> > >> > On Mon, Apr 05, 2021 at 05:24:48PM -0700, John Fastabend wrote: > >> >> Hangbin Liu wrot

Re: [PATCHv4 bpf-next 2/4] xdp: extend xdp_redirect_map with broadcast support

Toke Høiland-Jørgensen wrote: > Hangbin Liu writes: > > > On Mon, Apr 05, 2021 at 05:24:48PM -0700, John Fastabend wrote: > >> Hangbin Liu wrote: > >> > This patch add two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_INGRESS to > >> > extend

Re: [Patch bpf-next v8 10/16] sock: introduce sk->sk_prot->psock_update_sk_prot()

Cong Wang wrote: > On Mon, Apr 5, 2021 at 1:25 AM Eric Dumazet wrote: > > > > > > > > On 3/31/21 4:32 AM, Cong Wang wrote: > > > From: Cong Wang > > > > > > Currently sockmap calls into each protocol to update the struct > > > proto and replace it. This certainly won't work when the protocol > >

RE: [syzbot] WARNING: suspicious RCU usage in tcp_bpf_update_proto

syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:514e1150 net: x25: Queue received packets in the drivers i.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=112a8831d0 > kernel config: https://syzkaller.appspot.com/x/

Re: [Patch bpf-next v8 10/16] sock: introduce sk->sk_prot->psock_update_sk_prot()

Eric Dumazet wrote: > > > On 3/31/21 4:32 AM, Cong Wang wrote: > > From: Cong Wang > > > > Currently sockmap calls into each protocol to update the struct > > proto and replace it. This certainly won't work when the protocol > > is implemented as a module, for example, AF_UNIX. > > > > Introdu

RE: [PATCH bpf-next 2/3] libbpf: selftests: refactor 'BPF_PERCPU_TYPE()' and 'bpf_percpu()' macros

Pedro Tammela wrote: > This macro was refactored out of the bpf selftests. > > Since percpu values are rounded up to '8' in the kernel, a careless > user in userspace might encounter unexpected values when parsing the > output of the batched operations. > > Now that both array and hash maps have

RE: [PATCH bpf-next 1/3] bpf: add batched ops support for percpu array

Pedro Tammela wrote: > Suggested-by: Jamal Hadi Salim > Signed-off-by: Pedro Tammela > --- A commit message describing some of the change details and a note it uses the for-each cpu copies (same as normal syscall on percpu map) and not the per-cpu ones would be nice. I at least had to go and che

RE: [PATCHv4 bpf-next 2/4] xdp: extend xdp_redirect_map with broadcast support

Hangbin Liu wrote: > This patch add two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_INGRESS to extend > xdp_redirect_map for broadcast support. > > Keep the general data path in net/core/filter.c and the native data > path in kernel/bpf/devmap.c so we can use direct calls to get better > performace. >

RE: [Patch bpf-next] udp_bpf: remove some pointless comments

Cong Wang wrote: > From: Cong Wang > > These comments in udp_bpf_update_proto() are copied from the > original TCP code and apparently do not apply to UDP. Just > remove them. > > Reported-by: Jakub Sitnicki > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Loren

[PATCH bpf v2 2/2] bpf, sockmap: fix incorrect fwd_alloc accounting

s memory will be claimed on psock_other. Reported-by: Andrii Nakryiko Fixes: 6fa9201a89898 ("bpf, sockmap: Avoid returning unneeded EAGAIN when redirecting to self") Signed-off-by: John Fastabend --- net/core/skmsg.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-)

[PATCH bpf v2 1/2] bpf, sockmap: fix sk->prot unhash op reset

to the saved unhash() handler. Fixes: 4da6a196f93b1 ("bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop") Reported-by: Cong Wang Reported-by: Lorenz Bauer Suggested-by: Cong Wang Signed-off-by: John Fastabend --- include/linux/skmsg.h |7 ++- 1 file changed, 6 insertion

[PATCH bpf v2 0/2] bpf, sockmap fixes

with usual suspects: test_sockmap, test_maps, test_progs and test_progs-no_alu32. v2: drop skb_orphan its not necessary and use sk directly instead of using psock->sk both suggested by Cong --- John Fastabend (2): bpf, sockmap: fix sk->prot unhash op reset bpf, sockma

RE: [Patch bpf-next v8 12/16] skmsg: extract __tcp_bpf_recvmsg() and tcp_bpf_wait_data()

> skmsg.c and export them to modules. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang Acked-by: John Fastabend

RE: [Patch bpf-next v8 00/16] sockmap: introduce BPF_SK_SKB_VERDICT and support UDP

Cong Wang wrote: > From: Cong Wang > > We have thousands of services connected to a daemon on every host > via AF_UNIX dgram sockets, after they are moved into VM, we have to > add a proxy to forward these communications from VM to host, because > rewriting thousands of them is not practical. Thi

RE: [Patch bpf-next v8 13/16] udp: implement udp_bpf_recvmsg() for sockmap

Cong Wang wrote: > From: Cong Wang > > We have to implement udp_bpf_recvmsg() to replace the ->recvmsg() > to retrieve skmsg from ingress_msg. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang Acked-by: John Fastabend

RE: [Patch bpf-next v8 14/16] sock_map: update sock type checks for UDP

Cong Wang wrote: > From: Cong Wang > > Now UDP supports sockmap and redirection, we can safely update > the sock type checks for it accordingly. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang &g

RE: [Patch bpf-next v8 11/16] udp: implement ->read_sock() for sockmap

y(), and UDP still does not > support splice() due to lack of ->splice_read(), so users > can not reach udp_read_sock() directly. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- Thanks t

RE: [Patch bpf-next v8 09/16] sock_map: introduce BPF_SK_SKB_VERDICT

skb_verdict. Users are not > allowed to attach stream_verdict and skb_verdict programs to the > same map. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- Looks good. Acked-by: John Fastabend

RE: [Patch bpf-next v8 07/16] sock_map: simplify sock_map_link() a bit

ock_map_link_no_progs() too. > > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Cc: John Fastabend > Signed-off-by: Cong Wang > --- Acked-by: John Fastabend

RE: [Patch bpf-next v8 01/16] skmsg: lock ingress_skb when purging

Cong Wang wrote: > From: Cong Wang > > Currently we purge the ingress_skb queue only when psock > refcnt goes down to 0, so locking the queue is not necessary, > but in order to be called during ->close, we have to lock it > here. > > Cc: John Fastabend > Cc:

Re: [Patch bpf-next v7 09/13] udp: implement ->read_sock() for sockmap

Cong Wang wrote: > On Mon, Mar 29, 2021 at 11:23 PM John Fastabend > wrote: > > > > Cong Wang wrote: > > > On Mon, Mar 29, 2021 at 1:54 PM John Fastabend > > > wrote: > > > > > > > > Cong Wang wrote: > > > > > From: Cong

Re: [Patch bpf-next v7 09/13] udp: implement ->read_sock() for sockmap

Cong Wang wrote: > On Mon, Mar 29, 2021 at 1:54 PM John Fastabend > wrote: > > > > Cong Wang wrote: > > > From: Cong Wang > > > > > > This is similar to tcp_read_sock(), except we do not need > > > to worry about connections, we

RE: [Patch bpf-next v7 12/13] sock_map: update sock type checks for UDP

Cong Wang wrote: > From: Cong Wang > > Now UDP supports sockmap and redirection, we can safely update > the sock type checks for it accordingly. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang &g

RE: [Patch bpf-next v7 09/13] udp: implement ->read_sock() for sockmap

Cong Wang wrote: > From: Cong Wang > > This is similar to tcp_read_sock(), except we do not need > to worry about connections, we just need to retrieve skb > from UDP receive queue. > > Note, the return value of ->read_sock() is unused in > sk_psock_verdict_data_ready

RE: [Patch bpf-next v7 07/13] sock_map: introduce BPF_SK_SKB_VERDICT

skb_verdict. Users are not > allowed to set stream_verdict and skb_verdict at the same time. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- [...] > diff --git a/net/core/skmsg.c b/net/core/skms

RE: [Patch bpf-next v7 06/13] skmsg: use GFP_KERNEL in sk_psock_create_ingress_msg()

Cong Wang wrote: > From: Cong Wang > > This function is only called in process context. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- > net/core/skmsg.c | 2 +- > 1 file

RE: [Patch bpf-next v7 05/13] skmsg: use rcu work for destroying psock

Cong Wang wrote: > From: Cong Wang > > The RCU callback sk_psock_destroy() only queues work psock->gc, > so we can just switch to rcu work to simplify the code. > > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Acked-by: John Fastabend > Sign

RE: [Patch bpf-next v7 04/13] skmsg: avoid lock_sock() in sk_psock_backlog()

gt; As noticed by John, we still have to lock the psock->work, > because the same work item could be running concurrently on > different CPU's. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- Acked-by: John Fastabend

RE: [Patch bpf-next v7 02/13] skmsg: introduce a spinlock to protect ingress_msg

> it still has to use lock_sock. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Lorenz Bauer > Acked-by: Jakub Sitnicki > Signed-off-by: Cong Wang > --- Acked-by: John Fastabend

Re: [Patch bpf-next v7 00/13] sockmap: introduce BPF_SK_SKB_VERDICT and support UDP

Alexei Starovoitov wrote: > On Sun, Mar 28, 2021 at 01:20:00PM -0700, Cong Wang wrote: > > From: Cong Wang > > > > We have thousands of services connected to a daemon on every host > > via AF_UNIX dgram sockets, after they are moved into VM, we have to > > add a proxy to forward these communicati

RE: [Patch bpf-next v6 05/12] skmsg: use rcu work for destroying psock

Cong Wang wrote: > From: Cong Wang > > The RCU callback sk_psock_destroy() only queues work psock->gc, > so we can just switch to rcu work to simplify the code. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-o

RE: [Patch bpf-next v6 04/12] skmsg: avoid lock_sock() in sk_psock_backlog()

queues when psock refcnt reaches zero but > here we want to purge them explicitly in sock_map_close(). > There are also some nasty race conditions on testing bit > SK_PSOCK_TX_ENABLED and queuing/canceling the psock work, > we can expand psock->ingress_lock a bit to protect them too. > &

Re: [bpf PATCH 2/2] bpf, sockmap: fix incorrect fwd_alloc accounting

Cong Wang wrote: > On Wed, Mar 24, 2021 at 7:46 PM John Fastabend > wrote: > > > > Cong Wang wrote: > > > On Wed, Mar 24, 2021 at 2:00 PM John Fastabend > > > wrote: > > > > > > > > Incorrect accounting fwd_alloc

Re: [bpf PATCH 1/2] bpf, sockmap: fix sk->prot unhash op reset

Cong Wang wrote: > On Wed, Mar 24, 2021 at 7:28 PM John Fastabend > wrote: > > > > Cong Wang wrote: > > > On Wed, Mar 24, 2021 at 1:59 PM John Fastabend > > > wrote: > > > > diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c > > > &g

Re: [bpf PATCH] bpf, selftests: test_maps generating unrecognized data section

Daniel Borkmann wrote: > On 3/24/21 10:07 PM, John Fastabend wrote: > > With a relatively recent clang master branch test_map skips a section, > > > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > > > the cause is some pointless st

Re: [bpf PATCH 2/2] bpf, sockmap: fix incorrect fwd_alloc accounting

Cong Wang wrote: > On Wed, Mar 24, 2021 at 2:00 PM John Fastabend > wrote: > > > > Incorrect accounting fwd_alloc can result in a warning when the socket > > is torn down, > > [...] > > To resolve lets only account for sockets on the ingress queue that are &

Re: [bpf PATCH 1/2] bpf, sockmap: fix sk->prot unhash op reset

Cong Wang wrote: > On Wed, Mar 24, 2021 at 1:59 PM John Fastabend > wrote: > > diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c > > index 47b7c5334c34..ecb5634b4c4a 100644 > > --- a/net/tls/tls_main.c > > +++ b/net/tls/tls_main.c > > @@ -754,6 +754,12 @

[bpf PATCH] bpf, selftests: test_maps generating unrecognized data section

: John Fastabend --- .../selftests/bpf/progs/sockmap_tcp_msg_prog.c |3 --- 1 file changed, 3 deletions(-) diff --git a/tools/testing/selftests/bpf/progs/sockmap_tcp_msg_prog.c b/tools/testing/selftests/bpf/progs/sockmap_tcp_msg_prog.c index fdb4bf4408fa..0f603253f4ed 100644 --- a/tools

[bpf PATCH] small test_maps fix

Small fix to silence a warning running ./test_maps on my local test boxes. Pushed to 'bpf' but can also apply against 'bpf-next' if folks would prefer. Thanks. --- John Fastabend (1): bpf, selftests: test_maps generating unrecognized data section ...

[bpf PATCH 2/2] bpf, sockmap: fix incorrect fwd_alloc accounting

s memory will be claimed on psock_other. Reported-by: Andrii Nakryiko Fixes: 6fa9201a89898 ("bpf, sockmap: Avoid returning unneeded EAGAIN when redirecting to self") Signed-off-by: John Fastabend --- net/core/skmsg.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-)

[bpf PATCH 1/2] bpf, sockmap: fix sk->prot unhash op reset

l point to the saved unhash() handler. Fixes: 4da6a196f93b1 ("bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop") Reported-by: Cong Wang Reported-by: Lorenz Bauer Signed-off-by: John Fastabend --- include/linux/skmsg.h |1 - net/tls/tls_main.c|6 +

[bpf PATCH 0/2] bpf, sockmap fixes

test_progs and test_progs-no_alu32. --- John Fastabend (2): bpf, sockmap: fix sk->prot unhash op reset bpf, sockmap: fix incorrect fwd_alloc accounting include/linux/skmsg.h |1 - net/core/skmsg.c | 13 ++--- net/tls/tls_main.c|6 ++ 3 file

RE: [Patch bpf-next v5 04/11] skmsg: avoid lock_sock() in sk_psock_backlog()

queues when psock refcnt reaches zero but > here we want to purge them explicitly in sock_map_close(). > There are also some nasty race conditions on testing bit > SK_PSOCK_TX_ENABLED and queuing/canceling the psock work, > we can expand psock->ingress_lock a bit to protect them too. > &

Re: [Patch bpf-next v2 2/9] sock: introduce sk_prot->update_proto()

Cong Wang wrote: > On Fri, Mar 5, 2021 at 5:55 PM John Fastabend > wrote: > > [...] > > > // tcp_bpf_prots->unhash == sock_map_unhash > > > sk_psock_restore_proto(); > > > // Now tcp_bpf_prots->unhash is inet_unhash > > > ... >

Re: [Patch bpf-next v3 3/9] udp: implement ->sendmsg_locked()

Cong Wang wrote: > On Fri, Mar 5, 2021 at 5:21 PM John Fastabend > wrote: > > > > Cong Wang wrote: > > > From: Cong Wang > > > > > > UDP already has udp_sendmsg() which takes lock_sock() inside. > > > We have to build ->sendmsg_locked()

Re: [Patch bpf-next v2 2/9] sock: introduce sk_prot->update_proto()

Cong Wang wrote: > On Fri, Mar 5, 2021 at 4:27 PM John Fastabend > wrote: > > > > Cong Wang wrote: > > > On Tue, Mar 2, 2021 at 10:23 AM Cong Wang > > > wrote: > > > > > > > > On Tue, Mar 2, 2021 at 8:22 AM Lorenz Bauer wrote

RE: [Patch bpf-next v3 3/9] udp: implement ->sendmsg_locked()

Cong Wang wrote: > From: Cong Wang > > UDP already has udp_sendmsg() which takes lock_sock() inside. > We have to build ->sendmsg_locked() on top of it, by adding > a new parameter for whether the sock has been locked. > > Cc: John Fastabend > Cc: Daniel Borkmann

Re: [Patch bpf-next v2 2/9] sock: introduce sk_prot->update_proto()

, it is completely unrelated to my patch, as the current code has > > the same problem. > > Looking at this again. I noticed > > commit 4da6a196f93b1af7612340e8c1ad8ce71e18f955 > Author: John Fastabend > Date: Sat Jan 11 06:11:59 2020 + > > bpf: Sockmap/tls, duri

RE: [Patch bpf-next] skmsg: add function doc for skb->_sk_redir

Cong Wang wrote: > From: Cong Wang > > This should fix the following warning: > > include/linux/skbuff.h:932: warning: Function parameter or member > '_sk_redir' not described in 'sk_buff' > > Reported-by: Lorenz Bauer > Cc: Daniel Borkm

Re: [PATCH net] net: Fix gro aggregation for udp encaps with zero csum

|| > > Basically matches > > - CHECKSUM_NONE > - CHECKSUM_UNNECESSARY which has already used up its valid state on a > prior header > - CHECKSUM_COMPLETE with bad checksum. > > This change just refines to not drop for in the first two cases on a > zero checksum field. +1 > > Making this explicit in case anyone sees holes in the logic. Else, > > Acked-by: Willem de Bruijn LGTM, Acked-by: John Fastabend

RE: [PATCH v7 bpf-next 0/6] xsk: build skb by page (aka generic zerocopy xmit)

47 1775988 1600203 1440054 > page1974058 1953655 1945463 1904478 > percent 3.0%10.0% 21.58% 32.3% > For the series, but might be good to get Dave or Jakub to check 2/6 to be sure they agree. Acked-by: John Fastabend

Re: RE: [PATCH v7 bpf-next 6/6] xsk: build skb by page (aka generic zerocopy xmit)

Xuan Zhuo wrote: > On Wed, 17 Feb 2021 16:46:04 -0800, John Fastabend > wrote: > > Alexander Lobakin wrote: > > > From: Xuan Zhuo > > > > > > This patch is used to construct skb based on page to save memory copy > > > overhead. &

RE: [PATCH v7 bpf-next 6/6] xsk: build skb by page (aka generic zerocopy xmit)

Alexander Lobakin wrote: > From: Xuan Zhuo > > This patch is used to construct skb based on page to save memory copy > overhead. > > This function is implemented based on IFF_TX_SKB_NO_LINEAR. Only the > network card priv_flags supports IFF_TX_SKB_NO_LINEAR will use page to > directly construct

RE: [Patch bpf-next] bpf: clear per_cpu pointers in bpf_prog_clone_create()

6ef59 ("bpf: Optimize program stats") > Fixes: ca06f55b9002 ("bpf: Add per-program recursion prevention mechanism") > Cc: Alexei Starovoitov > Signed-off-by: Cong Wang > --- Acked-by: John Fastabend

RE: [PATCH bpf-next V1 2/2] selftests/bpf: Tests using bpf_check_mtu BPF-helper input mtu_len param

esper Dangaard Brouer > --- LGTM. Acked-by: John Fastabend

RE: [PATCH bpf-next V1 1/2] bpf: BPF-helper for MTU checking add length input

specify the L3 length that the MTU check > + * is done against. Remeber XDP and TC length operate at L2, but ^^^ typo, Remember Acked-by: John Fastabend

Re: [Patch bpf-next v4 4/5] skmsg: move sk_redir from TCP_SKB_CB to skb

Cong Wang wrote: > On Wed, Feb 17, 2021 at 10:40 AM John Fastabend > wrote: > > > @@ -802,9 +809,10 @@ int sk_psock_tls_strp_read(struct sk_psock *psock, > > > struct sk_buff *skb) > > >* TLS context. > > >

RE: [PATCH bpf-next 0/8] PROG_TEST_RUN support for sk_lookup programs

2) > > Please let me know what your preference is. Seems reasonable to me. For the series, Acked-by: John Fastabend

Re: [Patch bpf-next v3 4/5] skmsg: use skb ext instead of TCP_SKB_CB

Lorenz Bauer wrote: > On Mon, 15 Feb 2021 at 19:20, John Fastabend wrote: > > > > Cong Wang wrote: > > > From: Cong Wang > > > > > > Currently TCP_SKB_CB() is hard-coded in skmsg code, it certainly > > > does not work for any other non-TCP prot

RE: [Patch bpf-next v4 4/5] skmsg: move sk_redir from TCP_SKB_CB to skb

o longer needed after ->sk_data_ready() so we can just drop it. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- Great, its likely we have more space in sk_buff we can use if needed as well. queue_m

Re: [PATCH bpf-next 1/3] libbpf: xsk: use bpf_link

Maciej Fijalkowski wrote: > On Tue, Feb 16, 2021 at 11:15:41AM -0800, John Fastabend wrote: > > Toke Høiland-Jørgensen wrote: > > > Björn Töpel writes: > > > > > > > On 2021-02-15 21:49, John Fastabend wrote: > > > >> Maciej Fijalkowski wro

Re: [PATCH bpf-next 1/3] libbpf: xsk: use bpf_link

Toke Høiland-Jørgensen wrote: > Björn Töpel writes: > > > On 2021-02-15 21:49, John Fastabend wrote: > >> Maciej Fijalkowski wrote: > >>> Currently, if there are multiple xdpsock instances running on a single > >>> interface and in case one of the in

Re: [PATCH bpf-next 1/3] libbpf: xsk: use bpf_link

Maciej Fijalkowski wrote: > On Mon, Feb 15, 2021 at 12:49:27PM -0800, John Fastabend wrote: > > Maciej Fijalkowski wrote: > > > Currently, if there are multiple xdpsock instances running on a single > > > interface and in case one of the instances is terminated, the res

Re: [Patch bpf-next v3 4/5] skmsg: use skb ext instead of TCP_SKB_CB

Cong Wang wrote: > On Mon, Feb 15, 2021 at 4:54 PM John Fastabend > wrote: > > > > Cong Wang wrote: > > > On Mon, Feb 15, 2021 at 3:57 PM John Fastabend > > > wrote: > > > > > > > > For TCP case we can continue to use CB and not pa

Re: [Patch bpf-next v3 4/5] skmsg: use skb ext instead of TCP_SKB_CB

Cong Wang wrote: > On Mon, Feb 15, 2021 at 3:57 PM John Fastabend > wrote: > > > > For TCP case we can continue to use CB and not pay the price. For UDP > > and AF_UNIX we can do the extra alloc. > > I see your point, but specializing TCP case does not give much

Re: [PATCH bpf-next 1/3] libbpf: xsk: use bpf_link

Toke Høiland-Jørgensen wrote: > John Fastabend writes: > > >> > However, in libxdp we can solve the original problem in a different way, > >> > and in fact I already suggested to Magnus that we should do this (see > >> > [1]); so one way forward

Re: [Patch bpf-next v3 4/5] skmsg: use skb ext instead of TCP_SKB_CB

Cong Wang wrote: > On Mon, Feb 15, 2021 at 11:20 AM John Fastabend > wrote: > > > > Cong Wang wrote: > > > From: Cong Wang > > > > > > Currently TCP_SKB_CB() is hard-coded in skmsg code, it certainly > > > does not work for any other non-TC

RE: [PATCH bpf-next 1/3] libbpf: xsk: use bpf_link

Maciej Fijalkowski wrote: > Currently, if there are multiple xdpsock instances running on a single > interface and in case one of the instances is terminated, the rest of > them are left in an inoperable state due to the fact of unloaded XDP > prog from interface. > > To address that, step away fr

RE: [PATCH bpf-next 2/3] libbpf: clear map_info before each bpf_obj_get_info_by_fd

Maciej Fijalkowski wrote: > xsk_lookup_bpf_maps, based on prog_fd, looks whether current prog has a > reference to XSKMAP. BPF prog can include insns that work on various BPF > maps and this is covered by iterating through map_ids. > > The bpf_map_info that is passed to bpf_obj_get_info_by_fd for

RE: [PATCH bpf-next 3/3] samples: bpf: do not unload prog within xdpsock

Maciej Fijalkowski wrote: > With the introduction of bpf_link in xsk's libbpf part, there's no > further need for explicit unload of prog on xdpsock's termination. When > process dies, the bpf_link's refcount will be decremented and resources > will be unloaded/freed under the hood in case when the

Re: [PATCH bpf-next 1/3] libbpf: xsk: use bpf_link

Björn Töpel wrote: > On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote: > > Maciej Fijalkowski writes: > > > >> Currently, if there are multiple xdpsock instances running on a single > >> interface and in case one of the instances is terminated, the rest of > >> them are left in an inoperable sta

RE: [Patch bpf-next v3 4/5] skmsg: use skb ext instead of TCP_SKB_CB

Cong Wang wrote: > From: Cong Wang > > Currently TCP_SKB_CB() is hard-coded in skmsg code, it certainly > does not work for any other non-TCP protocols. We can move them to > skb ext instead of playing with skb cb, which is harder to make > correct. > > Cc: John Fastaben

RE: [Patch bpf-next v3 5/5] sock_map: rename skb_parser and skb_verdict

Cong Wang wrote: > From: Cong Wang > > These two eBPF programs are tied to BPF_SK_SKB_STREAM_PARSER > and BPF_SK_SKB_STREAM_VERDICT, rename them to reflect the fact > they are only used for TCP. And save the name 'skb_verdict' for > general use later. > >

RE: [Patch bpf-next v3 3/5] bpf: compute data_end dynamically with JIT code

imilar to skb_shinfo(skb) computation > in bpf_convert_shinfo_access(). > > Suggested-by: Jakub Sitnicki > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- Acked-by: John Fastabend

RE: [Patch bpf-next v3 2/5] skmsg: get rid of struct sk_psock_parser

Cong Wang wrote: > From: Cong Wang > > struct sk_psock_parser is embedded in sk_psock, it is > unnecessary as skb verdict also uses ->saved_data_ready. > We can simply fold these fields into sk_psock, and get rid > of ->enabled. > > Cc: John Fastabend >

RE: [Patch bpf-next v3 1/5] bpf: clean up sockmap related Kconfigs

d leave CONFIG_NET_SOCK_MSG untouched, as it is used by > non-sockmap cases. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- Thanks for doing this. Acked-by: John Fastabend

Re: [Patch bpf-next 01/19] bpf: rename BPF_STREAM_PARSER to BPF_SOCK_MAP

Cong Wang wrote: > On Mon, Feb 8, 2021 at 12:21 AM John Fastabend > wrote: > > > > Cong Wang wrote: > > > From: Cong Wang > > > > > > Before we add non-TCP support, it is necessary to rename > > > BPF_STREAM_PARSER as it will be no long

Re: [Patch bpf-next 02/19] skmsg: get rid of struct sk_psock_parser

Jakub Sitnicki wrote: > On Wed, Feb 03, 2021 at 05:16 AM CET, Cong Wang wrote: > > From: Cong Wang > > > > struct sk_psock_parser is embedded in sk_psock, it is > > unnecessary as skb verdict also uses ->saved_data_ready. > > We can simply fold these fi

RE: [Patch bpf-next 05/19] sock_map: introduce BPF_SK_SKB_VERDICT

a new type of eBPF program, skb_verdict. > Users are not allowed to set stream_verdict and skb_verdict at the > same time. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang I think it will be better if we

RE: [Patch bpf-next 04/19] sock_map: rename skb_parser and skb_verdict

Cong Wang wrote: > From: Cong Wang > > These two ebpf programs are tied to BPF_SK_SKB_STREAM_PARSER > and BPF_SK_SKB_STREAM_VERDICT, rename them to reflect the fact > they are currently used for TCP. And save the generic name > skb_verdict for general use. > > Cc: John

RE: [Patch bpf-next 01/19] bpf: rename BPF_STREAM_PARSER to BPF_SOCK_MAP

hat sock_map.c hopefully would be protocol-independent. > > Also, improve its Kconfig description to avoid confusion. > > Cc: John Fastabend > Cc: Daniel Borkmann > Cc: Jakub Sitnicki > Cc: Lorenz Bauer > Signed-off-by: Cong Wang > --- The BPF_STREAM_PARSER config was

Re: [PATCHv17 bpf-next 0/6] xdp: add a new helper for dev map multicast support

Hangbin Liu wrote: > Hi Daniel, Alexei, > > It has been one week after Maciej, Toke, John's review/ack. What should > I do to make a progress for this patch set? > Patchwork is usually the first place to check: https://patchwork.kernel.org/project/netdevbpf/list/?series=421095&state=* Looks l

RE: [PATCH bpf-next] libbpf: stop using feature-detection Makefiles

tools/lib/bpf/Makefile | 47 > 2 files changed, 4 insertions(+), 44 deletions(-) I've also hit these annoying cases at least once or twice. Acked-by: John Fastabend

Re: [Patch bpf-next 00/19] sock_map: add non-TCP and cross-protocol support

Cong Wang wrote: > On Wed, Feb 3, 2021 at 9:48 AM Alexei Starovoitov > wrote: > > > > On Tue, Feb 02, 2021 at 08:16:17PM -0800, Cong Wang wrote: > > > From: Cong Wang > > > > > > Currently sockmap only fully supports TCP, UDP is partially supported > > > as it is only allowed to add into sockmap.

RE: [PATCH bpf-next V13 6/7] selftests/bpf: use bpf_check_mtu in selftest test_cls_redirect

; ./test_progs -t cls_redirect > > Signed-off-by: Jesper Dangaard Brouer > --- Acked-by: John Fastabend

RE: [PATCH bpf-next V13 5/7] bpf: drop MTU check when doing TC-BPF redirect to ingress

ce "up" (IFF_UP) check. > - Adjustment to handle bpf_redirect_peer() helper > > Signed-off-by: Jesper Dangaard Brouer > --- LGTM. Acked-by: John Fastabend

RE: [PATCH bpf-next V13 4/7] bpf: add BPF-helper for MTU checking

Jesper Dangaard Brouer wrote: > This BPF-helper bpf_check_mtu() works for both XDP and TC-BPF programs. > > The SKB object is complex and the skb->len value (accessible from > BPF-prog) also include the length of any extra GRO/GSO segments, but > without taking into account that these GRO/GSO segm

RE: [PATCH bpf-next V13 3/7] bpf: bpf_fib_lookup return MTU value as output when looked up

t; > V5: > - Fixed uninit value spotted by Dan Carpenter. > - Name struct output member mtu_result > > Reported-by: kernel test robot > Reported-by: Dan Carpenter > Signed-off-by: Jesper Dangaard Brouer > --- LGTM. Acked-by: John Fastabend

RE: [PATCH bpf-next V13 2/7] bpf: fix bpf_fib_lookup helper MTU check for SKB ctx

se same method as XDP for 'tot_len' MTU check > > Fixes: 4c79579b44b1 ("bpf: Change bpf_fib_lookup to return lookup status") > Reported-by: Carlo Carraro > Signed-off-by: Jesper Dangaard Brouer > --- Acked-by: John Fastabend

RE: [PATCHv17 bpf-next 6/6] selftests/bpf: add xdp_redirect_multi test

if (data + nh_off > data_end) > + return XDP_DROP; > + > + mac = bpf_map_lookup_elem(&mac_map, &key); > + if (mac) > + __builtin_memcpy(eth->h_source, mac, ETH_ALEN); > + > + return XDP_PASS; > +} Might be nice to a

Re: [PATCHv17 bpf-next 5/6] selftests/bpf: Add verifier tests for bpf arg ARG_CONST_MAP_PTR_OR_NULL

Hangbin Liu wrote: > On Wed, Jan 27, 2021 at 02:24:47PM -0800, John Fastabend wrote: > > [...] > > > > > +{ > > > + "ARG_CONST_MAP_PTR_OR_NULL: null pointer for ex_map", > > > + .insns = { > > > + BPF_MOV64_IMM(BPF_REG_

RE: [PATCHv17 bpf-next 5/6] selftests/bpf: Add verifier tests for bpf arg ARG_CONST_MAP_PTR_OR_NULL

Hangbin Liu wrote: > Use helper bpf_redirect_map() and bpf_redirect_map_multi() to test bpf > arg ARG_CONST_MAP_PTR and ARG_CONST_MAP_PTR_OR_NULL. Make sure the > map arg could be verified correctly when it is NULL or valid map > pointer. > > Add devmap and devmap_hash in struct bpf_test due to bp

RE: [PATCHv16 bpf-next 3/6] xdp: add a new helper for dev map multicast support

he > new helper to make a difference with bpf_xdp_redirect_map(). > > Also I keep the general data path in net/core/filter.c, the native data > path in kernel/bpf/devmap.c so we can use direct calls to get better > performace. > > [0] https://xdp-project.net/#Handling-multicast > > Signed-off-by: Hangbin Liu > Thanks for the updates. Acked-by: John Fastabend

RE: [PATCHv17 bpf-next 2/6] bpf: add a new bpf argument type ARG_CONST_MAP_PTR_OR_NULL

rnel.org/bpf/20200715070001.2048207-1-liuhang...@gmail.com/ > --- LGTM Acked-by: John Fastabend

  1   2   3   4   5   6   7   8   9   10   >