[Patch bpf-next v7 7/9] skmsg: make __sk_psock_purge_ingress_msg() static

From: Cong Wang It is only used within skmsg.c so can become static. Cc: Daniel Borkmann Cc: Lorenz Bauer Cc: John Fastabend Acked-by: Jakub Sitnicki Signed-off-by: Cong Wang --- include/linux/skmsg.h | 2 -- net/core/skmsg.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions

[Patch bpf-next v7 3/9] bpf: compute data_end dynamically with JIT code

From: Cong Wang Currently, we compute ->data_end with a compile-time constant offset of skb. But as Jakub pointed out, we can actually compute it in eBPF JIT code at run-time, so that we can competely get rid of ->data_end. This is similar to skb_shinfo(skb) computat

[Patch bpf-next v7 2/9] skmsg: get rid of struct sk_psock_parser

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: Daniel Borkmann Cc: Lorenz Bauer Acked-by: John Fastabend Acked-by: Jakub Si

[Patch bpf-next v7 0/9] sock_map: clean up and refactor code for BPF_SK_SKB_VERDICT

From: Cong Wang This patchset is the first series of patches separated out from the original large patchset, to make reviews easier. This patchset does not add any new feature or change any functionality but merely cleans up the existing sockmap and skmsg code and refactors it, to prepare for

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

On Tue, Feb 23, 2021 at 9:53 AM Jakub Sitnicki wrote: > Based on what I've seen around, mask for sanitizing tagged pointers is > usually derived from the flag(s). For instance: > > #define SKB_DST_NOREF 1UL > #define SKB_DST_PTRMASK ~(SKB_DST_NOREF) > > #define SK_USER_DATA_NOCOPY 1UL > #def

Re: [Patch bpf-next v6 1/8] bpf: clean up sockmap related Kconfigs

On Mon, Feb 22, 2021 at 12:52 AM Jakub Sitnicki wrote: > > On Sat, Feb 20, 2021 at 06:29 AM CET, Cong Wang wrote: > > From: Cong Wang > > > > As suggested by John, clean up sockmap related Kconfigs: > > > > Reduce the scope of CONFIG_BPF_STREAM_PARSER down

Re: [Patch bpf-next v6 5/8] sock_map: rename skb_parser and skb_verdict

On Mon, Feb 22, 2021 at 4:28 AM Jakub Sitnicki wrote: > > skb_parser also appears in: > > tools/testing/selftests/bpf/test_sockmap.c:int txmsg_omit_skb_parser; > tools/testing/selftests/bpf/test_sockmap.c: {"txmsg_omit_skb_parser", > no_argument, &txmsg_omit_skb_parser, 1}, > tools/testi

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

On Mon, Feb 22, 2021 at 4:20 AM Jakub Sitnicki wrote: > > On Sat, Feb 20, 2021 at 06:29 AM CET, 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 mo

[Patch bpf-next v6 1/8] bpf: clean up sockmap related Kconfigs

From: Cong Wang As suggested by John, clean up sockmap related Kconfigs: Reduce the scope of CONFIG_BPF_STREAM_PARSER down to TCP stream parser, to reflect its name. Make the rest sockmap code simply depend on CONFIG_BPF_SYSCALL and CONFIG_INET, the latter is still needed at this point because

[Patch bpf-next v6 8/8] skmsg: get rid of sk_psock_bpf_run()

From: Cong Wang It is now nearly identical to bpf_prog_run_pin_on_cpu() and it has an unused parameter 'psock', so we can just get rid of it and call bpf_prog_run_pin_on_cpu() directly. Cc: Jakub Sitnicki Cc: Daniel Borkmann Cc: Lorenz Bauer Cc: John Fastabend Signed-off-by:

[Patch bpf-next v6 6/8] sock_map: make sock_map_prog_update() static

From: Cong Wang It is only used within sock_map.c so can become static. Suggested-by: Jakub Sitnicki Cc: Daniel Borkmann Cc: Lorenz Bauer Cc: John Fastabend Signed-off-by: Cong Wang --- include/linux/bpf.h | 9 - net/core/sock_map.c | 7 +-- 2 files changed, 5 insertions

