netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the net-next tree with the bpf tree
@ 2020-07-16  1:59 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2020-07-16  1:59 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Peilin Ye, Jiri Olsa

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  kernel/bpf/btf.c

between commit:

  5b801dfb7feb ("bpf: Fix NULL pointer dereference in __btf_resolve_helper_id()")

from the bpf tree and commit:

  138b9a0511c7 ("bpf: Remove btf_id helpers resolving")

from the net-next tree.

I fixed it up (the latter removed the code fixed by the former) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2022-10-04  2:07 ` Jakub Kicinski
@ 2022-10-04 22:45   ` Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2022-10-04 22:45 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: David Miller, Daniel Borkmann, Alexei Starovoitov,
	Andrii Nakryiko, bpf, Networking, David Vernet,
	Kumar Kartikeya Dwivedi, Linux Kernel Mailing List,
	Linux Next Mailing List, Stanislav Fomichev

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

Hi Jakub,

On Mon, 3 Oct 2022 19:07:27 -0700 Jakub Kicinski <kuba@kernel.org> wrote:
>
> Unrelated to the conflict but do you see this when building the latest
> by any chance? Is it just me and my poor old gcc 8.5?
> 
> vmlinux.o: warning: objtool: ___ksymtab+bpf_dispatcher_xdp_func+0x0: data relocation to !ENDBR: bpf_dispatcher_xdp_func+0x0
> vmlinux.o: warning: objtool: bpf_dispatcher_xdp+0xa0: data relocation to !ENDBR: bpf_dispatcher_xdp_func+0x0

I don't get those messages.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2022-10-04  1:24 Stephen Rothwell
@ 2022-10-04  2:07 ` Jakub Kicinski
  2022-10-04 22:45   ` Stephen Rothwell
  0 siblings, 1 reply; 29+ messages in thread
From: Jakub Kicinski @ 2022-10-04  2:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Daniel Borkmann, Alexei Starovoitov,
	Andrii Nakryiko, bpf, Networking, David Vernet,
	Kumar Kartikeya Dwivedi, Linux Kernel Mailing List,
	Linux Next Mailing List, Stanislav Fomichev

On Tue, 4 Oct 2022 12:24:28 +1100 Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   kernel/bpf/helpers.c
> 
> between commit:
> 
>   8addbfc7b308 ("bpf: Gate dynptr API behind CAP_BPF")
> 
> from the bpf tree and commits:
> 
>   8a67f2de9b1d ("bpf: expose bpf_strtol and bpf_strtoul to all program types")
>   5679ff2f138f ("bpf: Move bpf_loop and bpf_for_each_map_elem under CAP_BPF")
>   205715673844 ("bpf: Add bpf_user_ringbuf_drain() helper")

Thanks! 

Unrelated to the conflict but do you see this when building the latest
by any chance? Is it just me and my poor old gcc 8.5?

