* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2021-01-25 0:12 Stephen Rothwell
2021-01-25 16:09 ` Stanislav Fomichev
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Stephen Rothwell @ 2021-01-25 0:12 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, David Miller, Networking
Cc: Arjun Roy, Jakub Kicinski, Linux Kernel Mailing List,
Linux Next Mailing List, Stanislav Fomichev
[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
net/ipv4/tcp.c
between commit:
7eeba1706eba ("tcp: Add receive timestamp support for receive zerocopy.")
from the net-next tree and commit:
9cacf81f8161 ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE")
from the bpf-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/ipv4/tcp.c
index e1a17c6b473c,26aa923cf522..000000000000
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@@ -4160,18 -4098,13 +4160,20 @@@ static int do_tcp_getsockopt(struct soc
if (copy_from_user(&zc, optval, len))
return -EFAULT;
lock_sock(sk);
- err = tcp_zerocopy_receive(sk, &zc);
+ err = tcp_zerocopy_receive(sk, &zc, &tss);
+ err = BPF_CGROUP_RUN_PROG_GETSOCKOPT_KERN(sk, level, optname,
+ &zc, &len, err);
release_sock(sk);
- if (len >= offsetofend(struct tcp_zerocopy_receive, err))
- goto zerocopy_rcv_sk_err;
+ if (len >= offsetofend(struct tcp_zerocopy_receive, msg_flags))
+ goto zerocopy_rcv_cmsg;
switch (len) {
+ case offsetofend(struct tcp_zerocopy_receive, msg_flags):
+ goto zerocopy_rcv_cmsg;
+ case offsetofend(struct tcp_zerocopy_receive, msg_controllen):
+ case offsetofend(struct tcp_zerocopy_receive, msg_control):
+ case offsetofend(struct tcp_zerocopy_receive, flags):
+ case offsetofend(struct tcp_zerocopy_receive, copybuf_len):
+ case offsetofend(struct tcp_zerocopy_receive, copybuf_address):
case offsetofend(struct tcp_zerocopy_receive, err):
goto zerocopy_rcv_sk_err;
case offsetofend(struct tcp_zerocopy_receive, inq):
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2021-01-25 0:12 linux-next: manual merge of the bpf-next tree with the net-next tree Stephen Rothwell
@ 2021-01-25 16:09 ` Stanislav Fomichev
2021-01-25 18:03 ` Arjun Roy
2021-02-14 21:12 ` Stephen Rothwell
2 siblings, 0 replies; 27+ messages in thread
From: Stanislav Fomichev @ 2021-01-25 16:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, David Miller, Networking,
Arjun Roy, Jakub Kicinski, Linux Kernel Mailing List,
Linux Next Mailing List
Thanks, the merge resolution looks good to me!
On Sun, Jan 24, 2021 at 4:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> net/ipv4/tcp.c
>
> between commit:
>
> 7eeba1706eba ("tcp: Add receive timestamp support for receive zerocopy.")
>
> from the net-next tree and commit:
>
> 9cacf81f8161 ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE")
>
> from the bpf-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/ipv4/tcp.c
> index e1a17c6b473c,26aa923cf522..000000000000
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@@ -4160,18 -4098,13 +4160,20 @@@ static int do_tcp_getsockopt(struct soc
> if (copy_from_user(&zc, optval, len))
> return -EFAULT;
> lock_sock(sk);
> - err = tcp_zerocopy_receive(sk, &zc);
> + err = tcp_zerocopy_receive(sk, &zc, &tss);
> + err = BPF_CGROUP_RUN_PROG_GETSOCKOPT_KERN(sk, level, optname,
> + &zc, &len, err);
> release_sock(sk);
> - if (len >= offsetofend(struct tcp_zerocopy_receive, err))
> - goto zerocopy_rcv_sk_err;
> + if (len >= offsetofend(struct tcp_zerocopy_receive, msg_flags))
> + goto zerocopy_rcv_cmsg;
> switch (len) {
> + case offsetofend(struct tcp_zerocopy_receive, msg_flags):
> + goto zerocopy_rcv_cmsg;
> + case offsetofend(struct tcp_zerocopy_receive, msg_controllen):
> + case offsetofend(struct tcp_zerocopy_receive, msg_control):
> + case offsetofend(struct tcp_zerocopy_receive, flags):
> + case offsetofend(struct tcp_zerocopy_receive, copybuf_len):
> + case offsetofend(struct tcp_zerocopy_receive, copybuf_address):
> case offsetofend(struct tcp_zerocopy_receive, err):
> goto zerocopy_rcv_sk_err;
> case offsetofend(struct tcp_zerocopy_receive, inq):
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2021-01-25 0:12 linux-next: manual merge of the bpf-next tree with the net-next tree Stephen Rothwell
2021-01-25 16:09 ` Stanislav Fomichev
@ 2021-01-25 18:03 ` Arjun Roy
2021-02-14 21:12 ` Stephen Rothwell
2 siblings, 0 replies; 27+ messages in thread
From: Arjun Roy @ 2021-01-25 18:03 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, David Miller, Networking,
Jakub Kicinski, Linux Kernel Mailing List,
Linux Next Mailing List, Stanislav Fomichev
On Sun, Jan 24, 2021 at 4:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> net/ipv4/tcp.c
>
> between commit:
>
> 7eeba1706eba ("tcp: Add receive timestamp support for receive zerocopy.")
>
> from the net-next tree and commit:
>
> 9cacf81f8161 ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE")
>
> from the bpf-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.
>
The fix looks good, thank you.
-Arjun
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc net/ipv4/tcp.c
> index e1a17c6b473c,26aa923cf522..000000000000
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@@ -4160,18 -4098,13 +4160,20 @@@ static int do_tcp_getsockopt(struct soc
> if (copy_from_user(&zc, optval, len))
> return -EFAULT;
> lock_sock(sk);
> - err = tcp_zerocopy_receive(sk, &zc);
> + err = tcp_zerocopy_receive(sk, &zc, &tss);
> + err = BPF_CGROUP_RUN_PROG_GETSOCKOPT_KERN(sk, level, optname,
> + &zc, &len, err);
> release_sock(sk);
> - if (len >= offsetofend(struct tcp_zerocopy_receive, err))
> - goto zerocopy_rcv_sk_err;
> + if (len >= offsetofend(struct tcp_zerocopy_receive, msg_flags))
> + goto zerocopy_rcv_cmsg;
> switch (len) {
> + case offsetofend(struct tcp_zerocopy_receive, msg_flags):
> + goto zerocopy_rcv_cmsg;
> + case offsetofend(struct tcp_zerocopy_receive, msg_controllen):
> + case offsetofend(struct tcp_zerocopy_receive, msg_control):
> + case offsetofend(struct tcp_zerocopy_receive, flags):
> + case offsetofend(struct tcp_zerocopy_receive, copybuf_len):
> + case offsetofend(struct tcp_zerocopy_receive, copybuf_address):
> case offsetofend(struct tcp_zerocopy_receive, err):
> goto zerocopy_rcv_sk_err;
> case offsetofend(struct tcp_zerocopy_receive, inq):
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2021-01-25 0:12 linux-next: manual merge of the bpf-next tree with the net-next tree Stephen Rothwell
2021-01-25 16:09 ` Stanislav Fomichev
2021-01-25 18:03 ` Arjun Roy
@ 2021-02-14 21:12 ` Stephen Rothwell
2021-02-14 21:40 ` Arjun Roy
2 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2021-02-14 21:12 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, David Miller, Networking
Cc: Arjun Roy, Jakub Kicinski, Linux Kernel Mailing List,
Linux Next Mailing List, Stanislav Fomichev
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
Hi all,
On Mon, 25 Jan 2021 11:12:23 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> net/ipv4/tcp.c
>
> between commit:
>
> 7eeba1706eba ("tcp: Add receive timestamp support for receive zerocopy.")
>
> from the net-next tree and commit:
>
> 9cacf81f8161 ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE")
>
> from the bpf-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.
>
> diff --cc net/ipv4/tcp.c
> index e1a17c6b473c,26aa923cf522..000000000000
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@@ -4160,18 -4098,13 +4160,20 @@@ static int do_tcp_getsockopt(struct soc
> if (copy_from_user(&zc, optval, len))
> return -EFAULT;
> lock_sock(sk);
> - err = tcp_zerocopy_receive(sk, &zc);
> + err = tcp_zerocopy_receive(sk, &zc, &tss);
> + err = BPF_CGROUP_RUN_PROG_GETSOCKOPT_KERN(sk, level, optname,
> + &zc, &len, err);
> release_sock(sk);
> - if (len >= offsetofend(struct tcp_zerocopy_receive, err))
> - goto zerocopy_rcv_sk_err;
> + if (len >= offsetofend(struct tcp_zerocopy_receive, msg_flags))
> + goto zerocopy_rcv_cmsg;
> switch (len) {
> + case offsetofend(struct tcp_zerocopy_receive, msg_flags):
> + goto zerocopy_rcv_cmsg;
> + case offsetofend(struct tcp_zerocopy_receive, msg_controllen):
> + case offsetofend(struct tcp_zerocopy_receive, msg_control):
> + case offsetofend(struct tcp_zerocopy_receive, flags):
> + case offsetofend(struct tcp_zerocopy_receive, copybuf_len):
> + case offsetofend(struct tcp_zerocopy_receive, copybuf_address):
> case offsetofend(struct tcp_zerocopy_receive, err):
> goto zerocopy_rcv_sk_err;
> case offsetofend(struct tcp_zerocopy_receive, inq):
With the merge window about to open, this is a reminder that this
conflict still exists.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2021-02-14 21:12 ` Stephen Rothwell
@ 2021-02-14 21:40 ` Arjun Roy
2021-02-14 23:00 ` Stephen Rothwell
0 siblings, 1 reply; 27+ messages in thread
From: Arjun Roy @ 2021-02-14 21:40 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, David Miller, Networking,
Jakub Kicinski, Linux Kernel Mailing List,
Linux Next Mailing List, Stanislav Fomichev
On Sun, Feb 14, 2021 at 1:13 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 25 Jan 2021 11:12:23 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the bpf-next tree got a conflict in:
> >
> > net/ipv4/tcp.c
> >
> > between commit:
> >
> > 7eeba1706eba ("tcp: Add receive timestamp support for receive zerocopy.")
> >
> > from the net-next tree and commit:
> >
> > 9cacf81f8161 ("bpf: Remove extra lock_sock for TCP_ZEROCOPY_RECEIVE")
> >
> > from the bpf-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.
> >
> > diff --cc net/ipv4/tcp.c
> > index e1a17c6b473c,26aa923cf522..000000000000
> > --- a/net/ipv4/tcp.c
> > +++ b/net/ipv4/tcp.c
> > @@@ -4160,18 -4098,13 +4160,20 @@@ static int do_tcp_getsockopt(struct soc
> > if (copy_from_user(&zc, optval, len))
> > return -EFAULT;
> > lock_sock(sk);
> > - err = tcp_zerocopy_receive(sk, &zc);
> > + err = tcp_zerocopy_receive(sk, &zc, &tss);
> > + err = BPF_CGROUP_RUN_PROG_GETSOCKOPT_KERN(sk, level, optname,
> > + &zc, &len, err);
> > release_sock(sk);
> > - if (len >= offsetofend(struct tcp_zerocopy_receive, err))
> > - goto zerocopy_rcv_sk_err;
> > + if (len >= offsetofend(struct tcp_zerocopy_receive, msg_flags))
> > + goto zerocopy_rcv_cmsg;
> > switch (len) {
> > + case offsetofend(struct tcp_zerocopy_receive, msg_flags):
> > + goto zerocopy_rcv_cmsg;
> > + case offsetofend(struct tcp_zerocopy_receive, msg_controllen):
> > + case offsetofend(struct tcp_zerocopy_receive, msg_control):
> > + case offsetofend(struct tcp_zerocopy_receive, flags):
> > + case offsetofend(struct tcp_zerocopy_receive, copybuf_len):
> > + case offsetofend(struct tcp_zerocopy_receive, copybuf_address):
> > case offsetofend(struct tcp_zerocopy_receive, err):
> > goto zerocopy_rcv_sk_err;
> > case offsetofend(struct tcp_zerocopy_receive, inq):
>
> With the merge window about to open, this is a reminder that this
> conflict still exists.
>
Sorry, I was confused from the prior email. Is any action required at
the moment, or not?
Thanks,
-Arjun
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2021-02-14 21:40 ` Arjun Roy
@ 2021-02-14 23:00 ` Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2021-02-14 23:00 UTC (permalink / raw)
To: Arjun Roy
Cc: Daniel Borkmann, Alexei Starovoitov, David Miller, Networking,
Jakub Kicinski, Linux Kernel Mailing List,
Linux Next Mailing List, Stanislav Fomichev
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
Hi Arjun,
On Sun, 14 Feb 2021 13:40:38 -0800 Arjun Roy <arjunroy@google.com> wrote:
>
> Sorry, I was confused from the prior email. Is any action required at
> the moment, or not?
No. This is just something that the net-next and bpf-next maintainers
need to sort out when they merge their trees.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2023-12-17 23:29 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2023-12-17 23:29 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
David Miller, Jakub Kicinski, Paolo Abeni
Cc: bpf, Networking, Aleksander Lobakin, Larysa Zaremba,
Linux Kernel Mailing List, Linux Next Mailing List, Randy Dunlap
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
include/linux/skbuff.h
between commit:
bf873a800ac3 ("net: skbuff: fix spelling errors")
from the net-next tree and commit:
2ebe81c81435 ("net, xdp: Allow metadata > 32")
from the bpf-next tree.
I fixed it up (the latter removed a line that was updated by the former,
so I just removed it) 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] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2023-12-14 23:56 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2023-12-14 23:56 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
David Miller, Jakub Kicinski, Paolo Abeni
Cc: bpf, Networking, Larysa Zaremba, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/net/ynl/generated/netdev-user.c
between commit:
f7c0e362a25f ("tools: ynl: remove generated user space code from git")
from the net-next tree and commit:
e6795330f88b ("xdp: Add VLAN tag hint")
from the bpf-next tree.
I fixed it up (I just removed the file) 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] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2023-11-30 22:47 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2023-11-30 22:47 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
David Miller, Jakub Kicinski, Paolo Abeni
Cc: bpf, Networking, Linux Kernel Mailing List,
Linux Next Mailing List, Stanislav Fomichev
[-- Attachment #1: Type: text/plain, Size: 4538 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
Documentation/netlink/specs/netdev.yaml
between commit:
839ff60df3ab ("net: page_pool: add nlspec for basic access to page pools")
(and a few following)
from the net-next tree and commit:
48eb03dd2630 ("xsk: Add TX timestamp and TX checksum offload support")
from the bpf-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 Documentation/netlink/specs/netdev.yaml
index 20f75b7d3240,00439bcbd2e3..000000000000
--- a/Documentation/netlink/specs/netdev.yaml
+++ b/Documentation/netlink/specs/netdev.yaml
@@@ -86,112 -97,11 +97,117 @@@ attribute-sets
See Documentation/networking/xdp-rx-metadata.rst for more details.
type: u64
enum: xdp-rx-metadata
+ -
+ name: xsk-features
+ doc: Bitmask of enabled AF_XDP features.
+ type: u64
+ enum: xsk-flags
+ -
+ name: page-pool
+ attributes:
+ -
+ name: id
+ doc: Unique ID of a Page Pool instance.
+ type: uint
+ checks:
+ min: 1
+ max: u32-max
+ -
+ name: ifindex
+ doc: |
+ ifindex of the netdev to which the pool belongs.
+ May be reported as 0 if the page pool was allocated for a netdev
+ which got destroyed already (page pools may outlast their netdevs
+ because they wait for all memory to be returned).
+ type: u32
+ checks:
+ min: 1
+ max: s32-max
+ -
+ name: napi-id
+ doc: Id of NAPI using this Page Pool instance.
+ type: uint
+ checks:
+ min: 1
+ max: u32-max
+ -
+ name: inflight
+ type: uint
+ doc: |
+ Number of outstanding references to this page pool (allocated
+ but yet to be freed pages). Allocated pages may be held in
+ socket receive queues, driver receive ring, page pool recycling
+ ring, the page pool cache, etc.
+ -
+ name: inflight-mem
+ type: uint
+ doc: |
+ Amount of memory held by inflight pages.
+ -
+ name: detach-time
+ type: uint
+ doc: |
+ Seconds in CLOCK_BOOTTIME of when Page Pool was detached by
+ the driver. Once detached Page Pool can no longer be used to
+ allocate memory.
+ Page Pools wait for all the memory allocated from them to be freed
+ before truly disappearing. "Detached" Page Pools cannot be
+ "re-attached", they are just waiting to disappear.
+ Attribute is absent if Page Pool has not been detached, and
+ can still be used to allocate new memory.
+ -
+ name: page-pool-info
+ subset-of: page-pool
+ attributes:
+ -
+ name: id
+ -
+ name: ifindex
+ -
+ name: page-pool-stats
+ doc: |
+ Page pool statistics, see docs for struct page_pool_stats
+ for information about individual statistics.
+ attributes:
+ -
+ name: info
+ doc: Page pool identifying information.
+ type: nest
+ nested-attributes: page-pool-info
+ -
+ name: alloc-fast
+ type: uint
+ value: 8 # reserve some attr ids in case we need more metadata later
+ -
+ name: alloc-slow
+ type: uint
+ -
+ name: alloc-slow-high-order
+ type: uint
+ -
+ name: alloc-empty
+ type: uint
+ -
+ name: alloc-refill
+ type: uint
+ -
+ name: alloc-waive
+ type: uint
+ -
+ name: recycle-cached
+ type: uint
+ -
+ name: recycle-cache-full
+ type: uint
+ -
+ name: recycle-ring
+ type: uint
+ -
+ name: recycle-ring-full
+ type: uint
+ -
+ name: recycle-released-refcnt
+ type: uint
operations:
list:
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2023-04-13 16:12 broonie
@ 2023-04-13 16:31 ` Christian Ehrig
0 siblings, 0 replies; 27+ messages in thread
From: Christian Ehrig @ 2023-04-13 16:31 UTC (permalink / raw)
To: broonie
Cc: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking, Gavin Li, Jakub Kicinski, Linux Kernel Mailing List,
Linux Next Mailing List
On Thu, Apr 13, 2023 at 05:12:35PM +0100, broonie@kernel.org wrote:
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> include/net/ip_tunnels.h
>
> between commit:
>
> bc9d003dc48c3 ("ip_tunnel: Preserve pointer const in ip_tunnel_info_opts")
>
> from the net-next tree and commit:
>
> ac931d4cdec3d ("ipip,ip_tunnel,sit: Add FOU support for externally controlled ipip devices")
>
> from the bpf-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.
>
> diff --cc include/net/ip_tunnels.h
> index 255b32a90850a,7912f53caae0b..0000000000000
> --- a/include/net/ip_tunnels.h
> +++ b/include/net/ip_tunnels.h
> @@@ -66,15 -73,9 +73,16 @@@ struct ip_tunnel_encap
> #define IP_TUNNEL_OPTS_MAX \
> GENMASK((sizeof_field(struct ip_tunnel_info, \
> options_len) * BITS_PER_BYTE) - 1, 0)
> +
> +#define ip_tunnel_info_opts(info) \
> + _Generic(info, \
> + const struct ip_tunnel_info * : ((const void *)((info) + 1)),\
> + struct ip_tunnel_info * : ((void *)((info) + 1))\
> + )
> +
> struct ip_tunnel_info {
> struct ip_tunnel_key key;
> + struct ip_tunnel_encap encap;
> #ifdef CONFIG_DST_CACHE
> struct dst_cache dst_cache;
> #endif
This looks good to me. Thanks much.
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2023-04-13 16:12 broonie
2023-04-13 16:31 ` Christian Ehrig
0 siblings, 1 reply; 27+ messages in thread
From: broonie @ 2023-04-13 16:12 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf, Networking
Cc: Christian Ehrig, Gavin Li, Jakub Kicinski,
Linux Kernel Mailing List, Linux Next Mailing List
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
include/net/ip_tunnels.h
between commit:
bc9d003dc48c3 ("ip_tunnel: Preserve pointer const in ip_tunnel_info_opts")
from the net-next tree and commit:
ac931d4cdec3d ("ipip,ip_tunnel,sit: Add FOU support for externally controlled ipip devices")
from the bpf-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.
diff --cc include/net/ip_tunnels.h
index 255b32a90850a,7912f53caae0b..0000000000000
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@@ -66,15 -73,9 +73,16 @@@ struct ip_tunnel_encap
#define IP_TUNNEL_OPTS_MAX \
GENMASK((sizeof_field(struct ip_tunnel_info, \
options_len) * BITS_PER_BYTE) - 1, 0)
+
+#define ip_tunnel_info_opts(info) \
+ _Generic(info, \
+ const struct ip_tunnel_info * : ((const void *)((info) + 1)),\
+ struct ip_tunnel_info * : ((void *)((info) + 1))\
+ )
+
struct ip_tunnel_info {
struct ip_tunnel_key key;
+ struct ip_tunnel_encap encap;
#ifdef CONFIG_DST_CACHE
struct dst_cache dst_cache;
#endif
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2023-03-19 23:09 Stephen Rothwell
@ 2023-03-20 3:17 ` Bagas Sanjaya
0 siblings, 0 replies; 27+ messages in thread
From: Bagas Sanjaya @ 2023-03-20 3:17 UTC (permalink / raw)
To: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov,
Andrii Nakryiko, David Miller
Cc: bpf, Networking, Jakub Kicinski, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On Mon, Mar 20, 2023 at 10:09:22AM +1100, Stephen Rothwell wrote:
> diff --cc Documentation/bpf/bpf_devel_QA.rst
> index 7403f81c995c,e151e61dff38..000000000000
> --- a/Documentation/bpf/bpf_devel_QA.rst
> +++ b/Documentation/bpf/bpf_devel_QA.rst
> @@@ -684,8 -689,11 +689,7 @@@ when
>
>
> .. Links
> - .. _netdev-FAQ: https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> -.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
> .. _selftests:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
> -.. _Documentation/dev-tools/kselftest.rst:
> - https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
> -.. _Documentation/bpf/btf.rst: btf.rst
>
> Happy BPF hacking!
The resolution LGTM, thanks!
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2023-03-19 23:09 Stephen Rothwell
2023-03-20 3:17 ` Bagas Sanjaya
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2023-03-19 23:09 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, David Miller
Cc: bpf, Networking, Bagas Sanjaya, Jakub Kicinski,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
Documentation/bpf/bpf_devel_QA.rst
between commit:
d0ddf5065ffe ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net")
from the net-next tree and commit:
0f10f647f455 ("bpf, docs: Use internal linking for link to netdev subsystem doc")
from the bpf-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 Documentation/bpf/bpf_devel_QA.rst
index 7403f81c995c,e151e61dff38..000000000000
--- a/Documentation/bpf/bpf_devel_QA.rst
+++ b/Documentation/bpf/bpf_devel_QA.rst
@@@ -684,8 -689,11 +689,7 @@@ when
.. Links
- .. _netdev-FAQ: https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
-.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
.. _selftests:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
-.. _Documentation/dev-tools/kselftest.rst:
- https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
-.. _Documentation/bpf/btf.rst: btf.rst
Happy BPF hacking!
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2023-02-19 23:00 Stephen Rothwell
@ 2023-02-20 11:53 ` Alexander Lobakin
0 siblings, 0 replies; 27+ messages in thread
From: Alexander Lobakin @ 2023-02-20 11:53 UTC (permalink / raw)
To: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov,
Andrii Nakryiko, David S. Miller
Cc: bpf, Networking, Alexander Lobakin, Linux Kernel Mailing List,
Linux Next Mailing List
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 20 Feb 2023 10:00:56 +1100
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> drivers/net/ethernet/intel/ice/ice_xsk.c
>
> between commit:
>
> 675f176b4dcc ("Merge ra.kernel.org:/pub/scm/linux/kernel/git/netdev/net")
>
> from the net-next tree and commit:
>
> aa1d3faf71a6 ("ice: Robustify cleaning/completing XDP Tx buffers")
>
> from the bpf-next tree.
>
> I fixed it up (I guessed - 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.
>
Hi,
the correct fix will be as follows (at least my Git yielded me this when
merging net-next with bpf-next).
Strange movements from Git, but basically the resolution is to pick the
latest ice_xsk.c from bpf-next and then manually carry Larysa's fix[0]
for @xsk_frames (she initially did it for bpf-next, so it's easier for
us to resolve this conflict).
Much thanks for noticing and notifying.
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=1f090494170ea298530cf1285fb8d078e355b4c0
Thanks,
Olek
---
diff --cc drivers/net/ethernet/intel/ice/ice_xsk.c
index b2d96ae5668c,917c75e530ca..1fcfa07c205b
--- a/drivers/net/ethernet/intel/ice/ice_xsk.c
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.c
@@@ -629,29 -613,28 +614,30 @@@ static void ice_clean_xdp_irq_zc(struc
last_rs = xdp_ring->next_to_use ? xdp_ring->next_to_use - 1 : cnt - 1;
tx_desc = ICE_TX_DESC(xdp_ring, last_rs);
- if ((tx_desc->cmd_type_offset_bsz &
- cpu_to_le64(ICE_TX_DESC_DTYPE_DESC_DONE))) {
+ if (tx_desc->cmd_type_offset_bsz &
+ cpu_to_le64(ICE_TX_DESC_DTYPE_DESC_DONE)) {
if (last_rs >= ntc)
- xsk_frames = last_rs - ntc + 1;
+ completed_frames = last_rs - ntc + 1;
else
- xsk_frames = last_rs + cnt - ntc + 1;
+ completed_frames = last_rs + cnt - ntc + 1;
}
- if (!xsk_frames)
+ if (!completed_frames)
return;
- if (likely(!xdp_ring->xdp_tx_active))
+ if (likely(!xdp_ring->xdp_tx_active)) {
+ xsk_frames = completed_frames;
goto skip;
+ }
ntc = xdp_ring->next_to_clean;
- for (i = 0; i < xsk_frames; i++) {
+ for (i = 0; i < completed_frames; i++) {
tx_buf = &xdp_ring->tx_buf[ntc];
- if (tx_buf->raw_buf) {
- ice_clean_xdp_tx_buf(xdp_ring, tx_buf);
- tx_buf->raw_buf = NULL;
+ if (tx_buf->type == ICE_TX_BUF_XSK_TX) {
+ tx_buf->type = ICE_TX_BUF_EMPTY;
+ xsk_buff_free(tx_buf->xdp);
+ xdp_ring->xdp_tx_active--;
} else {
xsk_frames++;
}
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2023-02-19 23:00 Stephen Rothwell
2023-02-20 11:53 ` Alexander Lobakin
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2023-02-19 23:00 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, David S. Miller
Cc: bpf, Networking, Alexander Lobakin, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
drivers/net/ethernet/intel/ice/ice_xsk.c
between commit:
675f176b4dcc ("Merge ra.kernel.org:/pub/scm/linux/kernel/git/netdev/net")
from the net-next tree and commit:
aa1d3faf71a6 ("ice: Robustify cleaning/completing XDP Tx buffers")
from the bpf-next tree.
I fixed it up (I guessed - 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 drivers/net/ethernet/intel/ice/ice_xsk.c
index b2d96ae5668c,917c75e530ca..000000000000
--- a/drivers/net/ethernet/intel/ice/ice_xsk.c
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.c
@@@ -629,29 -613,28 +629,30 @@@ static void ice_clean_xdp_irq_zc(struc
last_rs = xdp_ring->next_to_use ? xdp_ring->next_to_use - 1 : cnt - 1;
tx_desc = ICE_TX_DESC(xdp_ring, last_rs);
- if (tx_desc->cmd_type_offset_bsz &
- cpu_to_le64(ICE_TX_DESC_DTYPE_DESC_DONE)) {
+ if ((tx_desc->cmd_type_offset_bsz &
+ cpu_to_le64(ICE_TX_DESC_DTYPE_DESC_DONE))) {
if (last_rs >= ntc)
- xsk_frames = last_rs - ntc + 1;
+ completed_frames = last_rs - ntc + 1;
else
- xsk_frames = last_rs + cnt - ntc + 1;
+ completed_frames = last_rs + cnt - ntc + 1;
}
- if (!xsk_frames)
+ if (!completed_frames)
return;
- if (likely(!xdp_ring->xdp_tx_active))
+ if (likely(!xdp_ring->xdp_tx_active)) {
+ xsk_frames = completed_frames;
goto skip;
+ }
ntc = xdp_ring->next_to_clean;
- for (i = 0; i < xsk_frames; i++) {
+ for (i = 0; i < completed_frames; i++) {
tx_buf = &xdp_ring->tx_buf[ntc];
- if (tx_buf->raw_buf) {
+ if (tx_buf->type == ICE_TX_BUF_XSK_TX) {
+ tx_buf->type = ICE_TX_BUF_EMPTY;
- xsk_buff_free(tx_buf->xdp);
- xdp_ring->xdp_tx_active--;
+ ice_clean_xdp_tx_buf(xdp_ring, tx_buf);
+ tx_buf->raw_buf = NULL;
} else {
xsk_frames++;
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2023-02-06 23:19 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2023-02-06 23:19 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, David Miller
Cc: bpf, Networking, Kumar Kartikeya Dwivedi,
Linux Kernel Mailing List, Linux Next Mailing List,
Lorenzo Bianconi, Marek Majtyka, Michal Swiatkowski, Tony Nguyen
[-- Attachment #1: Type: text/plain, Size: 3751 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
drivers/net/ethernet/intel/ice/ice_main.c
between commit:
5b246e533d01 ("ice: split probe into smaller functions")
from the net-next tree and commit:
66c0e13ad236 ("drivers: net: turn on XDP features")
from the bpf-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 drivers/net/ethernet/intel/ice/ice_main.c
index 433298d0014a,074b0e6d0e2d..000000000000
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@@ -4485,116 -4619,6 +4501,118 @@@ static int ice_register_netdev(struct i
return -EIO;
err = register_netdev(vsi->netdev);
+ if (err)
+ return err;
+
+ set_bit(ICE_VSI_NETDEV_REGISTERED, vsi->state);
+ netif_carrier_off(vsi->netdev);
+ netif_tx_stop_all_queues(vsi->netdev);
+
+ return 0;
+}
+
+static void ice_unregister_netdev(struct ice_vsi *vsi)
+{
+ if (!vsi || !vsi->netdev)
+ return;
+
+ unregister_netdev(vsi->netdev);
+ clear_bit(ICE_VSI_NETDEV_REGISTERED, vsi->state);
+}
+
+/**
+ * ice_cfg_netdev - Allocate, configure and register a netdev
+ * @vsi: the VSI associated with the new netdev
+ *
+ * Returns 0 on success, negative value on failure
+ */
+static int ice_cfg_netdev(struct ice_vsi *vsi)
+{
+ struct ice_netdev_priv *np;
+ struct net_device *netdev;
+ u8 mac_addr[ETH_ALEN];
+
+ netdev = alloc_etherdev_mqs(sizeof(*np), vsi->alloc_txq,
+ vsi->alloc_rxq);
+ if (!netdev)
+ return -ENOMEM;
+
+ set_bit(ICE_VSI_NETDEV_ALLOCD, vsi->state);
+ vsi->netdev = netdev;
+ np = netdev_priv(netdev);
+ np->vsi = vsi;
+
+ ice_set_netdev_features(netdev);
++ netdev->xdp_features = NETDEV_XDP_ACT_BASIC | NETDEV_XDP_ACT_REDIRECT |
++ NETDEV_XDP_ACT_XSK_ZEROCOPY;
+ ice_set_ops(netdev);
+
+ if (vsi->type == ICE_VSI_PF) {
+ SET_NETDEV_DEV(netdev, ice_pf_to_dev(vsi->back));
+ ether_addr_copy(mac_addr, vsi->port_info->mac.perm_addr);
+ eth_hw_addr_set(netdev, mac_addr);
+ }
+
+ netdev->priv_flags |= IFF_UNICAST_FLT;
+
+ /* Setup netdev TC information */
+ ice_vsi_cfg_netdev_tc(vsi, vsi->tc_cfg.ena_tc);
+
+ netdev->max_mtu = ICE_MAX_MTU;
+
+ return 0;
+}
+
+static void ice_decfg_netdev(struct ice_vsi *vsi)
+{
+ clear_bit(ICE_VSI_NETDEV_ALLOCD, vsi->state);
+ free_netdev(vsi->netdev);
+ vsi->netdev = NULL;
+}
+
+static int ice_start_eth(struct ice_vsi *vsi)
+{
+ int err;
+
+ err = ice_init_mac_fltr(vsi->back);
+ if (err)
+ return err;
+
+ rtnl_lock();
+ err = ice_vsi_open(vsi);
+ rtnl_unlock();
+
+ return err;
+}
+
+static int ice_init_eth(struct ice_pf *pf)
+{
+ struct ice_vsi *vsi = ice_get_main_vsi(pf);
+ int err;
+
+ if (!vsi)
+ return -EINVAL;
+
+ /* init channel list */
+ INIT_LIST_HEAD(&vsi->ch_list);
+
+ err = ice_cfg_netdev(vsi);
+ if (err)
+ return err;
+ /* Setup DCB netlink interface */
+ ice_dcbnl_setup(vsi);
+
+ err = ice_init_mac_fltr(pf);
+ if (err)
+ goto err_init_mac_fltr;
+
+ err = ice_devlink_create_pf_port(pf);
+ if (err)
+ goto err_devlink_create_pf_port;
+
+ SET_NETDEV_DEVLINK_PORT(vsi->netdev, &pf->devlink_port);
+
+ err = ice_register_netdev(vsi);
if (err)
goto err_register_netdev;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2022-05-11 1:10 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2022-05-11 1:10 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, David Miller
Cc: bpf, Networking, Linux Kernel Mailing List,
Linux Next Mailing List, Paolo Abeni, Tiezhu Yang, Tonghao Zhang
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
net/core/sysctl_net_core.c
between commits:
bd8a53675c0d ("net: sysctl: use shared sysctl macro")
4c7f24f857c7 ("net: sysctl: introduce sysctl SYSCTL_THREE")
from the net-next tree and commit:
f922c8972fb5 ("net: sysctl: Use SYSCTL_TWO instead of &two")
from the bpf-next tree.
I fixed it up (bd8a53675c0d and f922c8972fb5 delete the same line) 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] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2020-08-03 3:05 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2020-08-03 3:05 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Roopa Prabhu,
Andrii Nakryiko
[-- Attachment #1: Type: text/plain, Size: 4107 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
net/core/dev.c
between commit:
829eb208e80d ("rtnetlink: add support for protodown reason")
from the net-next tree and commits:
7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in net_device")
aa8d3a716b59 ("bpf, xdp: Add bpf_link-based XDP attachment API")
from the bpf-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/dev.c
index f7ef0f5c5569,c8b911b10187..000000000000
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@@ -8715,54 -8712,75 +8711,100 @@@ int dev_change_proto_down_generic(struc
}
EXPORT_SYMBOL(dev_change_proto_down_generic);
+/**
+ * dev_change_proto_down_reason - proto down reason
+ *
+ * @dev: device
+ * @mask: proto down mask
+ * @value: proto down value
+ */
+void dev_change_proto_down_reason(struct net_device *dev, unsigned long mask,
+ u32 value)
+{
+ int b;
+
+ if (!mask) {
+ dev->proto_down_reason = value;
+ } else {
+ for_each_set_bit(b, &mask, 32) {
+ if (value & (1 << b))
+ dev->proto_down_reason |= BIT(b);
+ else
+ dev->proto_down_reason &= ~BIT(b);
+ }
+ }
+}
+EXPORT_SYMBOL(dev_change_proto_down_reason);
+
- u32 __dev_xdp_query(struct net_device *dev, bpf_op_t bpf_op,
- enum bpf_netdev_command cmd)
+ struct bpf_xdp_link {
+ struct bpf_link link;
+ struct net_device *dev; /* protected by rtnl_lock, no refcnt held */
+ int flags;
+ };
+
+ static enum bpf_xdp_mode dev_xdp_mode(u32 flags)
{
- struct netdev_bpf xdp;
+ if (flags & XDP_FLAGS_HW_MODE)
+ return XDP_MODE_HW;
+ if (flags & XDP_FLAGS_DRV_MODE)
+ return XDP_MODE_DRV;
+ return XDP_MODE_SKB;
+ }
- if (!bpf_op)
- return 0;
+ static bpf_op_t dev_xdp_bpf_op(struct net_device *dev, enum bpf_xdp_mode mode)
+ {
+ switch (mode) {
+ case XDP_MODE_SKB:
+ return generic_xdp_install;
+ case XDP_MODE_DRV:
+ case XDP_MODE_HW:
+ return dev->netdev_ops->ndo_bpf;
+ default:
+ return NULL;
+ };
+ }
- memset(&xdp, 0, sizeof(xdp));
- xdp.command = cmd;
+ static struct bpf_xdp_link *dev_xdp_link(struct net_device *dev,
+ enum bpf_xdp_mode mode)
+ {
+ return dev->xdp_state[mode].link;
+ }
+
+ static struct bpf_prog *dev_xdp_prog(struct net_device *dev,
+ enum bpf_xdp_mode mode)
+ {
+ struct bpf_xdp_link *link = dev_xdp_link(dev, mode);
+
+ if (link)
+ return link->link.prog;
+ return dev->xdp_state[mode].prog;
+ }
+
+ u32 dev_xdp_prog_id(struct net_device *dev, enum bpf_xdp_mode mode)
+ {
+ struct bpf_prog *prog = dev_xdp_prog(dev, mode);
- /* Query must always succeed. */
- WARN_ON(bpf_op(dev, &xdp) < 0 && cmd == XDP_QUERY_PROG);
+ return prog ? prog->aux->id : 0;
+ }
- return xdp.prog_id;
+ static void dev_xdp_set_link(struct net_device *dev, enum bpf_xdp_mode mode,
+ struct bpf_xdp_link *link)
+ {
+ dev->xdp_state[mode].link = link;
+ dev->xdp_state[mode].prog = NULL;
}
- static int dev_xdp_install(struct net_device *dev, bpf_op_t bpf_op,
- struct netlink_ext_ack *extack, u32 flags,
- struct bpf_prog *prog)
+ static void dev_xdp_set_prog(struct net_device *dev, enum bpf_xdp_mode mode,
+ struct bpf_prog *prog)
+ {
+ dev->xdp_state[mode].link = NULL;
+ dev->xdp_state[mode].prog = prog;
+ }
+
+ static int dev_xdp_install(struct net_device *dev, enum bpf_xdp_mode mode,
+ bpf_op_t bpf_op, struct netlink_ext_ack *extack,
+ u32 flags, struct bpf_prog *prog)
{
- bool non_hw = !(flags & XDP_FLAGS_HW_MODE);
- struct bpf_prog *prev_prog = NULL;
struct netdev_bpf xdp;
int err;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2020-07-21 2:16 Stephen Rothwell
@ 2020-07-21 8:53 ` Lorenzo Bianconi
0 siblings, 0 replies; 27+ messages in thread
From: Lorenzo Bianconi @ 2020-07-21 8:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller,
Linux Next Mailing List, Jesper Dangaard Brouer
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
[...]
> diff --cc include/net/xdp.h
> index d3005bef812f,5be0d4d65b94..000000000000
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@@ -104,15 -98,12 +104,21 @@@ struct xdp_frame
> struct net_device *dev_rx; /* used by cpumap */
> };
>
> +static inline struct skb_shared_info *
> +xdp_get_shared_info_from_frame(struct xdp_frame *frame)
> +{
> + void *data_hard_start = frame->data - frame->headroom - sizeof(*frame);
> +
> + return (struct skb_shared_info *)(data_hard_start + frame->frame_sz -
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
> +}
> +
> + struct xdp_cpumap_stats {
> + unsigned int redirect;
> + unsigned int pass;
> + unsigned int drop;
> + };
Hi Stephen,
the fix is correct, thanks and sorry for the noise. I will point out possible
conflicts next time.
Regards,
Lorenzo
> +
> /* Clear kernel pointers in xdp_frame */
> static inline void xdp_scrub_frame(struct xdp_frame *frame)
> {
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2020-07-21 2:16 Stephen Rothwell
2020-07-21 8:53 ` Lorenzo Bianconi
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2020-07-21 2:16 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Lorenzo Bianconi, Jesper Dangaard Brouer
[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
include/net/xdp.h
between commit:
2f0bc54ba9a8 ("xdp: introduce xdp_get_shared_info_from_{buff, frame} utility routines")
from the net-next tree and commits:
9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap")
28b1520ebf81 ("bpf: cpumap: Implement XDP_REDIRECT for eBPF programs attached to map entries")
from the bpf-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/xdp.h
index d3005bef812f,5be0d4d65b94..000000000000
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@@ -104,15 -98,12 +104,21 @@@ struct xdp_frame
struct net_device *dev_rx; /* used by cpumap */
};
+static inline struct skb_shared_info *
+xdp_get_shared_info_from_frame(struct xdp_frame *frame)
+{
+ void *data_hard_start = frame->data - frame->headroom - sizeof(*frame);
+
+ return (struct skb_shared_info *)(data_hard_start + frame->frame_sz -
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
+}
+
+ struct xdp_cpumap_stats {
+ unsigned int redirect;
+ unsigned int pass;
+ unsigned int drop;
+ };
+
/* Clear kernel pointers in xdp_frame */
static inline void xdp_scrub_frame(struct xdp_frame *frame)
{
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2020-07-21 2:12 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2020-07-21 2:12 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Christoph Hellwig, Jakub Sitnicki
[-- Attachment #1: Type: text/plain, Size: 5862 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
include/linux/filter.h
between commit:
4d295e546115 ("net: simplify cBPF setsockopt compat handling")
from the net-next tree and commits:
e9ddbb7707ff ("bpf: Introduce SK_LOOKUP program type with a dedicated attach point")
1559b4aa1db4 ("inet: Run SK_LOOKUP BPF program on socket lookup")
1122702f0267 ("inet6: Run SK_LOOKUP BPF program on socket lookup")
from the bpf-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/filter.h
index 4d049c8e1fbe,8252572db918..000000000000
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@@ -1276,6 -1278,151 +1276,153 @@@ struct bpf_sockopt_kern
s32 retval;
};
+ struct bpf_sk_lookup_kern {
+ u16 family;
+ u16 protocol;
+ struct {
+ __be32 saddr;
+ __be32 daddr;
+ } v4;
+ struct {
+ const struct in6_addr *saddr;
+ const struct in6_addr *daddr;
+ } v6;
+ __be16 sport;
+ u16 dport;
+ struct sock *selected_sk;
+ bool no_reuseport;
+ };
+
+ extern struct static_key_false bpf_sk_lookup_enabled;
+
+ /* Runners for BPF_SK_LOOKUP programs to invoke on socket lookup.
+ *
+ * Allowed return values for a BPF SK_LOOKUP program are SK_PASS and
+ * SK_DROP. Their meaning is as follows:
+ *
+ * SK_PASS && ctx.selected_sk != NULL: use selected_sk as lookup result
+ * SK_PASS && ctx.selected_sk == NULL: continue to htable-based socket lookup
+ * SK_DROP : terminate lookup with -ECONNREFUSED
+ *
+ * This macro aggregates return values and selected sockets from
+ * multiple BPF programs according to following rules in order:
+ *
+ * 1. If any program returned SK_PASS and a non-NULL ctx.selected_sk,
+ * macro result is SK_PASS and last ctx.selected_sk is used.
+ * 2. If any program returned SK_DROP return value,
+ * macro result is SK_DROP.
+ * 3. Otherwise result is SK_PASS and ctx.selected_sk is NULL.
+ *
+ * Caller must ensure that the prog array is non-NULL, and that the
+ * array as well as the programs it contains remain valid.
+ */
+ #define BPF_PROG_SK_LOOKUP_RUN_ARRAY(array, ctx, func) \
+ ({ \
+ struct bpf_sk_lookup_kern *_ctx = &(ctx); \
+ struct bpf_prog_array_item *_item; \
+ struct sock *_selected_sk = NULL; \
+ bool _no_reuseport = false; \
+ struct bpf_prog *_prog; \
+ bool _all_pass = true; \
+ u32 _ret; \
+ \
+ migrate_disable(); \
+ _item = &(array)->items[0]; \
+ while ((_prog = READ_ONCE(_item->prog))) { \
+ /* restore most recent selection */ \
+ _ctx->selected_sk = _selected_sk; \
+ _ctx->no_reuseport = _no_reuseport; \
+ \
+ _ret = func(_prog, _ctx); \
+ if (_ret == SK_PASS && _ctx->selected_sk) { \
+ /* remember last non-NULL socket */ \
+ _selected_sk = _ctx->selected_sk; \
+ _no_reuseport = _ctx->no_reuseport; \
+ } else if (_ret == SK_DROP && _all_pass) { \
+ _all_pass = false; \
+ } \
+ _item++; \
+ } \
+ _ctx->selected_sk = _selected_sk; \
+ _ctx->no_reuseport = _no_reuseport; \
+ migrate_enable(); \
+ _all_pass || _selected_sk ? SK_PASS : SK_DROP; \
+ })
+
+ static inline bool bpf_sk_lookup_run_v4(struct net *net, int protocol,
+ const __be32 saddr, const __be16 sport,
+ const __be32 daddr, const u16 dport,
+ struct sock **psk)
+ {
+ struct bpf_prog_array *run_array;
+ struct sock *selected_sk = NULL;
+ bool no_reuseport = false;
+
+ rcu_read_lock();
+ run_array = rcu_dereference(net->bpf.run_array[NETNS_BPF_SK_LOOKUP]);
+ if (run_array) {
+ struct bpf_sk_lookup_kern ctx = {
+ .family = AF_INET,
+ .protocol = protocol,
+ .v4.saddr = saddr,
+ .v4.daddr = daddr,
+ .sport = sport,
+ .dport = dport,
+ };
+ u32 act;
+
+ act = BPF_PROG_SK_LOOKUP_RUN_ARRAY(run_array, ctx, BPF_PROG_RUN);
+ if (act == SK_PASS) {
+ selected_sk = ctx.selected_sk;
+ no_reuseport = ctx.no_reuseport;
+ } else {
+ selected_sk = ERR_PTR(-ECONNREFUSED);
+ }
+ }
+ rcu_read_unlock();
+ *psk = selected_sk;
+ return no_reuseport;
+ }
+
+ #if IS_ENABLED(CONFIG_IPV6)
+ static inline bool bpf_sk_lookup_run_v6(struct net *net, int protocol,
+ const struct in6_addr *saddr,
+ const __be16 sport,
+ const struct in6_addr *daddr,
+ const u16 dport,
+ struct sock **psk)
+ {
+ struct bpf_prog_array *run_array;
+ struct sock *selected_sk = NULL;
+ bool no_reuseport = false;
+
+ rcu_read_lock();
+ run_array = rcu_dereference(net->bpf.run_array[NETNS_BPF_SK_LOOKUP]);
+ if (run_array) {
+ struct bpf_sk_lookup_kern ctx = {
+ .family = AF_INET6,
+ .protocol = protocol,
+ .v6.saddr = saddr,
+ .v6.daddr = daddr,
+ .sport = sport,
+ .dport = dport,
+ };
+ u32 act;
+
+ act = BPF_PROG_SK_LOOKUP_RUN_ARRAY(run_array, ctx, BPF_PROG_RUN);
+ if (act == SK_PASS) {
+ selected_sk = ctx.selected_sk;
+ no_reuseport = ctx.no_reuseport;
+ } else {
+ selected_sk = ERR_PTR(-ECONNREFUSED);
+ }
+ }
+ rcu_read_unlock();
+ *psk = selected_sk;
+ return no_reuseport;
+ }
+ #endif /* IS_ENABLED(CONFIG_IPV6) */
+
+int copy_bpf_fprog_from_user(struct sock_fprog *dst, void __user *src, int len);
+
#endif /* __LINUX_FILTER_H__ */
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2019-11-24 23:58 Stephen Rothwell
@ 2019-11-25 1:19 ` Alexei Starovoitov
0 siblings, 0 replies; 27+ messages in thread
From: Alexei Starovoitov @ 2019-11-25 1:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller,
Linux Next Mailing List, Linux Kernel Mailing List,
Jakub Kicinski
On Sun, Nov 24, 2019 at 3:58 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> kernel/bpf/syscall.c
>
> between commit:
>
> 84bb46cd6228 ("Revert "bpf: Emit audit messages upon successful prog load and unload"")
>
> from the net-next tree and commit:
>
> 8793e6b23b1e ("bpf: Move bpf_free_used_maps into sleepable section")
>
> from the bpf-next tree.
argh. I wonder whether individual reverts would have
helped git to avoid such conflict.
Anyhow I've rebased bpf-next on top of net-next to avoid this mess.
There was only one Fixes tag that I adjusted manually.
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2019-11-24 23:58 Stephen Rothwell
2019-11-25 1:19 ` Alexei Starovoitov
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2019-11-24 23:58 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jakub Kicinski
[-- Attachment #1: Type: text/plain, Size: 3382 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
kernel/bpf/syscall.c
between commit:
84bb46cd6228 ("Revert "bpf: Emit audit messages upon successful prog load and unload"")
from the net-next tree and commit:
8793e6b23b1e ("bpf: Move bpf_free_used_maps into sleepable section")
from the bpf-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/syscall.c
index 4ae52eb05f41,bb002f15b32a..000000000000
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@@ -23,14 -23,16 +23,15 @@@
#include <linux/timekeeping.h>
#include <linux/ctype.h>
#include <linux/nospec.h>
-#include <linux/audit.h>
#include <uapi/linux/btf.h>
- #define IS_FD_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PROG_ARRAY || \
- (map)->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY || \
- (map)->map_type == BPF_MAP_TYPE_CGROUP_ARRAY || \
- (map)->map_type == BPF_MAP_TYPE_ARRAY_OF_MAPS)
+ #define IS_FD_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY || \
+ (map)->map_type == BPF_MAP_TYPE_CGROUP_ARRAY || \
+ (map)->map_type == BPF_MAP_TYPE_ARRAY_OF_MAPS)
+ #define IS_FD_PROG_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PROG_ARRAY)
#define IS_FD_HASH(map) ((map)->map_type == BPF_MAP_TYPE_HASH_OF_MAPS)
- #define IS_FD_MAP(map) (IS_FD_ARRAY(map) || IS_FD_HASH(map))
+ #define IS_FD_MAP(map) (IS_FD_ARRAY(map) || IS_FD_PROG_ARRAY(map) || \
+ IS_FD_HASH(map))
#define BPF_OBJ_FLAG_MASK (BPF_F_RDONLY | BPF_F_WRONLY)
@@@ -1302,25 -1307,34 +1306,6 @@@ static int find_prog_type(enum bpf_prog
return 0;
}
- /* drop refcnt on maps used by eBPF program and free auxilary data */
- static void free_used_maps(struct bpf_prog_aux *aux)
- {
- enum bpf_cgroup_storage_type stype;
- int i;
-enum bpf_event {
- BPF_EVENT_LOAD,
- BPF_EVENT_UNLOAD,
-};
--
- for_each_cgroup_storage_type(stype) {
- if (!aux->cgroup_storage[stype])
- continue;
- bpf_cgroup_storage_release(aux->prog,
- aux->cgroup_storage[stype]);
- }
-static const char * const bpf_event_audit_str[] = {
- [BPF_EVENT_LOAD] = "LOAD",
- [BPF_EVENT_UNLOAD] = "UNLOAD",
-};
--
- for (i = 0; i < aux->used_map_cnt; i++)
- bpf_map_put(aux->used_maps[i]);
-static void bpf_audit_prog(const struct bpf_prog *prog, enum bpf_event event)
-{
- bool has_task_context = event == BPF_EVENT_LOAD;
- struct audit_buffer *ab;
--
- kfree(aux->used_maps);
- if (audit_enabled == AUDIT_OFF)
- return;
- ab = audit_log_start(audit_context(), GFP_ATOMIC, AUDIT_BPF);
- if (unlikely(!ab))
- return;
- if (has_task_context)
- audit_log_task(ab);
- audit_log_format(ab, "%sprog-id=%u event=%s",
- has_task_context ? " " : "",
- prog->aux->id, bpf_event_audit_str[event]);
- audit_log_end(ab);
--}
--
int __bpf_prog_charge(struct user_struct *user, u32 pages)
{
unsigned long memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2019-07-01 4:47 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2019-07-01 4:47 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Maxim Mikityanskiy, Tariq Toukan, Tal Gilboa, Saeed Mahameed
[-- Attachment #1: Type: text/plain, Size: 3834 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
drivers/net/ethernet/mellanox/mlx5/core/en_main.c
between commit:
8960b38932be ("linux/dim: Rename externally used net_dim members")
from the net-next tree and commits:
db05815b36cb ("net/mlx5e: Add XSK zero-copy support")
0a06382fa406 ("net/mlx5e: Encapsulate open/close queues into a function")
from the bpf-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 drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 1085040675ae,67b562c7f8a1..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -1567,10 -1602,8 +1602,8 @@@ static void mlx5e_destroy_cq(struct mlx
mlx5_core_destroy_cq(cq->mdev, &cq->mcq);
}
- static int mlx5e_open_cq(struct mlx5e_channel *c,
- struct dim_cq_moder moder,
- struct mlx5e_cq_param *param,
- struct mlx5e_cq *cq)
-int mlx5e_open_cq(struct mlx5e_channel *c, struct net_dim_cq_moder moder,
++int mlx5e_open_cq(struct mlx5e_channel *c, struct dim_cq_moder moder,
+ struct mlx5e_cq_param *param, struct mlx5e_cq *cq)
{
struct mlx5_core_dev *mdev = c->mdev;
int err;
@@@ -1767,45 -1800,12 +1800,12 @@@ static void mlx5e_free_xps_cpumask(stru
free_cpumask_var(c->xps_cpumask);
}
- static int mlx5e_open_channel(struct mlx5e_priv *priv, int ix,
- struct mlx5e_params *params,
- struct mlx5e_channel_param *cparam,
- struct mlx5e_channel **cp)
+ static int mlx5e_open_queues(struct mlx5e_channel *c,
+ struct mlx5e_params *params,
+ struct mlx5e_channel_param *cparam)
{
- int cpu = cpumask_first(mlx5_comp_irq_get_affinity_mask(priv->mdev, ix));
- struct net_dim_cq_moder icocq_moder = {0, 0};
+ struct dim_cq_moder icocq_moder = {0, 0};
- struct net_device *netdev = priv->netdev;
- struct mlx5e_channel *c;
- unsigned int irq;
int err;
- int eqn;
-
- err = mlx5_vector2eqn(priv->mdev, ix, &eqn, &irq);
- if (err)
- return err;
-
- c = kvzalloc_node(sizeof(*c), GFP_KERNEL, cpu_to_node(cpu));
- if (!c)
- return -ENOMEM;
-
- c->priv = priv;
- c->mdev = priv->mdev;
- c->tstamp = &priv->tstamp;
- c->ix = ix;
- c->cpu = cpu;
- c->pdev = priv->mdev->device;
- c->netdev = priv->netdev;
- c->mkey_be = cpu_to_be32(priv->mdev->mlx5e_res.mkey.key);
- c->num_tc = params->num_tc;
- c->xdp = !!params->xdp_prog;
- c->stats = &priv->channel_stats[ix].ch;
- c->irq_desc = irq_to_desc(irq);
-
- err = mlx5e_alloc_xps_cpumask(c, params);
- if (err)
- goto err_free_channel;
-
- netif_napi_add(netdev, &c->napi, mlx5e_napi_poll, 64);
err = mlx5e_open_cq(c, icocq_moder, &cparam->icosq_cq, &c->icosq.cq);
if (err)
@@@ -2150,12 -2230,12 +2230,12 @@@ void mlx5e_build_ico_cq_param(struct ml
mlx5e_build_common_cq_param(priv, param);
- param->cq_period_mode = NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE;
+ param->cq_period_mode = DIM_CQ_PERIOD_MODE_START_FROM_EQE;
}
- static void mlx5e_build_icosq_param(struct mlx5e_priv *priv,
- u8 log_wq_size,
- struct mlx5e_sq_param *param)
+ void mlx5e_build_icosq_param(struct mlx5e_priv *priv,
+ u8 log_wq_size,
+ struct mlx5e_sq_param *param)
{
void *sqc = param->sqc;
void *wq = MLX5_ADDR_OF(sqc, sqc, wq);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2018-11-21 23:36 Stephen Rothwell
0 siblings, 0 replies; 27+ messages in thread
From: Stephen Rothwell @ 2018-11-21 23:36 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Paolo Abeni,
Nikita V. Shirokov
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/testing/selftests/bpf/Makefile
between commit:
bd8e1afe6436 ("selftests: add dummy xdp test helper")
from the net-next tree and commit:
b1957c92eba5 ("bpf: adding tests for map_in_map helpber in libbpf")
from the bpf-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 4a54236475ae,43157bd89165..000000000000
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@@ -38,7 -39,7 +39,7 @@@ TEST_GEN_FILES = test_pkt_access.o test
get_cgroup_id_kern.o socket_cookie_prog.o test_select_reuseport_kern.o \
test_skb_cgroup_id_kern.o bpf_flow.o netcnt_prog.o \
test_sk_lookup_kern.o test_xdp_vlan.o test_queue_map.o test_stack_map.o \
- xdp_dummy.o
- test_map_in_map.o
++ xdp_dummy.o test_map_in_map.o
# Order correspond to 'make run_tests' order
TEST_PROGS := test_kmod.sh \
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net-next tree
2018-04-26 0:49 Stephen Rothwell
@ 2018-04-26 7:56 ` Daniel Borkmann
0 siblings, 0 replies; 27+ messages in thread
From: Daniel Borkmann @ 2018-04-26 7:56 UTC (permalink / raw)
To: Stephen Rothwell, Alexei Starovoitov, Networking, David Miller
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Anders Roxell
On 04/26/2018 02:49 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> tools/testing/selftests/bpf/.gitignore
>
> between commit:
>
> 0abf854d7cbb ("selftests: bpf: update .gitignore with missing generated files")
>
> from the net-next tree and commit:
>
> b6fd9cf796e6 ("selftests: bpf: update .gitignore with missing file")
>
> from the bpf-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.
Looks good, thanks!
^ permalink raw reply [flat|nested] 27+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net-next tree
@ 2018-04-26 0:49 Stephen Rothwell
2018-04-26 7:56 ` Daniel Borkmann
0 siblings, 1 reply; 27+ messages in thread
From: Stephen Rothwell @ 2018-04-26 0:49 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Anders Roxell
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/testing/selftests/bpf/.gitignore
between commit:
0abf854d7cbb ("selftests: bpf: update .gitignore with missing generated files")
from the net-next tree and commit:
b6fd9cf796e6 ("selftests: bpf: update .gitignore with missing file")
from the bpf-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/.gitignore
index 5e1ab2f0eb79,da19f0562bf8..000000000000
--- a/tools/testing/selftests/bpf/.gitignore
+++ b/tools/testing/selftests/bpf/.gitignore
@@@ -12,6 -12,4 +12,7 @@@ test_tcpbpf_use
test_verifier_log
feature
test_libbpf_open
+ test_btf
+test_sock
+test_sock_addr
+urandom_read
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2023-12-17 23:30 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-25 0:12 linux-next: manual merge of the bpf-next tree with the net-next tree Stephen Rothwell
2021-01-25 16:09 ` Stanislav Fomichev
2021-01-25 18:03 ` Arjun Roy
2021-02-14 21:12 ` Stephen Rothwell
2021-02-14 21:40 ` Arjun Roy
2021-02-14 23:00 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2023-12-17 23:29 Stephen Rothwell
2023-12-14 23:56 Stephen Rothwell
2023-11-30 22:47 Stephen Rothwell
2023-04-13 16:12 broonie
2023-04-13 16:31 ` Christian Ehrig
2023-03-19 23:09 Stephen Rothwell
2023-03-20 3:17 ` Bagas Sanjaya
2023-02-19 23:00 Stephen Rothwell
2023-02-20 11:53 ` Alexander Lobakin
2023-02-06 23:19 Stephen Rothwell
2022-05-11 1:10 Stephen Rothwell
2020-08-03 3:05 Stephen Rothwell
2020-07-21 2:16 Stephen Rothwell
2020-07-21 8:53 ` Lorenzo Bianconi
2020-07-21 2:12 Stephen Rothwell
2019-11-24 23:58 Stephen Rothwell
2019-11-25 1:19 ` Alexei Starovoitov
2019-07-01 4:47 Stephen Rothwell
2018-11-21 23:36 Stephen Rothwell
2018-04-26 0:49 Stephen Rothwell
2018-04-26 7:56 ` Daniel Borkmann
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).