[Patch bpf-next v6 5/8] sock_map: rename skb_parser and skb_verdict

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. Cc: Daniel Borkmann Cc: Jakub Sitnicki Reviewed-by: Lo

[Patch bpf-next v6 2/8] skmsg: get rid of struct sk_psock_parser

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: Daniel Borkmann Cc: Lorenz Bauer Acked-by: John Fastabend Acked-by: Jakub Si

[Patch bpf-next v6 3/8] bpf: compute data_end dynamically with JIT code

From: Cong Wang Currently, we compute ->data_end with a compile-time constant offset of skb. But as Jakub pointed out, we can actually compute it in eBPF JIT code at run-time, so that we can competely get rid of ->data_end. This is similar to skb_shinfo(skb) computat

[Patch bpf-next v6 4/8] skmsg: move sk_redir from TCP_SKB_CB to skb

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, but it introduces a memory allocation on fast path. Fortunately, we only need to a word-size to store all the information, because the

[Patch bpf-next v6 0/8] sock_map: clean up and refactor code for BPF_SK_SKB_VERDICT

From: Cong Wang This patchset is the first series of patches separated out from the original large patchset, to make reviews easier. This patchset does not add any new feature or change any functionality but merely cleans up the existing sockmap and skmsg code and refactors it, to prepare for

[Patch bpf-next v6 7/8] skmsg: make __sk_psock_purge_ingress_msg() static

From: Cong Wang It is only used within skmsg.c so can become static. Cc: Jakub Sitnicki Cc: Daniel Borkmann Cc: Lorenz Bauer Cc: John Fastabend Signed-off-by: Cong Wang --- include/linux/skmsg.h | 2 -- net/core/skmsg.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) diff

[Patch bpf-next v5 1/8] bpf: clean up sockmap related Kconfigs

From: Cong Wang As suggested by John, clean up sockmap related Kconfigs: Reduce the scope of CONFIG_BPF_STREAM_PARSER down to TCP stream parser, to reflect its name. Make the rest sockmap code simply depend on CONFIG_BPF_SYSCALL. And leave CONFIG_NET_SOCK_MSG untouched, as it is used by non

[Patch bpf-next v5 2/8] skmsg: get rid of struct sk_psock_parser

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: Daniel Borkmann Cc: Lorenz Bauer Acked-by: John Fastabend Acked-by: Jakub Si

[Patch bpf-next v5 3/8] bpf: compute data_end dynamically with JIT code

From: Cong Wang Currently, we compute ->data_end with a compile-time constant offset of skb. But as Jakub pointed out, we can actually compute it in eBPF JIT code at run-time, so that we can competely get rid of ->data_end. This is similar to skb_shinfo(skb) computat

[Patch bpf-next v5 0/8] sock_map: clean up and refactor code for BPF_SK_SKB_VERDICT

From: Cong Wang This patchset is the first series of patches separated out from the original large patchset, to make reviews easier. This patchset does not add any new feature or change any functionality but merely cleans up the existing sockmap and skmsg code and refactors it, to prepare for

[Patch bpf-next v5 7/8] skmsg: make __sk_psock_purge_ingress_msg() static

From: Cong Wang It is only used within skmsg.c so can become static. Cc: Jakub Sitnicki Cc: Daniel Borkmann Cc: Lorenz Bauer Cc: John Fastabend Signed-off-by: Cong Wang --- include/linux/skmsg.h | 2 -- net/core/skmsg.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) diff

[Patch bpf-next v5 8/8] skmsg: get rid of sk_psock_bpf_run()

From: Cong Wang It is now nearly identical to bpf_prog_run_pin_on_cpu() and it has an unused parameter 'psock', so we can just get rid of it and call bpf_prog_run_pin_on_cpu() directly. Cc: Jakub Sitnicki Cc: Daniel Borkmann Cc: Lorenz Bauer Cc: John Fastabend Signed-off-by:

[Patch bpf-next v5 5/8] sock_map: rename skb_parser and skb_verdict

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. Cc: Daniel Borkmann Cc: Jakub Sitnicki Reviewed-by: Lo

[Patch bpf-next v5 4/8] skmsg: move sk_redir from TCP_SKB_CB to skb

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, but it introduces a memory allocation on fast path. Fortunately, we only need to a word-size to store all the information, because the

[Patch bpf-next v5 6/8] sock_map: make sock_map_prog_update() static

From: Cong Wang It is only used within sock_map.c so can become static. Suggested-by: Jakub Sitnicki Cc: Daniel Borkmann Cc: Lorenz Bauer Cc: John Fastabend Signed-off-by: Cong Wang --- include/linux/bpf.h | 9 - net/core/sock_map.c | 7 +-- 2 files changed, 5 insertions

Re: [Patch bpf-next v4 1/5] bpf: clean up sockmap related Kconfigs

On Fri, Feb 19, 2021 at 10:25 AM Jakub Sitnicki wrote: > > On Tue, Feb 16, 2021 at 07:42 AM CET, Cong Wang wrote: > > From: Cong Wang > > > > As suggested by John, clean up sockmap related Kconfigs: > > > > Reduce the scope of CONFIG_BPF_STREAM_PARSER down

[Patch bpf-next v2] bpf: clear percpu pointers in bpf_prog_clone_free()

From: Cong Wang Similar to bpf_prog_realloc(), bpf_prog_clone_create() also copies the percpu pointers, but the clone still shares them with the original prog, so we have to clear these two percpu pointers in bpf_prog_clone_free(). Otherwise we would get a double free: BUG: kernel NULL pointer

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