vmlinux.o: warning: objtool: ___ksymtab+bpf_dispatcher_xdp_func+0x0: data relocation to !ENDBR: bpf_dispatcher_xdp_func+0x0
vmlinux.o: warning: objtool: bpf_dispatcher_xdp+0xa0: data relocation to !ENDBR: bpf_dispatcher_xdp_func+0x0

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2022-10-04  1:24 Stephen Rothwell
  2022-10-04  2:07 ` Jakub Kicinski
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2022-10-04  1:24 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko
  Cc: bpf, Networking, David Vernet, Kumar Kartikeya Dwivedi,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Stanislav Fomichev

[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  kernel/bpf/helpers.c

between commit:

  8addbfc7b308 ("bpf: Gate dynptr API behind CAP_BPF")

from the bpf tree and commits:

  8a67f2de9b1d ("bpf: expose bpf_strtol and bpf_strtoul to all program types")
  5679ff2f138f ("bpf: Move bpf_loop and bpf_for_each_map_elem under CAP_BPF")
  205715673844 ("bpf: Add bpf_user_ringbuf_drain() helper")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/bpf/helpers.c
index 3814b0fd3a2c,b069517a3da0..000000000000
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@@ -1627,12 -1609,26 +1609,12 @@@ bpf_base_func_proto(enum bpf_func_id fu
  		return &bpf_ringbuf_discard_proto;
  	case BPF_FUNC_ringbuf_query:
  		return &bpf_ringbuf_query_proto;
- 	case BPF_FUNC_for_each_map_elem:
- 		return &bpf_for_each_map_elem_proto;
- 	case BPF_FUNC_loop:
- 		return &bpf_loop_proto;
 -	case BPF_FUNC_ringbuf_reserve_dynptr:
 -		return &bpf_ringbuf_reserve_dynptr_proto;
 -	case BPF_FUNC_ringbuf_submit_dynptr:
 -		return &bpf_ringbuf_submit_dynptr_proto;
 -	case BPF_FUNC_ringbuf_discard_dynptr:
 -		return &bpf_ringbuf_discard_dynptr_proto;
  	case BPF_FUNC_strncmp:
  		return &bpf_strncmp_proto;
+ 	case BPF_FUNC_strtol:
+ 		return &bpf_strtol_proto;
+ 	case BPF_FUNC_strtoul:
+ 		return &bpf_strtoul_proto;
 -	case BPF_FUNC_dynptr_from_mem:
 -		return &bpf_dynptr_from_mem_proto;
 -	case BPF_FUNC_dynptr_read:
 -		return &bpf_dynptr_read_proto;
 -	case BPF_FUNC_dynptr_write:
 -		return &bpf_dynptr_write_proto;
 -	case BPF_FUNC_dynptr_data:
 -		return &bpf_dynptr_data_proto;
  	default:
  		break;
  	}
@@@ -1661,20 -1657,12 +1643,26 @@@
  		return &bpf_timer_cancel_proto;
  	case BPF_FUNC_kptr_xchg:
  		return &bpf_kptr_xchg_proto;
 +	case BPF_FUNC_ringbuf_reserve_dynptr:
 +		return &bpf_ringbuf_reserve_dynptr_proto;
 +	case BPF_FUNC_ringbuf_submit_dynptr:
 +		return &bpf_ringbuf_submit_dynptr_proto;
 +	case BPF_FUNC_ringbuf_discard_dynptr:
 +		return &bpf_ringbuf_discard_dynptr_proto;
 +	case BPF_FUNC_dynptr_from_mem:
 +		return &bpf_dynptr_from_mem_proto;
 +	case BPF_FUNC_dynptr_read:
 +		return &bpf_dynptr_read_proto;
 +	case BPF_FUNC_dynptr_write:
 +		return &bpf_dynptr_write_proto;
 +	case BPF_FUNC_dynptr_data:
 +		return &bpf_dynptr_data_proto;
+ 	case BPF_FUNC_for_each_map_elem:
+ 		return &bpf_for_each_map_elem_proto;
+ 	case BPF_FUNC_loop:
+ 		return &bpf_loop_proto;
+ 	case BPF_FUNC_user_ringbuf_drain:
+ 		return &bpf_user_ringbuf_drain_proto;
  	default:
  		break;
  	}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2022-09-23  0:45 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2022-09-23  0:45 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko
  Cc: bpf, Networking, Kumar Kartikeya Dwivedi,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Stanislav Fomichev

[-- Attachment #1: Type: text/plain, Size: 2860 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  kernel/bpf/helpers.c

between commit:

  8addbfc7b308 ("bpf: Gate dynptr API behind CAP_BPF")

from the bpf tree and commits:

  8a67f2de9b1d ("bpf: expose bpf_strtol and bpf_strtoul to all program types")
  5679ff2f138f ("bpf: Move bpf_loop and bpf_for_each_map_elem under CAP_BPF")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/bpf/helpers.c
index 3814b0fd3a2c,fc08035f14ed..000000000000
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@@ -1627,12 -1607,26 +1607,12 @@@ bpf_base_func_proto(enum bpf_func_id fu
  		return &bpf_ringbuf_discard_proto;
  	case BPF_FUNC_ringbuf_query:
  		return &bpf_ringbuf_query_proto;
- 	case BPF_FUNC_for_each_map_elem:
- 		return &bpf_for_each_map_elem_proto;
- 	case BPF_FUNC_loop:
- 		return &bpf_loop_proto;
 -	case BPF_FUNC_ringbuf_reserve_dynptr:
 -		return &bpf_ringbuf_reserve_dynptr_proto;
 -	case BPF_FUNC_ringbuf_submit_dynptr:
 -		return &bpf_ringbuf_submit_dynptr_proto;
 -	case BPF_FUNC_ringbuf_discard_dynptr:
 -		return &bpf_ringbuf_discard_dynptr_proto;
  	case BPF_FUNC_strncmp:
  		return &bpf_strncmp_proto;
+ 	case BPF_FUNC_strtol:
+ 		return &bpf_strtol_proto;
+ 	case BPF_FUNC_strtoul:
+ 		return &bpf_strtoul_proto;
 -	case BPF_FUNC_dynptr_from_mem:
 -		return &bpf_dynptr_from_mem_proto;
 -	case BPF_FUNC_dynptr_read:
 -		return &bpf_dynptr_read_proto;
 -	case BPF_FUNC_dynptr_write:
 -		return &bpf_dynptr_write_proto;
 -	case BPF_FUNC_dynptr_data:
 -		return &bpf_dynptr_data_proto;
  	default:
  		break;
  	}
@@@ -1661,20 -1655,10 +1641,24 @@@
  		return &bpf_timer_cancel_proto;
  	case BPF_FUNC_kptr_xchg:
  		return &bpf_kptr_xchg_proto;
 +	case BPF_FUNC_ringbuf_reserve_dynptr:
 +		return &bpf_ringbuf_reserve_dynptr_proto;
 +	case BPF_FUNC_ringbuf_submit_dynptr:
 +		return &bpf_ringbuf_submit_dynptr_proto;
 +	case BPF_FUNC_ringbuf_discard_dynptr:
 +		return &bpf_ringbuf_discard_dynptr_proto;
 +	case BPF_FUNC_dynptr_from_mem:
 +		return &bpf_dynptr_from_mem_proto;
 +	case BPF_FUNC_dynptr_read:
 +		return &bpf_dynptr_read_proto;
 +	case BPF_FUNC_dynptr_write:
 +		return &bpf_dynptr_write_proto;
 +	case BPF_FUNC_dynptr_data:
 +		return &bpf_dynptr_data_proto;
+ 	case BPF_FUNC_for_each_map_elem:
+ 		return &bpf_for_each_map_elem_proto;
+ 	case BPF_FUNC_loop:
+ 		return &bpf_loop_proto;
  	default:
  		break;
  	}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2021-10-27  0:12 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2021-10-27  0:12 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Cong Wang, Linux Kernel Mailing List, Linux Next Mailing List,
	Richard Palethorpe

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  include/net/sock.h

between commit:

  7b50ecfcc6cd ("net: Rename ->stream_memory_read to ->sock_is_readable")

from the bpf tree and commit:

  4c1e34c0dbff ("vsock: Enable y2038 safe timeval for timeout")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/net/sock.h
index 463f390d90b3,ff4e62aa62e5..000000000000
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@@ -2820,10 -2840,8 +2840,15 @@@ void sock_set_sndtimeo(struct sock *sk
  
  int sock_bind_add(struct sock *sk, struct sockaddr *addr, int addr_len);
  
+ int sock_get_timeout(long timeo, void *optval, bool old_timeval);
+ int sock_copy_user_timeval(struct __kernel_sock_timeval *tv,
+ 			   sockptr_t optval, int optlen, bool old_timeval);
+ 
 +static inline bool sk_is_readable(struct sock *sk)
 +{
 +	if (sk->sk_prot->sock_is_readable)
 +		return sk->sk_prot->sock_is_readable(sk);
 +	return false;
 +}
++
  #endif	/* _SOCK_H */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2021-06-22  1:06 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2021-06-22  1:06 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Cong Wang, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 4798 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got conflicts in:

  net/ipv4/tcp_bpf.c
  net/ipv4/udp_bpf.c
  include/linux/skmsg.h
  net/core/skmsg.c

between commit:

  9f2470fbc4cb ("skmsg: Improve udp_bpf_recvmsg() accuracy")

from the bpf tree and commit:

  c49661aa6f70 ("skmsg: Remove unused parameters of sk_msg_wait_data()")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/skmsg.h
index e3d080c299f6,fcaa9a7996c8..000000000000
--- a/include/linux/skmsg.h
+++ b/include/linux/skmsg.h
diff --cc net/core/skmsg.c
index 9b6160a191f8,f0b9decdf279..000000000000
--- a/net/core/skmsg.c
+++ b/net/core/skmsg.c
diff --cc net/ipv4/tcp_bpf.c
index bb49b52d7be8,a80de92ea3b6..000000000000
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@@ -163,28 -163,6 +163,28 @@@ static bool tcp_bpf_stream_read(const s
  	return !empty;
  }
  
- static int tcp_msg_wait_data(struct sock *sk, struct sk_psock *psock, int flags,
- 			     long timeo, int *err)
++static int tcp_msg_wait_data(struct sock *sk, struct sk_psock *psock,
++			     long timeo)
 +{
 +	DEFINE_WAIT_FUNC(wait, woken_wake_function);
 +	int ret = 0;
 +
 +	if (sk->sk_shutdown & RCV_SHUTDOWN)
 +		return 1;
 +
 +	if (!timeo)
 +		return ret;
 +
 +	add_wait_queue(sk_sleep(sk), &wait);
 +	sk_set_bit(SOCKWQ_ASYNC_WAITDATA, sk);
 +	ret = sk_wait_event(sk, &timeo,
 +			    !list_empty(&psock->ingress_msg) ||
 +			    !skb_queue_empty(&sk->sk_receive_queue), &wait);
 +	sk_clear_bit(SOCKWQ_ASYNC_WAITDATA, sk);
 +	remove_wait_queue(sk_sleep(sk), &wait);
 +	return ret;
 +}
 +
  static int tcp_bpf_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
  		    int nonblock, int flags, int *addr_len)
  {
@@@ -206,11 -184,11 +206,11 @@@
  msg_bytes_ready:
  	copied = sk_msg_recvmsg(sk, psock, msg, len, flags);
  	if (!copied) {
- 		int data, err = 0;
  		long timeo;
+ 		int data;
  
  		timeo = sock_rcvtimeo(sk, nonblock);
- 		data = tcp_msg_wait_data(sk, psock, flags, timeo, &err);
 -		data = sk_msg_wait_data(sk, psock, timeo);
++		data = tcp_msg_wait_data(sk, psock, timeo);
  		if (data) {
  			if (!sk_psock_queue_empty(psock))
  				goto msg_bytes_ready;
diff --cc net/ipv4/udp_bpf.c
index 565a70040c57,b07e4b6dda25..000000000000
--- a/net/ipv4/udp_bpf.c
+++ b/net/ipv4/udp_bpf.c
@@@ -21,45 -21,6 +21,45 @@@ static int sk_udp_recvmsg(struct sock *
  	return udp_prot.recvmsg(sk, msg, len, noblock, flags, addr_len);
  }
  
 +static bool udp_sk_has_data(struct sock *sk)
 +{
 +	return !skb_queue_empty(&udp_sk(sk)->reader_queue) ||
 +	       !skb_queue_empty(&sk->sk_receive_queue);
 +}
 +
 +static bool psock_has_data(struct sk_psock *psock)
 +{
 +	return !skb_queue_empty(&psock->ingress_skb) ||
 +	       !sk_psock_queue_empty(psock);
 +}
 +
 +#define udp_msg_has_data(__sk, __psock)	\
 +		({ udp_sk_has_data(__sk) || psock_has_data(__psock); })
 +
- static int udp_msg_wait_data(struct sock *sk, struct sk_psock *psock, int flags,
- 			     long timeo, int *err)
++static int udp_msg_wait_data(struct sock *sk, struct sk_psock *psock,
++			     long timeo)
 +{
 +	DEFINE_WAIT_FUNC(wait, woken_wake_function);
 +	int ret = 0;
 +
 +	if (sk->sk_shutdown & RCV_SHUTDOWN)
 +		return 1;
 +
 +	if (!timeo)
 +		return ret;
 +
 +	add_wait_queue(sk_sleep(sk), &wait);
 +	sk_set_bit(SOCKWQ_ASYNC_WAITDATA, sk);
 +	ret = udp_msg_has_data(sk, psock);
 +	if (!ret) {
 +		wait_woken(&wait, TASK_INTERRUPTIBLE, timeo);
 +		ret = udp_msg_has_data(sk, psock);
 +	}
 +	sk_clear_bit(SOCKWQ_ASYNC_WAITDATA, sk);
 +	remove_wait_queue(sk_sleep(sk), &wait);
 +	return ret;
 +}
 +
  static int udp_bpf_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
  			   int nonblock, int flags, int *addr_len)
  {
@@@ -81,13 -43,13 +81,13 @@@
  msg_bytes_ready:
  	copied = sk_msg_recvmsg(sk, psock, msg, len, flags);
  	if (!copied) {
- 		int data, err = 0;
  		long timeo;
+ 		int data;
  
  		timeo = sock_rcvtimeo(sk, nonblock);
- 		data = udp_msg_wait_data(sk, psock, flags, timeo, &err);
 -		data = sk_msg_wait_data(sk, psock, timeo);
++		data = udp_msg_wait_data(sk, psock, timeo);
  		if (data) {
 -			if (!sk_psock_queue_empty(psock))
 +			if (psock_has_data(psock))
  				goto msg_bytes_ready;
  			ret = sk_udp_recvmsg(sk, msg, len, nonblock, flags, addr_len);
  			goto out;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2021-04-08  3:11 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2021-04-08  3:11 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Cong Wang, John Fastabend, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 3139 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/core/skmsg.c

between commit:

  144748eb0c44 ("bpf, sockmap: Fix incorrect fwd_alloc accounting")

from the bpf tree and commit:

  e3526bb92a20 ("skmsg: Move sk_redir from TCP_SKB_CB to skb")

from the net-next tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/core/skmsg.c
index 5def3a2e85be,92a83c02562a..000000000000
--- a/net/core/skmsg.c
+++ b/net/core/skmsg.c
@@@ -806,12 -900,17 +900,13 @@@ int sk_psock_tls_strp_read(struct sk_ps
  	int ret = __SK_PASS;
  
  	rcu_read_lock();
- 	prog = READ_ONCE(psock->progs.skb_verdict);
+ 	prog = READ_ONCE(psock->progs.stream_verdict);
  	if (likely(prog)) {
 -		/* We skip full set_owner_r here because if we do a SK_PASS
 -		 * or SK_DROP we can skip skb memory accounting and use the
 -		 * TLS context.
 -		 */
  		skb->sk = psock->sk;
- 		tcp_skb_bpf_redirect_clear(skb);
- 		ret = sk_psock_bpf_run(psock, prog, skb);
- 		ret = sk_psock_map_verd(ret, tcp_skb_bpf_redirect_fetch(skb));
+ 		skb_dst_drop(skb);
+ 		skb_bpf_redirect_clear(skb);
+ 		ret = bpf_prog_run_pin_on_cpu(prog, skb);
+ 		ret = sk_psock_map_verd(ret, skb_bpf_redirect_fetch(skb));
  		skb->sk = NULL;
  	}
  	sk_psock_tls_verdict_apply(skb, psock->sk, ret);
@@@ -876,13 -995,13 +991,14 @@@ static void sk_psock_strp_read(struct s
  		kfree_skb(skb);
  		goto out;
  	}
- 	prog = READ_ONCE(psock->progs.skb_verdict);
 -	skb_set_owner_r(skb, sk);
+ 	prog = READ_ONCE(psock->progs.stream_verdict);
  	if (likely(prog)) {
 +		skb->sk = sk;
- 		tcp_skb_bpf_redirect_clear(skb);
- 		ret = sk_psock_bpf_run(psock, prog, skb);
- 		ret = sk_psock_map_verd(ret, tcp_skb_bpf_redirect_fetch(skb));
+ 		skb_dst_drop(skb);
+ 		skb_bpf_redirect_clear(skb);
+ 		ret = bpf_prog_run_pin_on_cpu(prog, skb);
+ 		ret = sk_psock_map_verd(ret, skb_bpf_redirect_fetch(skb));
 +		skb->sk = NULL;
  	}
  	sk_psock_verdict_apply(psock, skb, ret);
  out:
@@@ -953,13 -1115,15 +1112,16 @@@ static int sk_psock_verdict_recv(read_d
  		kfree_skb(skb);
  		goto out;
  	}
- 	prog = READ_ONCE(psock->progs.skb_verdict);
 -	skb_set_owner_r(skb, sk);
+ 	prog = READ_ONCE(psock->progs.stream_verdict);
+ 	if (!prog)
+ 		prog = READ_ONCE(psock->progs.skb_verdict);
  	if (likely(prog)) {
 +		skb->sk = sk;
- 		tcp_skb_bpf_redirect_clear(skb);
- 		ret = sk_psock_bpf_run(psock, prog, skb);
- 		ret = sk_psock_map_verd(ret, tcp_skb_bpf_redirect_fetch(skb));
+ 		skb_dst_drop(skb);
+ 		skb_bpf_redirect_clear(skb);
+ 		ret = bpf_prog_run_pin_on_cpu(prog, skb);
+ 		ret = sk_psock_map_verd(ret, skb_bpf_redirect_fetch(skb));
 +		skb->sk = NULL;
  	}
  	sk_psock_verdict_apply(psock, skb, ret);
  out:

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2021-04-08  3:02 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2021-04-08  3:02 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Cong Wang, John Fastabend, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  include/linux/skmsg.h

between commit:

  1c84b33101c8 ("bpf, sockmap: Fix sk->prot unhash op reset")

from the bpf tree and commit:

  8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()")

from the net-next tree.

I didn't know how to fixed it up so I just used the latter version or
today - a better solution would be appreciated. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2021-03-29  1:29 Stephen Rothwell
@ 2021-03-29  8:28 ` Jiri Olsa
  0 siblings, 0 replies; 29+ messages in thread
