Re: [External] linux-next: manual merge of the net-next tree with the bpf tree

2021-04-07 Thread Cong Wang .
On Wed, Apr 7, 2021 at 8:11 PM Stephen Rothwell  wrote:
>
> 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.

Looks good from my quick glance.

Thanks!


Re: [External] linux-next: manual merge of the net-next tree with the bpf tree

2021-04-07 Thread Cong Wang .
On Wed, Apr 7, 2021 at 8:02 PM Stephen Rothwell  wrote:
>
> 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.

The right way to resolve this is to move the lines added in commit
1c84b33101c8 to the similar place in tcp_bpf_update_proto().

Thanks.


linux-next: manual merge of the net-next tree with the bpf tree

2021-04-07 Thread Stephen Rothwell
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..
--- 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:


pgpmIksOHySb2.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the net-next tree with the bpf tree

2021-04-07 Thread Stephen Rothwell
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


pgpLwie9IQh1g.pgp
Description: OpenPGP digital signature


Re: linux-next: manual merge of the net-next tree with the bpf tree

2021-03-29 Thread Jiri Olsa
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..
> --- 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



linux-next: manual merge of the net-next tree with the bpf tree

2021-03-28 Thread Stephen Rothwell
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..
--- 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;


pgpuGsdmuM12I.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the net-next tree with the bpf tree

2020-07-15 Thread Stephen Rothwell
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


pgpIO4Uk0L6G3.pgp
Description: OpenPGP digital signature


Re: linux-next: manual merge of the net-next tree with the bpf tree

2020-05-25 Thread Björn Töpel

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


linux-next: manual merge of the net-next tree with the bpf tree

2020-05-25 Thread Stephen Rothwell
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..
--- 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;


pgpIcBMmTWURI.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the net-next tree with the bpf tree

2019-06-05 Thread Stephen Rothwell
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..
--- 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)


pgpMDJjaJkoeF.pgp
Description: OpenPGP digital signature


Re: linux-next: manual merge of the net-next tree with the bpf tree

2019-02-19 Thread Stanislav Fomichev
On Tue, Feb 19, 2019 at 5:07 PM Daniel Borkmann  wrote:
>
> On 02/20/2019 01:41 AM, Alexei Starovoitov wrote:
> > On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell  
> > 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")


Re: linux-next: manual merge of the net-next tree with the bpf tree

2019-02-19 Thread Daniel Borkmann
On 02/20/2019 01:41 AM, Alexei Starovoitov wrote:
> On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell  
> 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")


Re: linux-next: manual merge of the net-next tree with the bpf tree

2019-02-19 Thread Stephen Rothwell
Hi Stanislav,

On Tue, 19 Feb 2019 16:45:46 -0800 Stanislav Fomichev  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


pgpR_JbLCEbM6.pgp
Description: OpenPGP digital signature


Re: linux-next: manual merge of the net-next tree with the bpf tree

2019-02-19 Thread Stanislav Fomichev
On Tue, Feb 19, 2019 at 4:41 PM Alexei Starovoitov
 wrote:
>
> On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell  
> 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")
> >


Re: linux-next: manual merge of the net-next tree with the bpf tree

2019-02-19 Thread Alexei Starovoitov
On Tue, Feb 19, 2019 at 4:37 PM Stephen Rothwell  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")
>


linux-next: manual merge of the net-next tree with the bpf tree

2019-02-19 Thread Stephen Rothwell
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..
--- a/tools/testing/selftests/bpf/test_progs.c
+++ b/tools/testing/selftests/bpf/test_progs.c
@@@ -10,8 -10,8 +10,9 @@@
  #include 
  #include 
  #include 
+ #include 
  #include 
 +#include 
  
  #include 
  typedef __u16 __sum16;
@@@ -28,9 -28,8 +29,9 @@@
  #include 
  #include 
  #include 
 +#include 
  #include 
- 
+ #include 
  #include 
  #include 
  #include 
@@@ -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 = 10, /* 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, _action, NULL);
 +  CHECK(err, "test-run-signal-sigaction", "errno %d\n", errno);
 +
 +  err = setitimer(ITIMER_REAL, , NULL);
 +  CHECK(err, "test-run-signal-timer", "errno %d\n", errno);
 +
 +  err = bpf_prog_test_run(prog_fd, 0x, _v4, sizeof(pkt_v4),
 +  NULL, NULL, , );
 +  CHECK(err != -1 || errno != EINTR || duration > 10,
 +"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(, , 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 

linux-next: manual merge of the net-next tree with the bpf tree

2018-12-13 Thread Stephen Rothwell
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..
--- 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)


pgpytL8Tl8XPu.pgp
Description: OpenPGP digital signature


Re: linux-next: manual merge of the net-next tree with the bpf tree

2018-01-08 Thread Alexei Starovoitov
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..
> --- 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.



Re: linux-next: manual merge of the net-next tree with the bpf tree

2018-01-08 Thread Alexei Starovoitov
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..
> --- 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.



linux-next: manual merge of the net-next tree with the bpf tree

2018-01-08 Thread Stephen Rothwell
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..
--- 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;
 0xfffc))"},
 -  /* (4n) + 14 == (4n+2).  We blow our bounds, because
 -   * the add could overflow.
 -   */
 -  {8, "R5=inv(id=0,var_off=(0x2; 0xfffc))"},
 -  /* Checked s>=0 */
 -  {10, 
"R5=inv(id=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 
0x7ffc))"},
 -  /* packet pointer + nonnegative (4n+2) */
 -  {12, 
"R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2;
 0x7ffc))"},
 -  {14, 
"R4=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2;
 0x7ffc))"},
 -  /* 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;
 0x7ffc))"},
 +  /* R5 bitwise operator &= on pointer prohibited */
}
},
{


linux-next: manual merge of the net-next tree with the bpf tree

2018-01-08 Thread Stephen Rothwell
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..
--- 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;
 0xfffc))"},
 -  /* (4n) + 14 == (4n+2).  We blow our bounds, because
 -   * the add could overflow.
 -   */
 -  {8, "R5=inv(id=0,var_off=(0x2; 0xfffc))"},
 -  /* Checked s>=0 */
 -  {10, 
"R5=inv(id=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2; 
0x7ffc))"},
 -  /* packet pointer + nonnegative (4n+2) */
 -  {12, 
"R6_w=pkt(id=1,off=0,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2;
 0x7ffc))"},
 -  {14, 
"R4=pkt(id=1,off=4,r=0,umin_value=2,umax_value=9223372036854775806,var_off=(0x2;
 0x7ffc))"},
 -  /* 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;
 0x7ffc))"},
 +  /* R5 bitwise operator &= on pointer prohibited */
}
},
{