On Wed, Feb 17, 2021 at 2:01 PM Daniel Borkmann wrote: > > On 2/17/21 4:58 AM, Cong Wang wrote: > > From: Cong Wang > > > > Pretty much similar to commit 1336c662474e > > ("bpf: Clear per_cpu pointers during bpf_prog_realloc") we also need t

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

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. > >*/ > > skb->sk = psock->sk; > > - tcp_skb_bpf_redirect_clear(s

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

From: Cong Wang Pretty much similar to commit 1336c662474e ("bpf: Clear per_cpu pointers during bpf_prog_realloc") we also need to clear these two percpu pointers in bpf_prog_clone_create(), otherwise would get a double free: BUG: kernel NULL pointer dereference, address: 000

Re: [bug report] net: fix dev_ifsioc_locked() race condition

On Tue, Feb 16, 2021 at 11:40 AM Dan Carpenter wrote: > > Hello Cong Wang, > > The patch 3b23a32a6321: "net: fix dev_ifsioc_locked() race condition" > from Feb 11, 2021, leads to the following static checker warning: > > drivers/net/tap.c:1095 tap_ioc

Re: [PATCH net] net: sched: fix police ext initialization

and-tested-by: syzbot+151e3e714d34ae4ce...@syzkaller.appspotmail.com Reviewed-by: Cong Wang Thanks.

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

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, but it introduces a memory allocation on fast path. Fortunately, we only need to a word-size to store all the information, because the

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

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. Cc: Daniel Borkmann Cc: Jakub Sitnicki Reviewed-by: Lo

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

From: Cong Wang Currently, we compute ->data_end with a compile-time constant offset of skb. But as Jakub pointed out, we can actually compute it in eBPF JIT code at run-time, so that we can competely get rid of ->data_end. This is similar to skb_shinfo(skb) computat

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

From: Cong Wang As suggested by John, clean up sockmap related Kconfigs: Reduce the scope of CONFIG_BPF_STREAM_PARSER down to TCP stream parser, to reflect its name. Make the rest sockmap code simply depend on CONFIG_BPF_SYSCALL. And leave CONFIG_NET_SOCK_MSG untouched, as it is used by non

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

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: Daniel Borkmann Cc: Lorenz Bauer Acked-by: John Fastabend Acked-by: Jakub Si

[Patch bpf-next v4 0/5] sock_map: clean up and refactor code for BPF_SK_SKB_VERDICT

From: Cong Wang This patchset is the first series of patches separated out from the original large patchset, to make reviews easier. This patchset does not add any new feature or change any functionality but merely cleans up the existing sockmap and skmsg code and refactors it, to prepare for

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

On Mon, Feb 15, 2021 at 5:50 PM John Fastabend wrote: > > 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 > > > > wr

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

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 pay the price. For UDP > > > and AF_UNIX we can do t

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

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 benefit here, the skmsg code would have to check skb->protocol et

Re: KASAN: null-ptr-deref Read in tcf_idrinfo_destroy

On Wed, Feb 10, 2021 at 9:53 PM syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > HEAD commit:291009f6 Merge tag 'pm-5.11-rc8' of git://git.kernel.org/p.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=14470d18d0 > kerne

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

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-TCP protocols. We can move them to > > skb ext inst

Re: [PATCH net-next v2 1/7] mld: convert from timer to delayed work

On Sun, Feb 14, 2021 at 2:56 AM Taehee Yoo wrote: > > > > On 21. 2. 14. 오전 4:07, Cong Wang wrote: > > On Sat, Feb 13, 2021 at 9:51 AM Taehee Yoo wrote: > >> -static void mld_dad_start_timer(struct inet6_dev *idev, unsigned > long delay) > >> +static v

[Patch bpf-next v3 0/5] sock_map: clean up and refactor code for BPF_SK_SKB_VERDICT

From: Cong Wang This patchset is the first series of patches separated out from the original large patchset, to make reviews easier. This patchset does not add any new feature or change any functionality but merely cleans up the existing sockmap and skmsg code and refactors it, to prepare for

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

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 Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-

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

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. Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki R

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

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 Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Reviewed-by

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

From: Cong Wang Currently, we compute ->data_end with a compile-time constant offset of skb. But as Jakub pointed out, we can actually compute it in eBPF JIT code at run-time, so that we can competely get rid of ->data_end. This is similar to skb_shinfo(skb) computat

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

From: Cong Wang As suggested by John, clean up sockmap related Kconfigs: Reduce the scope of CONFIG_BPF_STREAM_PARSER down to TCP stream parser, to reflect its name. Make the rest sockmap code simply depend on CONFIG_BPF_SYSCALL. And leave CONFIG_NET_SOCK_MSG untouched, as it is used by non

Re: [PATCH net-next v2 3/7] mld: add a new delayed_work, mc_delrec_work

On Sat, Feb 13, 2021 at 9:52 AM Taehee Yoo wrote: > > The goal of mc_delrec_work delayed work is to call mld_clear_delrec(). > The mld_clear_delrec() is called under both data path and control path. > So, the context of mld_clear_delrec() can be atomic. > But this function accesses struct ifmcaddr

Re: [PATCH net-next v2 1/7] mld: convert from timer to delayed work

On Sat, Feb 13, 2021 at 9:51 AM Taehee Yoo wrote: > -static void mld_dad_start_timer(struct inet6_dev *idev, unsigned long delay) > +static void mld_dad_start_work(struct inet6_dev *idev, unsigned long delay) > { > unsigned long tv = prandom_u32() % delay; > > - if (!mod_timer(&idev

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

On Fri, Feb 12, 2021 at 11:09 AM Cong Wang wrote: > > On Fri, Feb 12, 2021 at 2:56 AM Lorenz Bauer wrote: > > > > On Wed, 10 Feb 2021 at 02:21, Cong Wang wrote: > > > > > > From: Cong Wang > > > > > > struct sk_psock_parser is embedded in

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

On Fri, Feb 12, 2021 at 2:56 AM Lorenz Bauer wrote: > > On Wed, 10 Feb 2021 at 02:21, 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. &

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

On Fri, Feb 12, 2021 at 2:56 AM Lorenz Bauer wrote: > > On Wed, 10 Feb 2021 at 02:22, Cong Wang wrote: > > > > From: Cong Wang > > > > Currently, we compute ->data_end with a compile-time constant > > offset of skb. But as Jakub pointed out, we can actu

[Patch net-next v3] net: fix dev_ifsioc_locked() race condition

From: Cong Wang dev_ifsioc_locked() is called with only RCU read lock, so when there is a parallel writer changing the mac address, it could get a partially updated mac address, as shown below: Thread 1Thread 2 // eth_commit_mac_addr_change() memcpy(dev->dev_addr, a

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

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 Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz

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

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. Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki

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

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 Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-

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

From: Cong Wang Currently, we compute ->data_end with a compile-time constant offset of skb. But as Jakub pointed out, we can actually compute it in eBPF JIT code at run-time, so that we can competely get rid of ->data_end. This is similar to skb_shinfo(skb) computat

[Patch bpf-next v2 0/5] sock_map: clean up and refactor code for BPF_SK_SKB_VERDICT

From: Cong Wang This patchset is the first series of patches separated out from the original large patchset, to make reviews easier. This patchset does not add any new feature but merely cleans up the existing sockmap and skmsg code and refactors it, to prepare for the patches followed up. This

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

From: Cong Wang As suggested by John, clean up sockmap related Kconfigs: Reduce the scope of CONFIG_BPF_STREAM_PARSER down to TCP stream parser, to reflect its name. Make the rest sockmap code simply depend on CONFIG_BPF_SYSCALL. And leave CONFIG_NET_SOCK_MSG untouched, as it is used by non

Re: [PATCH net v4] net/sched: cls_flower: Reject invalid ct_state flags rules

On Mon, Feb 8, 2021 at 10:48 AM Jakub Kicinski wrote: > > On Mon, 8 Feb 2021 10:41:35 -0800 Cong Wang wrote: > > On Sat, Feb 6, 2021 at 9:26 PM wrote: > > > + if (state && !(state & TCA_FLOWER_KEY_CT_FLAGS_TRACKED)) { > > > +

Re: [PATCH net-next 0/8] mld: change context from atomic to sleepable

On Mon, Feb 8, 2021 at 6:17 PM Taehee Yoo wrote: > You're right, this patchset contains many unnecessary changes. > So I will send a v2 patch, which contains only the necessary changes. > And target branch will be 'net', not 'net-next'. Just to be clear: this is up to you. I am not suggesting the

Re: [PATCH net-next 0/8] mld: change context from atomic to sleepable

On Mon, Feb 8, 2021 at 9:50 AM Taehee Yoo wrote: > > This patchset changes context of MLD module. > Before this patch, MLD functions are atomic context so it couldn't use > sleepable functions and flags. > This patchset also contains other refactoring patches, which is to use > list macro, etc. >

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

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 longer specific to TCP, > > and it does not have to be

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

On Fri, Feb 5, 2021 at 2:32 AM Jakub Sitnicki wrote: > > On Wed, Feb 03, 2021 at 05:16 AM CET, 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 longer specific to TCP, &g

Re: [Patch bpf-next 08/19] udp: implement ->read_sock() for sockmap

On Mon, Feb 8, 2021 at 1:48 AM Lorenz Bauer wrote: > > On Wed, 3 Feb 2021 at 04:17, Cong Wang wrote: > > > > From: Cong Wang > > > > Cc: John Fastabend > > Cc: Daniel Borkmann > > Cc: Jakub Sitnicki > > Cc: Lorenz Bauer > > Signed-o

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

On Mon, Feb 8, 2021 at 12:39 AM John Fastabend wrote: > > 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 > > > unneces

Re: [Patch bpf-next 03/19] skmsg: use skb ext instead of TCP_SKB_CB

On Fri, Feb 5, 2021 at 2:09 PM Jakub Sitnicki wrote: > > On Wed, Feb 03, 2021 at 05:16 AM CET, Cong Wang wrote: > > From: Cong Wang > > > > Currently TCP_SKB_CB() is hard-coded in skmsg code, it certainly > > won't work for any other non-TCP protocols. We can

Re: [Patch bpf-next 18/19] selftests/bpf: add test cases for unix and udp sockmap

On Fri, Feb 5, 2021 at 2:53 AM Jakub Sitnicki wrote: > > On Wed, Feb 03, 2021 at 05:16 AM CET, Cong Wang wrote: > > From: Cong Wang > > > > Add two test cases to ensure redirection between two > > AF_UNIX sockets or two UDP sockets work. > > > > C

Re: [PATCH net v4] net/sched: cls_flower: Reject invalid ct_state flags rules

On Sat, Feb 6, 2021 at 9:26 PM wrote: > + if (state && !(state & TCA_FLOWER_KEY_CT_FLAGS_TRACKED)) { > + NL_SET_ERR_MSG_ATTR(extack, tb, > + "ct_state no trk, no other flag are set"); > + return -EINVAL; > + } > + > +

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

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 sockm

[Patch bpf-next 18/19] selftests/bpf: add test cases for unix and udp sockmap

From: Cong Wang Add two test cases to ensure redirection between two AF_UNIX sockets or two UDP sockets work. Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- .../selftests/bpf/prog_tests/sockmap_listen.c | 241

[Patch bpf-next 16/19] af_unix: implement unix_dgram_bpf_recvmsg()

From: Cong Wang We have to implement unix_dgram_bpf_recvmsg() to replace the original ->recvmsg() to retrieve skmsg from ingress_msg. AF_UNIX is again special here because the lack of sk_prot->recvmsg(). I simply add a special case inside unix_dgram_recvmsg() to call sk->sk_prot

[Patch bpf-next 15/19] udp: implement udp_bpf_recvmsg() for sockmap

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 --- net/ipv4/udp_bpf.c |

[Patch bpf-next 13/19] af_unix: set TCP_ESTABLISHED for datagram sockets too

From: Cong Wang Currently only unix stream socket sets TCP_ESTABLISHED, datagram socket can set this too when they connect to its peer socket. At least __ip4_datagram_connect() does the same. This will be used by the next patch to determine whether an AF_UNIX datagram socket can be redirected

[Patch bpf-next 14/19] skmsg: extract __tcp_bpf_recvmsg() and tcp_bpf_wait_data()

From: Cong Wang Although these two functions are only used by TCP, they are not specific to TCP at all, both operate on skmsg and ingress_msg, so fit in net/core/skmsg.c very well. And we will need them for non-TCP, so rename and move them to skmsg.c and export them to modules. Cc: John

[Patch bpf-next 17/19] sock_map: update sock type checks

From: Cong Wang Now both AF_UNIX and UDP support sockmap and redirection, we can safely update the sock type checks for them accordingly. Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- net/core/skmsg.c| 3 ++- net/core

[Patch bpf-next 19/19] selftests/bpf: add test case for redirection between udp and unix

From: Cong Wang Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- .../selftests/bpf/prog_tests/sockmap_listen.c | 226 ++ 1 file changed, 226 insertions(+) diff --git a/tools/testing/selftests/bpf/prog_tests

[Patch bpf-next 11/19] af_unix: implement ->read_sock() for sockmap

From: Cong Wang Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- net/unix/af_unix.c | 46 ++ 1 file changed, 46 insertions(+) diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index

[Patch bpf-next 12/19] af_unix: implement ->update_proto()

From: Cong Wang unix_proto is special, it is very different from INET proto, which even does not have a ->close(). We have to add a dummy one to satisfy sockmap. Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- MAINTAIN

[Patch bpf-next 10/19] af_unix: implement ->sendmsg_locked for dgram socket

From: Cong Wang We already have unix_dgram_sendmsg(), we can just build its ->sendmsg_locked() on top of it. Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- net/unix/af_unix.c | 14 +++--- 1 file changed, 11 insertions(+)

[Patch bpf-next 07/19] udp: implement ->sendmsg_locked()

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 Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong W

[Patch bpf-next 09/19] udp: add ->read_sock() and ->sendmsg_locked() to ipv6

From: Cong Wang Similarly, udpv6_sendmsg() takes lock_sock() inside too, we have to build ->sendmsg_locked() on top of it. For ->read_sock(), we can just use udp_read_sock(). Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- i

[Patch bpf-next 06/19] sock: introduce sk_prot->update_proto()

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. Introduce a new ops sk->sk_prot->update_proto(), so each protocol can implement its

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

From: Cong Wang I was planning to reuse BPF_SK_SKB_STREAM_VERDICT but its name is confusing and more importantly it seems kTLS relies on it to deliver sk_msg too. To avoid messing up kTLS, we can just reuse the stream verdict code but introduce a new type of eBPF program, skb_verdict. Users are

[Patch bpf-next 08/19] udp: implement ->read_sock() for sockmap

From: Cong Wang Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- include/net/udp.h | 2 ++ net/ipv4/af_inet.c | 1 + net/ipv4/udp.c | 34 ++ 3 files changed, 37 insertions(+) diff --git a/include

[Patch bpf-next 03/19] skmsg: use skb ext instead of TCP_SKB_CB

From: Cong Wang Currently TCP_SKB_CB() is hard-coded in skmsg code, it certainly won't 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. Of course, except ->data_end, which is used by sk_skb_convert_ctx_acc

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

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 Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc

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

From: Cong Wang Before we add non-TCP support, it is necessary to rename BPF_STREAM_PARSER as it will be no longer specific to TCP, and it does not have to be a parser either. This patch renames BPF_STREAM_PARSER to BPF_SOCK_MAP, so that sock_map.c hopefully would be protocol-independent. Also

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

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. Cc: John Fastabend Cc: Daniel Borkmann Cc: Jakub Sitnicki Cc: Lorenz Bauer Signed-off-by: Cong Wang --- incl

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

From: Cong Wang Currently sockmap only fully supports TCP, UDP is partially supported as it is only allowed to add into sockmap. This patch extends sockmap with: 1) full UDP support; 2) full AF_UNIX dgram support; 3) cross protocol support. Our goal is to allow socket splice between AF_UNIX

Re: [Patch net-next v2] net: fix dev_ifsioc_locked() race condition

On Mon, Feb 1, 2021 at 7:40 PM Jakub Kicinski wrote: > > On Sat, 30 Jan 2021 18:27:55 -0800 Cong Wang wrote: > > From: Cong Wang > > > > dev_ifsioc_locked() is called with only RCU read lock, so when > > there is a parallel writer changing the mac address, it cou

Re: [PATCH net-next v2] net/sched: act_police: add support for packet-per-second policing

On Mon, Feb 1, 2021 at 5:02 AM Simon Horman wrote: > Would something like this incremental change your concerns? Yes of course. Thanks!

[Patch net-next v2] net: fix dev_ifsioc_locked() race condition

From: Cong Wang dev_ifsioc_locked() is called with only RCU read lock, so when there is a parallel writer changing the mac address, it could get a partially updated mac address, as shown below: Thread 1Thread 2 // eth_commit_mac_addr_change() memcpy(dev->dev_addr, a

Re: [RESEND net v3] net: ip_tunnel: fix mtu calculation

On Fri, Jan 29, 2021 at 2:30 PM Vadim Fedorenko wrote: > > dev->hard_header_len for tunnel interface is set only when header_ops > are set too and already contains full overhead of any tunnel encapsulation. > That's why there is not need to use this overhead twice in mtu calc. > > Fixes: fdafed459

Re: [PATCH net] net: sched: replaced invalid qdisc tree flush helper in qdisc_replace

: introduce and use qdisc tree flush/purge > helpers") > Signed-off-by: Alexander Ovechkin Looks reasonable to me: Acked-by: Cong Wang Thanks.

Re: [Patch net] net: fix dev_ifsioc_locked() race condition

On Fri, Jan 29, 2021 at 10:00 AM Jakub Kicinski wrote: > > On Thu, 28 Jan 2021 21:47:04 -0800 Cong Wang wrote: > > On Thu, Jan 28, 2021 at 9:21 PM Jakub Kicinski wrote: > > > On Thu, 28 Jan 2021 21:08:05 -0800 Cong Wang wrote: > > > > On Thu, Jan 28, 2021

<    1   2   3   4   5   6   7   8   9   10   >