From: Jiri Olsa @ 2021-03-29  8:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Daniel Borkmann, Alexei Starovoitov, Networking,
	Jiri Olsa, Linux Kernel Mailing List, Linux Next Mailing List,
	Yonghong Song

On Mon, Mar 29, 2021 at 12:29:16PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   include/linux/bpf.h
> 
> between commit:
> 
>   861de02e5f3f ("bpf: Take module reference for trampoline in module")
> 
> from the bpf tree and commit:
> 
>   69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc include/linux/bpf.h
> index fdac0534ce79,39dce9d3c3a5..000000000000
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@@ -40,7 -40,7 +40,8 @@@ struct bpf_local_storage
>   struct bpf_local_storage_map;
>   struct kobject;
>   struct mem_cgroup;
>  +struct module;
> + struct bpf_func_state;
>   
>   extern struct idr btf_idr;
>   extern spinlock_t btf_idr_lock;

ack, thanks
jirka


^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2021-03-29  1:29 Stephen Rothwell
  2021-03-29  8:28 ` Jiri Olsa
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2021-03-29  1:29 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Jiri Olsa, Linux Kernel Mailing List, Linux Next Mailing List,
	Yonghong Song

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  include/linux/bpf.h

between commit:

  861de02e5f3f ("bpf: Take module reference for trampoline in module")

from the bpf tree and commit:

  69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/bpf.h
index fdac0534ce79,39dce9d3c3a5..000000000000
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@@ -40,7 -40,7 +40,8 @@@ struct bpf_local_storage
  struct bpf_local_storage_map;
  struct kobject;
  struct mem_cgroup;
 +struct module;
+ struct bpf_func_state;
  
  extern struct idr btf_idr;
  extern spinlock_t btf_idr_lock;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2020-05-26  3:12 Stephen Rothwell
@ 2020-05-26  5:45 ` Björn Töpel
  0 siblings, 0 replies; 29+ messages in thread
From: Björn Töpel @ 2020-05-26  5:45 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Daniel Borkmann,
	Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

On 2020-05-26 05:12, Stephen Rothwell wrote:
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The fix looks good!

I'll keep this is mind, and try not to repeat similar conflicts for 
future patches.

Thanks for the fixup, and for the clarification!


Cheers,
Björn

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2020-05-26  3:12 Stephen Rothwell
  2020-05-26  5:45 ` Björn Töpel
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2020-05-26  3:12 UTC (permalink / raw)
  To: David Miller, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Björn Töpel

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/xdp/xdp_umem.c

between commit:

  b16a87d0aef7 ("xsk: Add overflow check for u64 division, stored into u32")

from the bpf tree and commit:

  2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/xdp/xdp_umem.c
index 3889bd9aec46,19e59d1a5e9f..000000000000
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@@ -389,13 -349,10 +353,10 @@@ static int xdp_umem_reg(struct xdp_ume
  	if (headroom >= chunk_size - XDP_PACKET_HEADROOM)
  		return -EINVAL;
  
- 	umem->address = (unsigned long)addr;
- 	umem->chunk_mask = unaligned_chunks ? XSK_UNALIGNED_BUF_ADDR_MASK
- 					    : ~((u64)chunk_size - 1);
  	umem->size = size;
  	umem->headroom = headroom;
- 	umem->chunk_size_nohr = chunk_size - headroom;
+ 	umem->chunk_size = chunk_size;
 -	umem->npgs = size / PAGE_SIZE;
 +	umem->npgs = (u32)npgs;
  	umem->pgs = NULL;
  	umem->user = NULL;
  	umem->flags = mr->flags;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2019-06-06  1:34 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2019-06-06  1:34 UTC (permalink / raw)
  To: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Hangbin Liu,
	Andrii Nakryiko

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  tools/testing/selftests/bpf/Makefile

between commit:

  25a7991c84f6 ("selftests/bpf: move test_lirc_mode2_user to TEST_GEN_PROGS_EXTENDED")

from the bpf tree and commit:

  2d2a3ad872f8 ("selftests/bpf: add btf_dump BTF-to-C conversion tests")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/bpf/Makefile
index e36356e2377e,2b426ae1cdc9..000000000000
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@@ -21,9 -23,10 +23,10 @@@ LDLIBS += -lcap -lelf -lrt -lpthrea
  # Order correspond to 'make run_tests' order
  TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs \
  	test_align test_verifier_log test_dev_cgroup test_tcpbpf_user \
- 	test_sock test_btf test_sockmap get_cgroup_id_user test_socket_cookie \
- 	test_cgroup_storage test_select_reuseport test_section_names \
- 	test_netcnt test_tcpnotify_user test_sock_fields test_sysctl
 -	test_sock test_btf test_sockmap test_lirc_mode2_user get_cgroup_id_user \
++	test_sock test_btf test_sockmap get_cgroup_id_user \
+ 	test_socket_cookie test_cgroup_storage test_select_reuseport test_section_names \
+ 	test_netcnt test_tcpnotify_user test_sock_fields test_sysctl test_hashmap \
+ 	test_btf_dump test_cgroup_attach xdping
  
  BPF_OBJ_FILES = $(patsubst %.c,%.o, $(notdir $(wildcard progs/*.c)))
  TEST_GEN_FILES = $(BPF_OBJ_FILES)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2019-02-20  0:48   ` Daniel Borkmann
@ 2019-02-20  3:03     ` Stanislav Fomichev
  0 siblings, 0 replies; 29+ messages in thread
From: Stanislav Fomichev @ 2019-02-20  3:03 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: Alexei Starovoitov, Stephen Rothwell, David Miller, Networking,
	Alexei Starovoitov, Linux Next Mailing List,
	Linux Kernel Mailing List

On Tue, Feb 19, 2019 at 5:07 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 02/20/2019 01:41 AM, Alexei Starovoitov wrote:
> > On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> Hi all,
> >>
> >> Today's linux-next merge of the net-next tree got a conflict in:
> >>
> >>   tools/testing/selftests/bpf/test_progs.c
> >>
> >> between commit:
> >>
> >>   f6be4d16039b ("selftests/bpf: make sure signal interrupts BPF_PROG_TEST_RUN")
> >
> > Ouch. Thanks for the heads up.
> >
> > Daniel,
> > should we drop this one from bpf tree ?
> > I don't think it's strictly necessary.
>
> Yeah no objections, lets move the selftest one over to bpf-next and
> have it properly integrated. I think test_progs might potentially need
> further topic-split aside from kernel progs like we did in test_verifier.
Do you want me to follow up with a clean rebased bpf-next sefltest patch?
Or you'll take care of it yourself?

> >> from the bpf tree and commits:
> >>
> >>   bf0f0fd93945 ("selftests/bpf: add simple BPF_PROG_TEST_RUN examples for flow dissector")
> >>   ab963beb9f5d ("selftests/bpf: add bpf_spin_lock C test")
> >>   ba72a7b4badb ("selftests/bpf: test for BPF_F_LOCK")

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2019-02-20  0:45   ` Stanislav Fomichev
@ 2019-02-20  1:03     ` Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2019-02-20  1:03 UTC (permalink / raw)
  To: Stanislav Fomichev
  Cc: Alexei Starovoitov, David Miller, Networking, Daniel Borkmann,
	Alexei Starovoitov, Linux Next Mailing List,
	Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Hi Stanislav,

On Tue, 19 Feb 2019 16:45:46 -0800 Stanislav Fomichev <sdf@google.com> wrote:
>
> OTOH, I don't understand why is there a conflict? bpf and bpf-next
> adding tests in the same place/file? Those can be trivially resolved
> when bpf and bpf-next are merged in the next window.

Yes, and yes :-)

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2019-02-20  0:41 ` Alexei Starovoitov
  2019-02-20  0:45   ` Stanislav Fomichev
@ 2019-02-20  0:48   ` Daniel Borkmann
  2019-02-20  3:03     ` Stanislav Fomichev
  1 sibling, 1 reply; 29+ messages in thread
From: Daniel Borkmann @ 2019-02-20  0:48 UTC (permalink / raw)
  To: Alexei Starovoitov, Stephen Rothwell
  Cc: David Miller, Networking, Alexei Starovoitov,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Stanislav Fomichev

On 02/20/2019 01:41 AM, Alexei Starovoitov wrote:
> On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>>
>> Today's linux-next merge of the net-next tree got a conflict in:
>>
>>   tools/testing/selftests/bpf/test_progs.c
>>
>> between commit:
>>
>>   f6be4d16039b ("selftests/bpf: make sure signal interrupts BPF_PROG_TEST_RUN")
> 
> Ouch. Thanks for the heads up.
> 
> Daniel,
> should we drop this one from bpf tree ?
> I don't think it's strictly necessary.

Yeah no objections, lets move the selftest one over to bpf-next and
have it properly integrated. I think test_progs might potentially need
further topic-split aside from kernel progs like we did in test_verifier.

>> from the bpf tree and commits:
>>
>>   bf0f0fd93945 ("selftests/bpf: add simple BPF_PROG_TEST_RUN examples for flow dissector")
>>   ab963beb9f5d ("selftests/bpf: add bpf_spin_lock C test")
>>   ba72a7b4badb ("selftests/bpf: test for BPF_F_LOCK")

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2019-02-20  0:41 ` Alexei Starovoitov
@ 2019-02-20  0:45   ` Stanislav Fomichev
  2019-02-20  1:03     ` Stephen Rothwell
  2019-02-20  0:48   ` Daniel Borkmann
  1 sibling, 1 reply; 29+ messages in thread
From: Stanislav Fomichev @ 2019-02-20  0:45 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Stephen Rothwell, David Miller, Networking, Daniel Borkmann,
	Alexei Starovoitov, Linux Next Mailing List,
	Linux Kernel Mailing List

On Tue, Feb 19, 2019 at 4:41 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the net-next tree got a conflict in:
> >
> >   tools/testing/selftests/bpf/test_progs.c
> >
> > between commit:
> >
> >   f6be4d16039b ("selftests/bpf: make sure signal interrupts BPF_PROG_TEST_RUN")
>
> Ouch. Thanks for the heads up.
>
> Daniel,
> should we drop this one from bpf tree ?
> I don't think it's strictly necessary.
Yeah, those can go via the bpf-next three as well, not very critical.

OTOH, I don't understand why is there a conflict? bpf and bpf-next
adding tests in the same place/file? Those can be trivially resolved
when bpf and bpf-next are merged in the next window.
>
> > from the bpf tree and commits:
> >
> >   bf0f0fd93945 ("selftests/bpf: add simple BPF_PROG_TEST_RUN examples for flow dissector")
> >   ab963beb9f5d ("selftests/bpf: add bpf_spin_lock C test")
> >   ba72a7b4badb ("selftests/bpf: test for BPF_F_LOCK")
> >

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2019-02-20  0:37 Stephen Rothwell
@ 2019-02-20  0:41 ` Alexei Starovoitov
  2019-02-20  0:45   ` Stanislav Fomichev
  2019-02-20  0:48   ` Daniel Borkmann
  0 siblings, 2 replies; 29+ messages in thread
From: Alexei Starovoitov @ 2019-02-20  0:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Stanislav Fomichev

On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   tools/testing/selftests/bpf/test_progs.c
>
> between commit:
>
>   f6be4d16039b ("selftests/bpf: make sure signal interrupts BPF_PROG_TEST_RUN")

Ouch. Thanks for the heads up.

Daniel,
should we drop this one from bpf tree ?
I don't think it's strictly necessary.

> from the bpf tree and commits:
>
>   bf0f0fd93945 ("selftests/bpf: add simple BPF_PROG_TEST_RUN examples for flow dissector")
>   ab963beb9f5d ("selftests/bpf: add bpf_spin_lock C test")
>   ba72a7b4badb ("selftests/bpf: test for BPF_F_LOCK")
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2019-02-20  0:37 Stephen Rothwell
  2019-02-20  0:41 ` Alexei Starovoitov
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2019-02-20  0:37 UTC (permalink / raw)
  To: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Stanislav Fomichev

[-- Attachment #1: Type: text/plain, Size: 8862 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  tools/testing/selftests/bpf/test_progs.c

between commit:

  f6be4d16039b ("selftests/bpf: make sure signal interrupts BPF_PROG_TEST_RUN")

from the bpf tree and commits:

  bf0f0fd93945 ("selftests/bpf: add simple BPF_PROG_TEST_RUN examples for flow dissector")
  ab963beb9f5d ("selftests/bpf: add bpf_spin_lock C test")
  ba72a7b4badb ("selftests/bpf: test for BPF_F_LOCK")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/bpf/test_progs.c
index 7842e3749b19,c52bd90fbb34..000000000000
--- a/tools/testing/selftests/bpf/test_progs.c
+++ b/tools/testing/selftests/bpf/test_progs.c
@@@ -10,8 -10,8 +10,9 @@@
  #include <string.h>
  #include <assert.h>
  #include <stdlib.h>
+ #include <stdarg.h>
  #include <time.h>
 +#include <signal.h>
  
  #include <linux/types.h>
  typedef __u16 __sum16;
@@@ -28,9 -28,8 +29,9 @@@
  #include <sys/ioctl.h>
  #include <sys/wait.h>
  #include <sys/types.h>
 +#include <sys/time.h>
  #include <fcntl.h>
- 
+ #include <pthread.h>
  #include <linux/bpf.h>
  #include <linux/err.h>
  #include <bpf/bpf.h>
@@@ -1914,47 -1925,189 +1927,230 @@@ out
  	bpf_object__close(obj);
  }
  
 +static void sigalrm_handler(int s) {}
 +static struct sigaction sigalrm_action = {
 +	.sa_handler = sigalrm_handler,
 +};
 +
 +static void test_signal_pending(void)
 +{
 +	struct bpf_insn prog[4096];
 +	struct itimerval timeo = {
 +		.it_value.tv_usec = 100000, /* 100ms */
 +	};
 +	__u32 duration, retval;
 +	int prog_fd;
 +	int err;
 +	int i;
 +
 +	for (i = 0; i < ARRAY_SIZE(prog); i++)
 +		prog[i] = BPF_ALU64_IMM(BPF_MOV, BPF_REG_0, 0);
 +	prog[ARRAY_SIZE(prog) - 1] = BPF_EXIT_INSN();
 +
 +	prog_fd = bpf_load_program(BPF_PROG_TYPE_SOCKET_FILTER,
 +				   prog, ARRAY_SIZE(prog),
 +				   "GPL", 0, NULL, 0);
 +	CHECK(prog_fd < 0, "test-run", "errno %d\n", errno);
 +
 +	err = sigaction(SIGALRM, &sigalrm_action, NULL);
 +	CHECK(err, "test-run-signal-sigaction", "errno %d\n", errno);
 +
 +	err = setitimer(ITIMER_REAL, &timeo, NULL);
 +	CHECK(err, "test-run-signal-timer", "errno %d\n", errno);
 +
 +	err = bpf_prog_test_run(prog_fd, 0xffffffff, &pkt_v4, sizeof(pkt_v4),
 +				NULL, NULL, &retval, &duration);
 +	CHECK(err != -1 || errno != EINTR || duration > 1000000000,
 +	      "test-run-signal-run",
 +	      "err %d errno %d retval %d\n",
 +	      err, errno, retval);
 +
 +	signal(SIGALRM, SIG_DFL);
 +}
 +
+ #define CHECK_FLOW_KEYS(desc, got, expected)				\
+ 	CHECK(memcmp(&got, &expected, sizeof(got)) != 0,		\
+ 	      desc,							\
+ 	      "nhoff=%u/%u "						\
+ 	      "thoff=%u/%u "						\
+ 	      "addr_proto=0x%x/0x%x "					\
+ 	      "is_frag=%u/%u "						\
+ 	      "is_first_frag=%u/%u "					\
+ 	      "is_encap=%u/%u "						\
+ 	      "n_proto=0x%x/0x%x "					\
+ 	      "sport=%u/%u "						\
+ 	      "dport=%u/%u\n",						\
+ 	      got.nhoff, expected.nhoff,				\
+ 	      got.thoff, expected.thoff,				\
+ 	      got.addr_proto, expected.addr_proto,			\
+ 	      got.is_frag, expected.is_frag,				\
+ 	      got.is_first_frag, expected.is_first_frag,		\
+ 	      got.is_encap, expected.is_encap,				\
+ 	      got.n_proto, expected.n_proto,				\
+ 	      got.sport, expected.sport,				\
+ 	      got.dport, expected.dport)
+ 
+ static struct bpf_flow_keys pkt_v4_flow_keys = {
+ 	.nhoff = 0,
+ 	.thoff = sizeof(struct iphdr),
+ 	.addr_proto = ETH_P_IP,
+ 	.ip_proto = IPPROTO_TCP,
+ 	.n_proto = bpf_htons(ETH_P_IP),
+ };
+ 
+ static struct bpf_flow_keys pkt_v6_flow_keys = {
+ 	.nhoff = 0,
+ 	.thoff = sizeof(struct ipv6hdr),
+ 	.addr_proto = ETH_P_IPV6,
+ 	.ip_proto = IPPROTO_TCP,
+ 	.n_proto = bpf_htons(ETH_P_IPV6),
+ };
+ 
+ static void test_flow_dissector(void)
+ {
+ 	struct bpf_flow_keys flow_keys;
+ 	struct bpf_object *obj;
+ 	__u32 duration, retval;
+ 	int err, prog_fd;
+ 	__u32 size;
+ 
+ 	err = bpf_flow_load(&obj, "./bpf_flow.o", "flow_dissector",
+ 			    "jmp_table", &prog_fd);
+ 	if (err) {
+ 		error_cnt++;
+ 		return;
+ 	}
+ 
+ 	err = bpf_prog_test_run(prog_fd, 10, &pkt_v4, sizeof(pkt_v4),
+ 				&flow_keys, &size, &retval, &duration);
+ 	CHECK(size != sizeof(flow_keys) || err || retval != 1, "ipv4",
+ 	      "err %d errno %d retval %d duration %d size %u/%lu\n",
+ 	      err, errno, retval, duration, size, sizeof(flow_keys));
+ 	CHECK_FLOW_KEYS("ipv4_flow_keys", flow_keys, pkt_v4_flow_keys);
+ 
+ 	err = bpf_prog_test_run(prog_fd, 10, &pkt_v6, sizeof(pkt_v6),
+ 				&flow_keys, &size, &retval, &duration);
+ 	CHECK(size != sizeof(flow_keys) || err || retval != 1, "ipv6",
+ 	      "err %d errno %d retval %d duration %d size %u/%lu\n",
+ 	      err, errno, retval, duration, size, sizeof(flow_keys));
+ 	CHECK_FLOW_KEYS("ipv6_flow_keys", flow_keys, pkt_v6_flow_keys);
+ 
+ 	bpf_object__close(obj);
+ }
+ 
+ static void *test_spin_lock(void *arg)
+ {
+ 	__u32 duration, retval;
+ 	int err, prog_fd = *(u32 *) arg;
+ 
+ 	err = bpf_prog_test_run(prog_fd, 10000, &pkt_v4, sizeof(pkt_v4),
+ 				NULL, NULL, &retval, &duration);
+ 	CHECK(err || retval, "",
+ 	      "err %d errno %d retval %d duration %d\n",
+ 	      err, errno, retval, duration);
+ 	pthread_exit(arg);
+ }
+ 
+ static void test_spinlock(void)
+ {
+ 	const char *file = "./test_spin_lock.o";
+ 	pthread_t thread_id[4];
+ 	struct bpf_object *obj;
+ 	int prog_fd;
+ 	int err = 0, i;
+ 	void *ret;
+ 
+ 	err = bpf_prog_load(file, BPF_PROG_TYPE_CGROUP_SKB, &obj, &prog_fd);
+ 	if (err) {
+ 		printf("test_spin_lock:bpf_prog_load errno %d\n", errno);
+ 		goto close_prog;
+ 	}
+ 	for (i = 0; i < 4; i++)
+ 		assert(pthread_create(&thread_id[i], NULL,
+ 				      &test_spin_lock, &prog_fd) == 0);
+ 	for (i = 0; i < 4; i++)
+ 		assert(pthread_join(thread_id[i], &ret) == 0 &&
+ 		       ret == (void *)&prog_fd);
+ 	goto close_prog_noerr;
+ close_prog:
+ 	error_cnt++;
+ close_prog_noerr:
+ 	bpf_object__close(obj);
+ }
+ 
+ static void *parallel_map_access(void *arg)
+ {
+ 	int err, map_fd = *(u32 *) arg;
+ 	int vars[17], i, j, rnd, key = 0;
+ 
+ 	for (i = 0; i < 10000; i++) {
+ 		err = bpf_map_lookup_elem_flags(map_fd, &key, vars, BPF_F_LOCK);
+ 		if (err) {
+ 			printf("lookup failed\n");
+ 			error_cnt++;
+ 			goto out;
+ 		}
+ 		if (vars[0] != 0) {
+ 			printf("lookup #%d var[0]=%d\n", i, vars[0]);
+ 			error_cnt++;
+ 			goto out;
+ 		}
+ 		rnd = vars[1];
+ 		for (j = 2; j < 17; j++) {
+ 			if (vars[j] == rnd)
+ 				continue;
+ 			printf("lookup #%d var[1]=%d var[%d]=%d\n",
+ 			       i, rnd, j, vars[j]);
+ 			error_cnt++;
+ 			goto out;
+ 		}
+ 	}
+ out:
+ 	pthread_exit(arg);
+ }
+ 
+ static void test_map_lock(void)
+ {
+ 	const char *file = "./test_map_lock.o";
+ 	int prog_fd, map_fd[2], vars[17] = {};
+ 	pthread_t thread_id[6];
+ 	struct bpf_object *obj;
+ 	int err = 0, key = 0, i;
+ 	void *ret;
+ 
+ 	err = bpf_prog_load(file, BPF_PROG_TYPE_CGROUP_SKB, &obj, &prog_fd);
+ 	if (err) {
+ 		printf("test_map_lock:bpf_prog_load errno %d\n", errno);
+ 		goto close_prog;
+ 	}
+ 	map_fd[0] = bpf_find_map(__func__, obj, "hash_map");
+ 	if (map_fd[0] < 0)
+ 		goto close_prog;
+ 	map_fd[1] = bpf_find_map(__func__, obj, "array_map");
+ 	if (map_fd[1] < 0)
+ 		goto close_prog;
+ 
+ 	bpf_map_update_elem(map_fd[0], &key, vars, BPF_F_LOCK);
+ 
+ 	for (i = 0; i < 4; i++)
+ 		assert(pthread_create(&thread_id[i], NULL,
+ 				      &test_spin_lock, &prog_fd) == 0);
+ 	for (i = 4; i < 6; i++)
+ 		assert(pthread_create(&thread_id[i], NULL,
+ 				      &parallel_map_access, &map_fd[i - 4]) == 0);
+ 	for (i = 0; i < 4; i++)
+ 		assert(pthread_join(thread_id[i], &ret) == 0 &&
+ 		       ret == (void *)&prog_fd);
+ 	for (i = 4; i < 6; i++)
+ 		assert(pthread_join(thread_id[i], &ret) == 0 &&
+ 		       ret == (void *)&map_fd[i - 4]);
+ 	goto close_prog_noerr;
+ close_prog:
+ 	error_cnt++;
+ close_prog_noerr:
+ 	bpf_object__close(obj);
+ }
+ 
  int main(void)
  {
  	srand(time(NULL));
@@@ -1982,7 -2135,9 +2178,10 @@@
  	test_reference_tracking();
  	test_queue_stack_map(QUEUE);
  	test_queue_stack_map(STACK);
 +	test_signal_pending();
+ 	test_flow_dissector();
+ 	test_spinlock();
+ 	test_map_lock();
  
  	printf("Summary: %d PASSED, %d FAILED\n", pass_cnt, error_cnt);
  	return error_cnt ? EXIT_FAILURE : EXIT_SUCCESS;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2018-12-14  0:56 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2018-12-14  0:56 UTC (permalink / raw)
  To: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Jakub Kicinski, Petar Penkov

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  tools/testing/selftests/bpf/test_verifier.c

between commit:

  7640ead93924 ("bpf: verifier: make sure callees don't prune with caller differences")

from the bpf tree and commit:

  e3da08d05700 ("bpf: allow BPF read access to qdisc pkt_len")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/bpf/test_verifier.c
index f8eac4a544f4,a08c67c8767e..000000000000
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@@ -13915,34 -14067,38 +14067,66 @@@ static struct bpf_test tests[] = 
  		.result_unpriv = REJECT,
  		.result = ACCEPT,
  	},
 +	{
 +		"calls: cross frame pruning",
 +		.insns = {
 +			/* r8 = !!random();
 +			 * call pruner()
 +			 * if (r8)
 +			 *     do something bad;
 +			 */
 +			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
 +				     BPF_FUNC_get_prandom_u32),
 +			BPF_MOV64_IMM(BPF_REG_8, 0),
 +			BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 1),
 +			BPF_MOV64_IMM(BPF_REG_8, 1),
 +			BPF_MOV64_REG(BPF_REG_1, BPF_REG_8),
 +			BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 1, 0, 4),
 +			BPF_JMP_IMM(BPF_JEQ, BPF_REG_8, 1, 1),
 +			BPF_LDX_MEM(BPF_B, BPF_REG_9, BPF_REG_1, 0),
 +			BPF_MOV64_IMM(BPF_REG_0, 0),
 +			BPF_EXIT_INSN(),
 +			BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0, 0),
 +			BPF_EXIT_INSN(),
 +		},
 +		.prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
 +		.errstr_unpriv = "function calls to other bpf functions are allowed for root only",
 +		.result_unpriv = REJECT,
 +		.errstr = "!read_ok",
 +		.result = REJECT,
 +	},
+ 	{
+ 		"check wire_len is not readable by sockets",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1,
+ 				    offsetof(struct __sk_buff, wire_len)),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.errstr = "invalid bpf_context access",
+ 		.result = REJECT,
+ 	},
+ 	{
+ 		"check wire_len is readable by tc classifier",
+ 		.insns = {
+ 			BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1,
+ 				    offsetof(struct __sk_buff, wire_len)),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ 		.result = ACCEPT,
+ 	},
+ 	{
+ 		"check wire_len is not writable by tc classifier",
+ 		.insns = {
+ 			BPF_STX_MEM(BPF_W, BPF_REG_1, BPF_REG_1,
+ 				    offsetof(struct __sk_buff, wire_len)),
+ 			BPF_EXIT_INSN(),
+ 		},
+ 		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ 		.errstr = "invalid bpf_context access",
+ 		.errstr_unpriv = "R1 leaks addr",
+ 		.result = REJECT,
+ 	},
  };
  
  static int probe_filter_length(const struct bpf_insn *fp)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2018-12-03  2:16 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2018-12-03  2:16 UTC (permalink / raw)
  To: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Joe Stringer,
	Nitin Hande, Vlad Dumitrescu

[-- Attachment #1: Type: text/plain, Size: 4050 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/core/filter.c

between commits:

  b7df9ada9a77 ("bpf: fix pointer offsets in context for 32 bit")
  f71c6143c203 ("bpf: Support sk lookup in netns with id 0")

from the bpf tree and commits:

  c8123ead13a5 ("bpf: Extend the sk_lookup() helper to XDP hookpoint.")
  f11216b24219 ("bpf: add skb->tstamp r/w access from tc clsact and cg skb progs")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/core/filter.c
index 8d2c629501e2,bd0df75dc7b6..000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -4887,26 -5067,26 +5067,27 @@@ __bpf_sk_lookup(struct sk_buff *skb, st
  	struct sock *sk = NULL;
  	u8 family = AF_UNSPEC;
  	struct net *net;
+ 	int sdif;
  
  	family = len == sizeof(tuple->ipv4) ? AF_INET : AF_INET6;
 -	if (unlikely(family == AF_UNSPEC || netns_id > U32_MAX || flags))
 +	if (unlikely(family == AF_UNSPEC || flags ||
 +		     !((s32)netns_id < 0 || netns_id <= S32_MAX)))
  		goto out;
  
- 	if (skb->dev)
- 		caller_net = dev_net(skb->dev);
+ 	if (family == AF_INET)
+ 		sdif = inet_sdif(skb);
  	else
- 		caller_net = sock_net(skb->sk);
+ 		sdif = inet6_sdif(skb);
+ 
 -	if (netns_id) {
 +	if ((s32)netns_id < 0) {
 +		net = caller_net;
- 		sk = sk_lookup(net, tuple, skb, family, proto);
++		sk = sk_lookup(net, tuple, ifindex, sdif, family, proto);
 +	} else {
  		net = get_net_ns_by_id(caller_net, netns_id);
  		if (unlikely(!net))
  			goto out;
- 		sk = sk_lookup(net, tuple, skb, family, proto);
+ 		sk = sk_lookup(net, tuple, ifindex, sdif, family, proto);
  		put_net(net);
 -	} else {
 -		net = caller_net;
 -		sk = sk_lookup(net, tuple, ifindex, sdif, family, proto);
  	}
  
  	if (sk)
@@@ -5436,10 -5737,14 +5738,14 @@@ static bool bpf_skb_is_valid_access(in
  		if (size != size_default)
  			return false;
  		break;
 -	case bpf_ctx_range(struct __sk_buff, flow_keys):
 -		if (size != sizeof(struct bpf_flow_keys *))
 +	case bpf_ctx_range_ptr(struct __sk_buff, flow_keys):
 +		if (size != sizeof(__u64))
  			return false;
  		break;
+ 	case bpf_ctx_range(struct __sk_buff, tstamp):
+ 		if (size != sizeof(__u64))
+ 			return false;
+ 		break;
  	default:
  		/* Only narrow read access allowed for now. */
  		if (type == BPF_WRITE) {
@@@ -5465,8 -5770,9 +5771,9 @@@ static bool sk_filter_is_valid_access(i
  	case bpf_ctx_range(struct __sk_buff, data):
  	case bpf_ctx_range(struct __sk_buff, data_meta):
  	case bpf_ctx_range(struct __sk_buff, data_end):
 -	case bpf_ctx_range(struct __sk_buff, flow_keys):
 +	case bpf_ctx_range_ptr(struct __sk_buff, flow_keys):
  	case bpf_ctx_range_till(struct __sk_buff, family, local_port):
+ 	case bpf_ctx_range(struct __sk_buff, tstamp):
  		return false;
  	}
  
@@@ -5531,7 -5841,8 +5842,8 @@@ static bool lwt_is_valid_access(int off
  	case bpf_ctx_range(struct __sk_buff, tc_classid):
  	case bpf_ctx_range_till(struct __sk_buff, family, local_port):
  	case bpf_ctx_range(struct __sk_buff, data_meta):
 -	case bpf_ctx_range(struct __sk_buff, flow_keys):
 +	case bpf_ctx_range_ptr(struct __sk_buff, flow_keys):
+ 	case bpf_ctx_range(struct __sk_buff, tstamp):
  		return false;
  	}
  
@@@ -5959,7 -6271,8 +6272,8 @@@ static bool sk_skb_is_valid_access(int 
  	switch (off) {
  	case bpf_ctx_range(struct __sk_buff, tc_classid):
  	case bpf_ctx_range(struct __sk_buff, data_meta):
 -	case bpf_ctx_range(struct __sk_buff, flow_keys):
 +	case bpf_ctx_range_ptr(struct __sk_buff, flow_keys):
+ 	case bpf_ctx_range(struct __sk_buff, tstamp):
  		return false;
  	}
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2018-12-03  2:03 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2018-12-03  2:03 UTC (permalink / raw)
  To: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Joe Stringer,
	Nitin Hande, Vlad Dumitrescu, Lorenz Bauer

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  include/uapi/linux/bpf.h
  tools/include/uapi/linux/bpf.h

between commits:

  b7df9ada9a77 ("bpf: fix pointer offsets in context for 32 bit")
  d74286d2c25a ("bpf: Improve socket lookup reuseport documentation")

from the bpf tree and commits:

  c8123ead13a5 ("bpf: Extend the sk_lookup() helper to XDP hookpoint.")
  608114e441ad ("tools: sync linux/bpf.h")
  f11216b24219 ("bpf: add skb->tstamp r/w access from tc clsact and cg skb progs")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/bpf.h
index 72c453a8bf50,597afdbc1ab9..000000000000
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@@ -2473,7 -2481,8 +2494,8 @@@ struct __sk_buff 
  	/* ... here. */
  
  	__u32 data_meta;
 -	struct bpf_flow_keys *flow_keys;
 +	__bpf_md_ptr(struct bpf_flow_keys *, flow_keys);
+ 	__u64 tstamp;
  };
  
  struct bpf_tunnel_key {
diff --cc tools/include/uapi/linux/bpf.h
index 72c453a8bf50,597afdbc1ab9..000000000000
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@@ -2473,7 -2481,8 +2494,8 @@@ struct __sk_buff 
  	/* ... here. */
  
  	__u32 data_meta;
 -	struct bpf_flow_keys *flow_keys;
 +	__bpf_md_ptr(struct bpf_flow_keys *, flow_keys);
+ 	__u64 tstamp;
  };
  
  struct bpf_tunnel_key {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2018-08-01  1:35 Stephen Rothwell
@ 2018-08-01  4:23 ` Yonghong Song
  0 siblings, 0 replies; 29+ messages in thread
From: Yonghong Song @ 2018-08-01  4:23 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller, Networking, Daniel Borkmann,
	Alexei Starovoitov
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Okash Khawaja



On 7/31/18 6:35 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>    tools/bpf/bpftool/map.c
> 
> between commit:
> 
>    573b3aa69406 ("tools/bpftool: fix a percpu_array map dump problem")
> 
> from the bpf tree and commit:
> 
>    2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
> 
> from the net-next tree.

The merge looks good to me. Thanks!

> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2018-08-01  1:35 Stephen Rothwell
  2018-08-01  4:23 ` Yonghong Song
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2018-08-01  1:35 UTC (permalink / raw)
  To: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Yonghong Song, Okash Khawaja

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  tools/bpf/bpftool/map.c

between commit:

  573b3aa69406 ("tools/bpftool: fix a percpu_array map dump problem")

from the bpf tree and commit:

  2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/bpf/bpftool/map.c
index f74a8bcbda87,9c8191845585..000000000000
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@@ -34,9 -34,7 +34,8 @@@
  #include <assert.h>
  #include <errno.h>
  #include <fcntl.h>
 +#include <linux/kernel.h>
+ #include <linux/err.h>
  #include <stdbool.h>
  #include <stdio.h>
  #include <stdlib.h>
@@@ -162,11 -262,20 +264,21 @@@ static void print_entry_json(struct bpf
  		print_hex_data_json(key, info->key_size);
  		jsonw_name(json_wtr, "value");
  		print_hex_data_json(value, info->value_size);
+ 		if (btf) {
+ 			struct btf_dumper d = {
+ 				.btf = btf,
+ 				.jw = json_wtr,
+ 				.is_plain_text = false,
+ 			};
+ 
+ 			jsonw_name(json_wtr, "formatted");
+ 			do_dump_btf(&d, info, key, value);
+ 		}
  	} else {
 -		unsigned int i, n;
 +		unsigned int i, n, step;
  
  		n = get_possible_cpus();
 +		step = round_up(info->value_size, 8);
  
  		jsonw_name(json_wtr, "key");
  		print_hex_data_json(key, info->key_size);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2018-07-26  1:19 Stephen Rothwell
@ 2018-07-26 15:32 ` Martin KaFai Lau
  0 siblings, 0 replies; 29+ messages in thread
From: Martin KaFai Lau @ 2018-07-26 15:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Okash Khawaja, Daniel Borkmann,
	Alexei Starovoitov

On Thu, Jul 26, 2018 at 11:19:16AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got conflicts in:
> 
>   tools/lib/bpf/btf.c
>   tools/lib/bpf/btf.h
> 
> between commits:
> 
>   5b891af7fca1 ("bpf: Replace [u]int32_t and [u]int64_t in libbpf")
>   38d5d3b3d5db ("bpf: Introduce BPF_ANNOTATE_KV_PAIR")
> 
> from the bpf tree and commit:
> 
>   92b57121ca79 ("bpf: btf: export btf types and name by offset from lib")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.  This
The fix LGTM. Thanks!

> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc tools/lib/bpf/btf.c
> index 2d270c560df3,03161be094b4..000000000000
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@@ -269,9 -259,29 +266,29 @@@ __s64 btf__resolve_size(const struct bt
>   	return nelems * size;
>   }
>   
> + int btf__resolve_type(const struct btf *btf, __u32 type_id)
> + {
> + 	const struct btf_type *t;
> + 	int depth = 0;
> + 
> + 	t = btf__type_by_id(btf, type_id);
> + 	while (depth < MAX_RESOLVE_DEPTH &&
> + 	       !btf_type_is_void_or_null(t) &&
> + 	       IS_MODIFIER(BTF_INFO_KIND(t->info))) {
> + 		type_id = t->type;
> + 		t = btf__type_by_id(btf, type_id);
> + 		depth++;
> + 	}
> + 
> + 	if (depth == MAX_RESOLVE_DEPTH || btf_type_is_void_or_null(t))
> + 		return -EINVAL;
> + 
> + 	return type_id;
> + }
> + 
>  -int32_t btf__find_by_name(const struct btf *btf, const char *type_name)
>  +__s32 btf__find_by_name(const struct btf *btf, const char *type_name)
>   {
>  -	uint32_t i;
>  +	__u32 i;
>   
>   	if (!strcmp(type_name, "void"))
>   		return 0;
> @@@ -368,3 -379,20 +385,11 @@@ int btf__fd(const struct btf *btf
>   {
>   	return btf->fd;
>   }
> + 
> + const char *btf__name_by_offset(const struct btf *btf, __u32 offset)
> + {
> + 	if (offset < btf->hdr->str_len)
> + 		return &btf->strings[offset];
> + 	else
> + 		return NULL;
> + }
>  -
>  -const struct btf_type *btf__type_by_id(const struct btf *btf,
>  -				       __u32 type_id)
>  -{
>  -	if (type_id > btf->nr_types)
>  -		return NULL;
>  -
>  -	return btf->types[type_id];
>  -}
> diff --cc tools/lib/bpf/btf.h
> index e2a09a155f84,24f361d99a5e..000000000000
> --- a/tools/lib/bpf/btf.h
> +++ b/tools/lib/bpf/btf.h
> @@@ -15,10 -14,12 +15,12 @@@ typedef int (*btf_print_fn_t)(const cha
>   	__attribute__((format(printf, 1, 2)));
>   
>   void btf__free(struct btf *btf);
>  -struct btf *btf__new(uint8_t *data, uint32_t size, btf_print_fn_t err_log);
>  -int32_t btf__find_by_name(const struct btf *btf, const char *type_name);
>  -int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id);
>  +struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log);
>  +__s32 btf__find_by_name(const struct btf *btf, const char *type_name);
> - const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 id);
>  +__s64 btf__resolve_size(const struct btf *btf, __u32 type_id);
> + int btf__resolve_type(const struct btf *btf, __u32 type_id);
>   int btf__fd(const struct btf *btf);
> + const char *btf__name_by_offset(const struct btf *btf, __u32 offset);
> + const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id);
>   
>   #endif

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2018-07-26  1:19 Stephen Rothwell
  2018-07-26 15:32 ` Martin KaFai Lau
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2018-07-26  1:19 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Okash Khawaja, Daniel Borkmann, Alexei Starovoitov,
	Martin KaFai Lau

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got conflicts in:

  tools/lib/bpf/btf.c
  tools/lib/bpf/btf.h

between commits:

  5b891af7fca1 ("bpf: Replace [u]int32_t and [u]int64_t in libbpf")
  38d5d3b3d5db ("bpf: Introduce BPF_ANNOTATE_KV_PAIR")

from the bpf tree and commit:

  92b57121ca79 ("bpf: btf: export btf types and name by offset from lib")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/lib/bpf/btf.c
index 2d270c560df3,03161be094b4..000000000000
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@@ -269,9 -259,29 +266,29 @@@ __s64 btf__resolve_size(const struct bt
  	return nelems * size;
  }
  
+ int btf__resolve_type(const struct btf *btf, __u32 type_id)
+ {
+ 	const struct btf_type *t;
+ 	int depth = 0;
+ 
+ 	t = btf__type_by_id(btf, type_id);
+ 	while (depth < MAX_RESOLVE_DEPTH &&
+ 	       !btf_type_is_void_or_null(t) &&
+ 	       IS_MODIFIER(BTF_INFO_KIND(t->info))) {
+ 		type_id = t->type;
+ 		t = btf__type_by_id(btf, type_id);
+ 		depth++;
+ 	}
+ 
+ 	if (depth == MAX_RESOLVE_DEPTH || btf_type_is_void_or_null(t))
+ 		return -EINVAL;
+ 
+ 	return type_id;
+ }
+ 
 -int32_t btf__find_by_name(const struct btf *btf, const char *type_name)
 +__s32 btf__find_by_name(const struct btf *btf, const char *type_name)
  {
 -	uint32_t i;
 +	__u32 i;
  
  	if (!strcmp(type_name, "void"))
  		return 0;
@@@ -368,3 -379,20 +385,11 @@@ int btf__fd(const struct btf *btf
  {
  	return btf->fd;
  }
+ 
+ const char *btf__name_by_offset(const struct btf *btf, __u32 offset)
+ {
+ 	if (offset < btf->hdr->str_len)
+ 		return &btf->strings[offset];
+ 	else
+ 		return NULL;
+ }
 -
 -const struct btf_type *btf__type_by_id(const struct btf *btf,
 -				       __u32 type_id)
 -{
 -	if (type_id > btf->nr_types)
 -		return NULL;
 -
 -	return btf->types[type_id];
 -}
diff --cc tools/lib/bpf/btf.h
index e2a09a155f84,24f361d99a5e..000000000000
--- a/tools/lib/bpf/btf.h
+++ b/tools/lib/bpf/btf.h
@@@ -15,10 -14,12 +15,12 @@@ typedef int (*btf_print_fn_t)(const cha
  	__attribute__((format(printf, 1, 2)));
  
  void btf__free(struct btf *btf);
 -struct btf *btf__new(uint8_t *data, uint32_t size, btf_print_fn_t err_log);
 -int32_t btf__find_by_name(const struct btf *btf, const char *type_name);
 -int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id);
 +struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log);
 +__s32 btf__find_by_name(const struct btf *btf, const char *type_name);
- const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 id);
 +__s64 btf__resolve_size(const struct btf *btf, __u32 type_id);
+ int btf__resolve_type(const struct btf *btf, __u32 type_id);
  int btf__fd(const struct btf *btf);
+ const char *btf__name_by_offset(const struct btf *btf, __u32 offset);
+ const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id);
  
  #endif

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the net-next tree with the bpf tree
  2018-01-09  0:21 Stephen Rothwell
@ 2018-01-09  0:29 ` Alexei Starovoitov
  0 siblings, 0 replies; 29+ messages in thread
From: Alexei Starovoitov @ 2018-01-09  0:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Tue, Jan 09, 2018 at 11:21:25AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   tools/testing/selftests/bpf/test_align.c
> 
> between commit:
> 
>   2b36047e7889 ("selftests/bpf: fix test_align")
> 
> from the bpf tree and commit:
> 
>   6a28b446b7d2 ("selftests/bpf: adjust test_align expected output")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc tools/testing/selftests/bpf/test_align.c
> index 471bbbdb94db,fe916d29e166..000000000000
> --- a/tools/testing/selftests/bpf/test_align.c
> +++ b/tools/testing/selftests/bpf/test_align.c
> @@@ -473,8 -473,28 +473,8 @@@ static struct bpf_align_test tests[] = 
>   		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
>   		.result = REJECT,
>   		.matches = {
> - 			{4, "R5=pkt(id=0,off=0,r=0,imm=0)"},
> + 			{4, "R5_w=pkt(id=0,off=0,r=0,imm=0)"},

thanks. That's correct resolution.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the net-next tree with the bpf tree
@ 2018-01-09  0:21 Stephen Rothwell
  2018-01-09  0:29 ` Alexei Starovoitov
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2018-01-09  0:21 UTC (permalink / raw)
  To: David Miller, Networking, Daniel Borkmann, Alexei Starovoitov
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  tools/testing/selftests/bpf/test_align.c

between commit:

  2b36047e7889 ("selftests/bpf: fix test_align")

from the bpf tree and commit:

  6a28b446b7d2 ("selftests/bpf: adjust test_align expected output")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/bpf/test_align.c
index 471bbbdb94db,fe916d29e166..000000000000
--- a/tools/testing/selftests/bpf/test_align.c
+++ b/tools/testing/selftests/bpf/test_align.c
@@@ -473,8 -473,28 +473,8 @@@ static struct bpf_align_test tests[] = 
  		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
  		.result = REJECT,
  		.matches = {
- 			{4, "R5=pkt(id=0,off=0,r=0,imm=0)"},
+ 			{4, "R5_w=pkt(id=0,off=0,r=0,imm=0)"},
 -			/* ptr & 0x40 == either 0 or 0x40 */
 -			{5, "R5_w=inv(id=0,umax_value=64,var_off=(0x0; 0x40))"},
 -			/* ptr << 2 == unknown, (4n) */
 -			{7, "R5_w=inv(id=0,smax_value=9223372036854775804,umax_value=18446744073709551612,var_off=(0x0; 0xfffffffffffffffc))"},
 -			/* (4n) + 14 == (4n+2).  We blow our bounds, because
 -			 * the add could overflow.
 -			 */
 -			{8, "R5=inv(id=0,var_off=(0x2; 0xfffffffffffffffc))"},
 -			/* Checked s>=0 */
 -			{10, "R5=inv(id=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
 -			/* packet pointer + nonnegative (4n+2) */
 -			{12, "R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
 -			{14, "R4=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
 -			/* NET_IP_ALIGN + (4n+2) == (4n), alignment is fine.
 -			 * We checked the bounds, but it might have been able
 -			 * to overflow if the packet pointer started in the
 -			 * upper half of the address space.
 -			 * So we did not get a 'range' on R6, and the access
 -			 * attempt will fail.
 -			 */
 -			{16, "R6=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 0x7ffffffffffffffc))"},
 +			/* R5 bitwise operator &= on pointer prohibited */
  		}
  	},
  	{

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2022-10-04 22:45 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-16  1:59 linux-next: manual merge of the net-next tree with the bpf tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-10-04  1:24 Stephen Rothwell
2022-10-04  2:07 ` Jakub Kicinski
2022-10-04 22:45   ` Stephen Rothwell
2022-09-23  0:45 Stephen Rothwell
2021-10-27  0:12 Stephen Rothwell
2021-06-22  1:06 Stephen Rothwell
2021-04-08  3:11 Stephen Rothwell
2021-04-08  3:02 Stephen Rothwell
2021-03-29  1:29 Stephen Rothwell
2021-03-29  8:28 ` Jiri Olsa
2020-05-26  3:12 Stephen Rothwell
2020-05-26  5:45 ` Björn Töpel
2019-06-06  1:34 Stephen Rothwell
2019-02-20  0:37 Stephen Rothwell
2019-02-20  0:41 ` Alexei Starovoitov
2019-02-20  0:45   ` Stanislav Fomichev
2019-02-20  1:03     ` Stephen Rothwell
2019-02-20  0:48   ` Daniel Borkmann
2019-02-20  3:03     ` Stanislav Fomichev
2018-12-14  0:56 Stephen Rothwell
2018-12-03  2:16 Stephen Rothwell
2018-12-03  2:03 Stephen Rothwell
2018-08-01  1:35 Stephen Rothwell
2018-08-01  4:23 ` Yonghong Song
2018-07-26  1:19 Stephen Rothwell
2018-07-26 15:32 ` Martin KaFai Lau
2018-01-09  0:21 Stephen Rothwell
2018-01-09  0:29 ` Alexei Starovoitov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).