* [PATCH iproute2-next] iplink: add support for reporting multiple XDP programs
From: Jakub Kicinski @ 2018-07-13 20:43 UTC (permalink / raw)
To: alexei.starovoitov, daniel, dsahern
Cc: stephen, netdev, oss-drivers, Jakub Kicinski
Kernel now supports attaching XDP programs in the driver
and hardware at the same time. Print that information
correctly.
In case there are multiple programs attached kernel will
not provide IFLA_XDP_PROG_ID, so don't expect it to be
there (this also improves the printing for very old kernels
slightly, as it avoids unnecessary "prog/xdp" line).
In short mode preserve the current outputs but don't print
IDs if there are multiple.
[...]
6: netdevsim0: <BROADCAST,NOARP> mtu 1500 xdpoffload/id:11 qdisc [...]
[...]
[...]
6: netdevsim0: <BROADCAST,NOARP> mtu 1500 xdpmulti qdisc [...]
[...]
ip link output will keep using prog/xdp prefix if only one program
is attached, but can also print multiple program lines:
prog/xdp id 8 tag fc7a51d1a693a99e jited
vs:
prog/xdpdrv id 8 tag fc7a51d1a693a99e jited
prog/xdpoffload id 9 tag fc7a51d1a693a99e
JSON output gains a new array called "attached" which will
contain the full list of attached programs along with their
attachment modes:
"xdp": {
"mode": 3,
"prog": {
"id": 11,
"tag": "fc7a51d1a693a99e",
"jited": 0
},
"attached": [ {
"mode": 3,
"prog": {
"id": 11,
"tag": "fc7a51d1a693a99e",
"jited": 0
}
} ]
},
In case there are multiple programs attached the general "xdp"
section will not contain program information:
"xdp": {
"mode": 4,
"attached": [ {
"mode": 1,
"prog": {
"id": 10,
"tag": "fc7a51d1a693a99e",
"jited": 1
}
},{
"mode": 3,
"prog": {
"id": 11,
"tag": "fc7a51d1a693a99e",
"jited": 0
}
} ]
},
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
ip/iplink_xdp.c | 65 ++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 53 insertions(+), 12 deletions(-)
diff --git a/ip/iplink_xdp.c b/ip/iplink_xdp.c
index dd4fd1fd3a3b..0328bc01a981 100644
--- a/ip/iplink_xdp.c
+++ b/ip/iplink_xdp.c
@@ -91,6 +91,18 @@ int xdp_parse(int *argc, char ***argv, struct iplink_req *req,
return 0;
}
+static void xdp_dump_json_one(struct rtattr *tb[IFLA_XDP_MAX + 1], __u32 attr,
+ __u8 mode)
+{
+ if (!tb[attr])
+ return;
+
+ open_json_object(NULL);
+ print_uint(PRINT_JSON, "mode", NULL, mode);
+ bpf_dump_prog_info(NULL, rta_getattr_u32(tb[attr]));
+ close_json_object();
+}
+
static void xdp_dump_json(struct rtattr *tb[IFLA_XDP_MAX + 1])
{
__u32 prog_id = 0;
@@ -104,13 +116,40 @@ static void xdp_dump_json(struct rtattr *tb[IFLA_XDP_MAX + 1])
print_uint(PRINT_JSON, "mode", NULL, mode);
if (prog_id)
bpf_dump_prog_info(NULL, prog_id);
+
+ open_json_array(PRINT_JSON, "attached");
+ xdp_dump_json_one(tb, IFLA_XDP_SKB_PROG_ID, XDP_ATTACHED_SKB);
+ xdp_dump_json_one(tb, IFLA_XDP_DRV_PROG_ID, XDP_ATTACHED_DRV);
+ xdp_dump_json_one(tb, IFLA_XDP_HW_PROG_ID, XDP_ATTACHED_HW);
+ close_json_array(PRINT_JSON, NULL);
+
close_json_object();
}
+static void xdp_dump_prog_one(FILE *fp, struct rtattr *tb[IFLA_XDP_MAX + 1],
+ __u32 attr, bool link, bool details, char *pfx)
+{
+ __u32 prog_id;
+
+ if (!tb[attr])
+ return;
+
+ prog_id = rta_getattr_u32(tb[attr]);
+ if (!details) {
+ if (prog_id && !link && attr == IFLA_XDP_PROG_ID)
+ fprintf(fp, "/id:%u", prog_id);
+ return;
+ }
+
+ if (prog_id) {
+ fprintf(fp, "%s prog/xdp%s ", _SL_, pfx);
+ bpf_dump_prog_info(fp, prog_id);
+ }
+}
+
void xdp_dump(FILE *fp, struct rtattr *xdp, bool link, bool details)
{
struct rtattr *tb[IFLA_XDP_MAX + 1];
- __u32 prog_id = 0;
__u8 mode;
parse_rtattr_nested(tb, IFLA_XDP_MAX, xdp);
@@ -124,27 +163,29 @@ void xdp_dump(FILE *fp, struct rtattr *xdp, bool link, bool details)
else if (is_json_context())
return details ? (void)0 : xdp_dump_json(tb);
else if (details && link)
- fprintf(fp, "%s prog/xdp", _SL_);
+ /* don't print mode */;
else if (mode == XDP_ATTACHED_DRV)
fprintf(fp, "xdp");
else if (mode == XDP_ATTACHED_SKB)
fprintf(fp, "xdpgeneric");
else if (mode == XDP_ATTACHED_HW)
fprintf(fp, "xdpoffload");
+ else if (mode == XDP_ATTACHED_MULTI)
+ fprintf(fp, "xdpmulti");
else
fprintf(fp, "xdp[%u]", mode);
- if (tb[IFLA_XDP_PROG_ID])
- prog_id = rta_getattr_u32(tb[IFLA_XDP_PROG_ID]);
- if (!details) {
- if (prog_id && !link)
- fprintf(fp, "/id:%u", prog_id);
- fprintf(fp, " ");
- return;
+ xdp_dump_prog_one(fp, tb, IFLA_XDP_PROG_ID, link, details, "");
+
+ if (mode == XDP_ATTACHED_MULTI) {
+ xdp_dump_prog_one(fp, tb, IFLA_XDP_SKB_PROG_ID, link, details,
+ "generic");
+ xdp_dump_prog_one(fp, tb, IFLA_XDP_DRV_PROG_ID, link, details,
+ "drv");
+ xdp_dump_prog_one(fp, tb, IFLA_XDP_HW_PROG_ID, link, details,
+ "offload");
}
- if (prog_id) {
+ if (!details || !link)
fprintf(fp, " ");
- bpf_dump_prog_info(fp, prog_id);
- }
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] net: ip6_gre: get ipv6hdr after skb_cow_head()
From: Gregory Rose @ 2018-07-13 20:45 UTC (permalink / raw)
To: Prashant Bhole, David S . Miller
Cc: Alexey Kuznetsov, Hideaki YOSHIFUJI, William Tu, netdev
In-Reply-To: <20180713054050.5656-1-bhole_prashant_q7@lab.ntt.co.jp>
On 7/12/2018 10:40 PM, Prashant Bhole wrote:
> A KASAN:use-after-free bug was found related to ip6-erspan
> while running selftests/net/ip6_gre_headroom.sh
>
> It happens because of following sequence:
> - ipv6hdr pointer is obtained from skb
> - skb_cow_head() is called, skb->head memory is reallocated
> - old data is accessed using ipv6hdr pointer
>
> skb_cow_head() call was added in e41c7c68ea77 ("ip6erspan: make sure
> enough headroom at xmit."), but looking at the history there was a
> chance of similar bug because gre_handle_offloads() and pskb_trim()
> can also reallocate skb->head memory. Fixes tag points to commit
> which introduced possibility of this bug.
>
> This patch moves ipv6hdr pointer assignment after skb_cow_head() call.
>
> Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Good catch.
LGTM
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
> ---
> net/ipv6/ip6_gre.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index 367177786e34..fc7dd3a04360 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -927,7 +927,6 @@ static netdev_tx_t ip6gre_tunnel_xmit(struct sk_buff *skb,
> static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb,
> struct net_device *dev)
> {
> - struct ipv6hdr *ipv6h = ipv6_hdr(skb);
> struct ip6_tnl *t = netdev_priv(dev);
> struct dst_entry *dst = skb_dst(skb);
> struct net_device_stats *stats;
> @@ -1012,6 +1011,8 @@ static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb,
> goto tx_err;
> }
> } else {
> + struct ipv6hdr *ipv6h = ipv6_hdr(skb);
> +
> switch (skb->protocol) {
> case htons(ETH_P_IP):
> memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
^ permalink raw reply
* Re: [PATCH iproute2-next 0/9] TC more JSON support
From: David Ahern @ 2018-07-13 20:48 UTC (permalink / raw)
To: Stephen Hemminger, netdev
Cc: Stephen Hemminger, Jiri Pirko, Jakub Kicinski, Cong Wang,
Jamal Hadi Salim
In-Reply-To: <20180709194856.18922-1-stephen@networkplumber.org>
On 7/9/18 3:48 PM, Stephen Hemminger wrote:
> From: Stephen Hemminger <sthemmin@microsoft.com>
>
> Update core of TC command and library to do more JSON.
> Most of this patch set is about getting tc utility functions
> to be more friendly to the json_print infrastructure.
>
> Stephen Hemminger (9):
> tc: use JSON in error handling
> tc: use const char in util
> tc: convert stats print to json
> tc/cbq: use sprint_rate
> tc/util: remove print_rate
> tc/util: remove unused print_size
> tc/util: remove unused print_time
> tc/util: add print helpers for JSON
> tc/sfq: add json support
>
> tc/q_cbq.c | 15 ++++-----
> tc/q_sfq.c | 65 +++++++++++++++++++++---------------
> tc/tc.c | 19 ++++++-----
> tc/tc_util.c | 94 +++++++++++++++++++++++++++-------------------------
> tc/tc_util.h | 11 +++---
> 5 files changed, 109 insertions(+), 95 deletions(-)
>
I'd prefer some tc folks to take a look at the json output and verify
everything is good.
Jamal, Jiri, Jakub, Cong, others?
There is a second set with 30 patches as well.
^ permalink raw reply
* Re: [PATCH iproute2-next] iplink: add support for reporting multiple XDP programs
From: Stephen Hemminger @ 2018-07-13 20:59 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: alexei.starovoitov, daniel, dsahern, netdev, oss-drivers
In-Reply-To: <20180713204359.1161-1-jakub.kicinski@netronome.com>
On Fri, 13 Jul 2018 13:43:59 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
>
> +static void xdp_dump_prog_one(FILE *fp, struct rtattr *tb[IFLA_XDP_MAX + 1],
> + __u32 attr, bool link, bool details, char *pfx)
> +{
> + __u32 prog_id;
> +
> + if (!tb[attr])
> + return;
> +
> + prog_id = rta_getattr_u32(tb[attr]);
> + if (!details) {
> + if (prog_id && !link && attr == IFLA_XDP_PROG_ID)
> + fprintf(fp, "/id:%u", prog_id);
> + return;
> + }
> +
> + if (prog_id) {
> + fprintf(fp, "%s prog/xdp%s ", _SL_, pfx);
> + bpf_dump_prog_info(fp, prog_id);
> + }
Maybe const char *pfx.
I prefer to not use "printf(fp," and use print_string(PRINT_FP, NULL, "%s", ...)
because otherwise you end up mixing strings and json format output in the
same result.
You should be able to do
tc -j ...
and always get valid JSON output.
One quick way to test json validation is to pipe it into python:
tc -j ... | python -mjson.tool
^ permalink raw reply
* Re: [PATCH bpf-next v5 0/3] bpf: btf: print bpftool map data with btf
From: Okash Khawaja @ 2018-07-13 21:35 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jakub Kicinski, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <e938c861-b341-22f0-7e82-215a27e2b74f@iogearbox.net>
On Fri, Jul 13, 2018 at 10:49:01PM +0200, Daniel Borkmann wrote:
> On 07/12/2018 05:30 AM, Jakub Kicinski wrote:
> > On Wed, 11 Jul 2018 20:08:03 -0700, Okash Khawaja wrote:
> >> Hi,
> >>
> >> Here are the changes from v4:
> >>
> >> patch 2:
> >>
> >> - sort headers in btf_dumper.c
> >> - remove extra parentheses
> >> - include asm/byteorder.h
> >> - compile error when big and small endian bitfields macro undefined
> >
> > Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> Hmm, strange, by accident I just noticed that only your bpf fix ever made
> it to patchwork, Okash.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_project_netdev_list_-3Fsubmitter-3D74458-26state-3D-2A&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=4wHrS7MHHFLZe_WCJwRVhA&m=wkiBQFYWPyiN9WONHLY0WiZxcOwNRhXaMMLIE551mCA&s=RggQzClRdkwawboGLPgPXHOdUtYffxeOwlcBlFru-P4&e=
>
> Potentially because you've sent with attachments which got dropped on
> the list?
interesting because i send all patches using quilt mail, the same way i
sent bpf fix. i can try git-send-email.
also i dropped Acked-by as i changed patch versions. is it common thing
to do? or should i keep the Acked-by?
>
> Could you properly submit the series again, and retaining Jakub's Reviewed-by
> tag to the patches?
>
> Thanks,
> Daniel
^ permalink raw reply
* Re: [PATCH iproute2-next] iplink: add support for reporting multiple XDP programs
From: Jakub Kicinski @ 2018-07-13 21:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexei.starovoitov, daniel, dsahern, netdev, oss-drivers
In-Reply-To: <20180713135941.3791c3ff@xeon-e3>
On Fri, 13 Jul 2018 13:59:41 -0700, Stephen Hemminger wrote:
> On Fri, 13 Jul 2018 13:43:59 -0700
> Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
>
> >
> > +static void xdp_dump_prog_one(FILE *fp, struct rtattr *tb[IFLA_XDP_MAX + 1],
> > + __u32 attr, bool link, bool details, char *pfx)
> > +{
> > + __u32 prog_id;
> > +
> > + if (!tb[attr])
> > + return;
> > +
> > + prog_id = rta_getattr_u32(tb[attr]);
> > + if (!details) {
> > + if (prog_id && !link && attr == IFLA_XDP_PROG_ID)
> > + fprintf(fp, "/id:%u", prog_id);
> > + return;
> > + }
> > +
> > + if (prog_id) {
> > + fprintf(fp, "%s prog/xdp%s ", _SL_, pfx);
> > + bpf_dump_prog_info(fp, prog_id);
> > + }
>
> Maybe const char *pfx.
Will do! Looking again at this code, I think I will also do this:
diff --git a/ip/iplink_xdp.c b/ip/iplink_xdp.c
index 0328bc01a981..68629834cc00 100644
--- a/ip/iplink_xdp.c
+++ b/ip/iplink_xdp.c
@@ -121,6 +121,12 @@ static void xdp_dump_json(struct rtattr *tb[IFLA_XDP_MAX + 1])
xdp_dump_json_one(tb, IFLA_XDP_SKB_PROG_ID, XDP_ATTACHED_SKB);
xdp_dump_json_one(tb, IFLA_XDP_DRV_PROG_ID, XDP_ATTACHED_DRV);
xdp_dump_json_one(tb, IFLA_XDP_HW_PROG_ID, XDP_ATTACHED_HW);
+ /* Older kernel - use IFLA_XDP_PROG_ID */
+ if (tb[IFLA_XDP_PROG_ID] &&
+ !(tb[IFLA_XDP_ATTACHED_SKB] ||
+ tb[IFLA_XDP_ATTACHED_DRV] ||
+ tb[IFLA_XDP_ATTACHED_HW]))
+ xdp_dump_json_one(tb, IFLA_XDP_PROG_ID, mode);
close_json_array(PRINT_JSON, NULL);
close_json_object();
So that on older kernels we will still be able to depend on the
contents of the "attached" array, even if kernel does not know to
report program per-mode, yet.
> I prefer to not use "printf(fp," and use print_string(PRINT_FP, NULL, "%s", ...)
> because otherwise you end up mixing strings and json format output in the
> same result.
>
> You should be able to do
> tc -j ...
> and always get valid JSON output.
>
> One quick way to test json validation is to pipe it into python:
> tc -j ... | python -mjson.tool
Note that XDP has separate print functions for plain text and JSON, and
the flow gets separated early on:
mode = rta_getattr_u8(tb[IFLA_XDP_ATTACHED]);
if (mode == XDP_ATTACHED_NONE)
return;
else if (is_json_context())
return details ? (void)0 : xdp_dump_json(tb);
... non-JSON handling follows...
The use of fprintfs is therefore okay. Do you have a preference for
using the wrapper, even if fprintf is safe? It's brevity vs
consistency, I guess. We'd need a separate patch for that, 'cause I'm
not touching all the fprintfs in the file, anyway.
^ permalink raw reply related
* Re: [PATCH net-next] net: ipmr: add support for passing full packet on wrong vif
From: David Miller @ 2018-07-13 21:21 UTC (permalink / raw)
To: nikolay; +Cc: netdev, sharpd
In-Reply-To: <20180713091643.22745-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Fri, 13 Jul 2018 12:16:43 +0300
> This patch adds support for IGMPMSG_WRVIFWHOLE which is used to pass
> full packet and real vif id when the incoming interface is wrong.
> While the RP and FHR are setting up state we need to be sending the
> registers encapsulated with all the data inside otherwise we lose it.
> The RP then decapsulates it and forwards it to the interested parties.
> Currently with WRONGVIF we can only be sending empty register packets
> and will lose that data.
> This behaviour can be enabled by using MRT_PIM with
> val == IGMPMSG_WRVIFWHOLE. This doesn't prevent IGMPMSG_WRONGVIF from
> happening, it happens in addition to it, also it is controlled by the same
> throttling parameters as WRONGVIF (i.e. 1 packet per 3 seconds currently).
> Both messages are generated to keep backwards compatibily and avoid
> breaking someone who was enabling MRT_PIM with val == 4, since any
> positive val is accepted and treated the same.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 3/3] rds: Extend RDS API for IPv6 support
From: David Miller @ 2018-07-13 21:25 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, sowmini.varadhan, rds-devel
In-Reply-To: <fb57cba4b05802465eb3ef083315e270095d3b1c.1531477918.git.ka-cheong.poon@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Fri, 13 Jul 2018 04:02:59 -0700
> @@ -52,7 +52,7 @@
> #define RDS_RECVERR 5
> #define RDS_CONG_MONITOR 6
> #define RDS_GET_MR_FOR_DEST 7
> -#define SO_RDS_TRANSPORT 8
> +#define SO_RDS_TRANSPORT 9
There is no way you can change this value without breaking
applications.
^ permalink raw reply
* Re: [PATCH net] skbuff: Unconditionally copy pfmemalloc in __skb_clone()
From: David Miller @ 2018-07-13 21:28 UTC (permalink / raw)
To: sbrivio; +Cc: sd, mgorman, eric.dumazet, ptalbert, netdev
In-Reply-To: <bf1a276ec28a2a0e6b94b43eec3975e64d1c63ae.1531479681.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Fri, 13 Jul 2018 13:21:07 +0200
> Commit 8b7008620b84 ("net: Don't copy pfmemalloc flag in
> __copy_skb_header()") introduced a different handling for the
> pfmemalloc flag in copy and clone paths.
>
> In __skb_clone(), now, the flag is set only if it was set in the
> original skb, but not cleared if it wasn't. This is wrong and
> might lead to socket buffers being flagged with pfmemalloc even
> if the skb data wasn't allocated from pfmemalloc reserves. Copy
> the flag instead of ORing it.
>
> Reported-by: Sabrina Dubroca <sd@queasysnail.net>
> Fixes: 8b7008620b84 ("net: Don't copy pfmemalloc flag in __copy_skb_header()")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH iproute2-next 0/9] TC more JSON support
From: Jakub Kicinski @ 2018-07-13 21:29 UTC (permalink / raw)
To: David Ahern
Cc: Stephen Hemminger, netdev, Stephen Hemminger, Jiri Pirko,
Cong Wang, Jamal Hadi Salim
In-Reply-To: <9ad5c235-8c66-4a62-0517-af4ae6bdddac@gmail.com>
On Fri, 13 Jul 2018 16:48:28 -0400, David Ahern wrote:
> On 7/9/18 3:48 PM, Stephen Hemminger wrote:
> > From: Stephen Hemminger <sthemmin@microsoft.com>
> >
> > Update core of TC command and library to do more JSON.
> > Most of this patch set is about getting tc utility functions
> > to be more friendly to the json_print infrastructure.
> >
> > Stephen Hemminger (9):
> > tc: use JSON in error handling
> > tc: use const char in util
> > tc: convert stats print to json
> > tc/cbq: use sprint_rate
> > tc/util: remove print_rate
> > tc/util: remove unused print_size
> > tc/util: remove unused print_time
> > tc/util: add print helpers for JSON
> > tc/sfq: add json support
> >
> > tc/q_cbq.c | 15 ++++-----
> > tc/q_sfq.c | 65 +++++++++++++++++++++---------------
> > tc/tc.c | 19 ++++++-----
> > tc/tc_util.c | 94 +++++++++++++++++++++++++++-------------------------
> > tc/tc_util.h | 11 +++---
> > 5 files changed, 109 insertions(+), 95 deletions(-)
> >
>
> I'd prefer some tc folks to take a look at the json output and verify
> everything is good.
>
> Jamal, Jiri, Jakub, Cong, others?
>
> There is a second set with 30 patches as well.
AFAIK the 31 patches supersede this set? I only have tests that use
JSON for MQ and RED qdiscs, and those work fine with the v2 applied!
^ permalink raw reply
* Re: pull-request: bpf 2018-07-13
From: David Miller @ 2018-07-13 21:32 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180713154058.24349-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 13 Jul 2018 17:40:58 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Fix AF_XDP TX error reporting before final kernel release such that it
> becomes consistent between copy mode and zero-copy, from Magnus.
>
> 2) Fix three different syzkaller reported issues: oob due to ld_abs
> rewrite with too large offset, another oob in l3 based skb test run
> and a bug leaving mangled prog in subprog JITing error path, from Daniel.
>
> 3) Fix BTF handling for bitfield extraction on big endian, from Okash.
>
> 4) Fix a missing linux/errno.h include in cgroup/BPF found by kbuild bot,
> from Roman.
>
> 5) Fix xdp2skb_meta.sh sample by using just command names instead of
> absolute paths for tc and ip and allow them to be redefined, from Taeung.
>
> 6) Fix availability probing for BPF seg6 helpers before final kernel ships
> so they can be detected at prog load time, from Mathieu.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
^ permalink raw reply
* Re: [PATCH] tcp: allow user to create repair socket without window probes
From: Eric Dumazet @ 2018-07-13 21:42 UTC (permalink / raw)
To: Stefan Baranoff
Cc: David Miller, netdev, Andrey Vagin, Pavel Emelyanov, Eric Dumazet,
Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <CAHzKxpbnNOSafBEJRoS3RsL4rywLrgEdhyQqVppBbATwfT4OrQ@mail.gmail.com>
On 07/13/2018 02:36 PM, Stefan Baranoff wrote:
>
> Before I put my foot in my mouth one more time and end up on everyone's naughty list - can someone help guide me on a couple of questions?
>
> What is the correct way to resubmit this, just as a simple v2 or does it need cherry picked out and moved over to net-next somehow?
> Part of the fix is to remember to include my header file changes to increase the size of repair from 1 bit to 2 in include/linux/tcp.h - does that make this patch's change require any additional work, notices, etc?
Patch was officially merged, so there wont be a V2.
Please send a patch to fix the issue on top of current David net tree
Thanks.
^ permalink raw reply
* Re: [PATCH v4 net-next 19/19] net/mlx5e: Kconfig, mutually exclude compilation of TLS and IPsec accel
From: David Miller @ 2018-07-13 21:44 UTC (permalink / raw)
To: borisp; +Cc: netdev, davejwatson, aviadye, saeedm
In-Reply-To: <4c27cdb3-bb8f-02b7-477e-e82d113b2b6d@mellanox.com>
From: Boris Pismenny <borisp@mellanox.com>
Date: Fri, 13 Jul 2018 16:03:01 -0400
> We currently have no devices that support both TLS and IPsec using the
> accel framework
I read this the first time, and this is not what I am objecting to.
The compile time limitation is the problem, not the run time
limitation.
> Looking a bit more carefully at the code. We don't need this patch,
> because we still don't have a deviceID for both TLS and IPsec, so the
> problematic flow cannot happen. So we've just been over zealous
> here. I'll remove this patch and send a v5.
Ok, thanks.
^ permalink raw reply
* Re: [PATCH net-next v6 01/11] net: sched: use rcu for action cookie update
From: Cong Wang @ 2018-07-13 21:51 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jiri Pirko, Alexei Starovoitov, Daniel Borkmann,
Yevgeny Kliteynik, Jiri Pirko
In-Reply-To: <vbf4lh3clfy.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Fri, Jul 13, 2018 at 6:30 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>
>
> On Fri 13 Jul 2018 at 03:52, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Thu, Jul 5, 2018 at 7:24 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> >>
> >> Implement functions to atomically update and free action cookie
> >> using rcu mechanism.
> >
> > Without stating any reason..... Is this even a changelog?
>
> Yes, it is.
What do you expect in a changelog generally? Repeating what
your code does? Thanks but we don't even want to read any code
unless the need of this code is reasonably justified.
Can we at least agree you have no justification for this change
in this changelog? Or you believe this patch is as trivial as
a white space change which doesn't need a justification?
>
> >
> >>
> >> Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> >
> > Dear Marcelo, how did it pass your review? See below:
> >
> >
> >> +static void tcf_set_action_cookie(struct tc_cookie __rcu **old_cookie,
> >> + struct tc_cookie *new_cookie)
> >> +{
> >> + struct tc_cookie *old;
> >> +
> >> + old = xchg(old_cookie, new_cookie);
> >
> >
> > This is an incorrect use of RCU, obviously should be rcu_assign_pointer()
> > here.
>
> Could you please explain your concern in more details? Similar pattern
> is already widely used in kernel for re-assigning rcu pointers. For
My reasoning is too simple: search whatisRCU.txt for "xchg",
I find nothing. :)
Here is the link:
https://www.kernel.org/doc/Documentation/RCU/whatisRCU.txt
Of course, both xchg() and rcu_assign_pointer() are aimed to make
an assignment of a pointer. But even without looking into their
implementations, there must be a reason for rcu_assign_pointer() to
exist, right? Can we agree or you believe rcu_assign_pointer() can
be replaced by xchg() and removed finally?
This also means you need to justify your pick of xchg() in your
changelog where there is nothing literally.
> example, Eric Dumazet uses it in 1c0d32fde5bd ("net_sched:
> gen_estimator: complete rewrite of rate estimators"):
>
> void gen_kill_estimator(struct net_rate_estimator __rcu **rate_est)
> {
> struct net_rate_estimator *est;
>
> est = xchg((__force struct net_rate_estimator **)rate_est, NULL);
> if (est) {
> del_timer_sync(&est->timer);
> kfree_rcu(est, rcu);
> }
> }
In this case, *I think* the only reason is the burden of the API
gen_kill_estimator(). It aims to be a core API for both netfilter and
net_sched, therefore it _has to_ provide a wrapper for its users,
because otherwise each user has to repeat rcu_assign_pointer()
+ del_timer_sync() + kfree_rcu(), just a matter of duplication.
Apparently this rule does NOT apply to your case, where
tcf_set_action_cookie() is merely a static function called by two
users in the same C file, and without anything but a call_rcu().
>
> Tom Herbert uses same idiom in a8c5f90fb59a ("ip_tunnel: Ops
> registration for secondary encap (fou, gue)"):
>
> int ip_tunnel_encap_add_ops(const struct ip_tunnel_encap_ops *ops,
> unsigned int num)
> {
> if (num >= MAX_IPTUN_ENCAP_OPS)
> return -ERANGE;
>
> return !cmpxchg((const struct ip_tunnel_encap_ops **)
> &iptun_encaps[num],
> NULL, ops) ? 0 : -1;
> }
cmpxchg() is completely different with xchg(), first of all.
In this case, its caller expects if this cmpxchg() fails or not.
How this could be even related to your case given
tcf_set_action_cookie() returns void?
>
> Again, Eric uses xchg to re-assign rcu pointer in 45f6fad84cc3 ("ipv6:
> add complete rcu protection around np->opt"):
>
> struct ipv6_txoptions *ipv6_update_options(struct sock *sk,
> struct ipv6_txoptions *opt)
> {
> if (inet_sk(sk)->is_icsk) {
> if (opt &&
> !((1 << sk->sk_state) & (TCPF_LISTEN | TCPF_CLOSE)) &&
> inet_sk(sk)->inet_daddr != LOOPBACK4_IPV6) {
> struct inet_connection_sock *icsk = inet_csk(sk);
> icsk->icsk_ext_hdr_len = opt->opt_flen + opt->opt_nflen;
> icsk->icsk_sync_mss(sk, icsk->icsk_pmtu_cookie);
> }
> }
> opt = xchg((__force struct ipv6_txoptions **)&inet6_sk(sk)->opt,
> opt);
> sk_dst_reset(sk);
In this case, it is the caller's requirement. The callers of
ipv6_update_options() want to get the old pointer and do
something about it:
opt = ipv6_update_options(sk, opt);
if (opt) {
atomic_sub(opt->tot_len, &sk->sk_omem_alloc);
txopt_put(opt);
}
It should be functionally equivalent to saving the old pointer
before a rcu_assign_pointer().
So, this does NOT apply to your case either, you only call
call_rcu() and the callers require nothing.
>
> return opt;
> }
>
> >
> >
> >> @@ -65,10 +83,7 @@ static void free_tcf(struct tc_action *p)
> >> free_percpu(p->cpu_bstats);
> >> free_percpu(p->cpu_qstats);
> >>
> >> - if (p->act_cookie) {
> >> - kfree(p->act_cookie->data);
> >> - kfree(p->act_cookie);
> >> - }
> >> + tcf_set_action_cookie(&p->act_cookie, NULL);
> >
> > So, this is called in free_tcf(), where the action is already
> > invisible from readers so it is ready to be freed.
> >
> > The question is:
> >
> > If the action itself is already ready to be freed, why do you
> > need RCU here? What could still read 'act->act_cookie'
> > while 'act' is already invisible?
> >
> > Its last refcnt is already gone, the fast path RCU readers
> > are gone too given filters use rcu work already.
> >
> > Standalone action dump? Again, the last refcnt is already
> > gone.
>
> It is not necessary here, I just used tcf_set_action_cookie() that
> already implements cookie pointer cleanup to prevent code duplication.
> I'm open to changing it, if you concerned with performance impact of
> using atomic operation for re-assigning cookie pointer.
Yeah, totally understand. But >act_cookie very special here,
it requires no copying when update, unlike the normal cases.
This means from RCU we can remove the "C" here. I know
you still copy it when dumping it, but it is a part of Read, not
a part of Update, so it is safe to say you only need R and U
here.
Which in turn means two things:
1. You don't have to use RCU anymore.
2. You don't need a lock for writers given there is no copy
during update, if you still stick to RCU.
This is why I keep saying you need to justify it, it is not trivial
and it is not easy to understand either.
Thanks!
^ permalink raw reply
* Re: [PATCH v2 nf-next 1/2] ipv6: remove dependency of nf_defrag_ipv6 on ipv6 module
From: kbuild test robot @ 2018-07-13 21:55 UTC (permalink / raw)
To: Florian Westphal; +Cc: kbuild-all, netfilter-devel, netdev, Florian Westphal
In-Reply-To: <20180713142754.23349-1-fw@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 13806 bytes --]
Hi Florian,
I love your patch! Yet something to improve:
[auto build test ERROR on nf-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Westphal/ipv6-remove-dependency-of-nf_defrag_ipv6-on-ipv6-module/20180714-051523
base: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
config: i386-randconfig-x015-201827 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from include/net/netns/mib.h:5:0,
from include/net/net_namespace.h:16,
from include/linux/netdevice.h:42,
from include/net/sock.h:51,
from include/linux/tcp.h:23,
from net//openvswitch/conntrack.c:16:
include/net/ipv6_frag.h: In function 'ip6frag_expire_frag_queue':
include/net/ipv6.h:213:16: error: 'struct netns_mib' has no member named 'ipv6_statistics'; did you mean 'ip_statistics'?
_DEVINC(net, ipv6, __, idev, field)
^
include/net/snmp.h:161:15: note: in definition of macro '__SNMP_ADD_STATS64'
__typeof__(*mib) *ptr = raw_cpu_ptr(mib); \
^~~
>> include/net/snmp.h:174:40: note: in expansion of macro 'SNMP_ADD_STATS64'
#define __SNMP_INC_STATS64(mib, field) SNMP_ADD_STATS64(mib, field, 1)
^~~~~~~~~~~~~~~~
include/net/ipv6.h:171:2: note: in expansion of macro '__SNMP_INC_STATS64'
mod##SNMP_INC_STATS64((net)->mib.statname##_statistics, (field));\
^~~
include/net/ipv6.h:213:3: note: in expansion of macro '_DEVINC'
_DEVINC(net, ipv6, __, idev, field)
^~~~~~~
include/net/ipv6_frag.h:80:2: note: in expansion of macro '__IP6_INC_STATS'
__IP6_INC_STATS(net, __in6_dev_get(dev), IPSTATS_MIB_REASMFAILS);
^~~~~~~~~~~~~~~
In file included from include/asm-generic/percpu.h:7:0,
from arch/x86/include/asm/percpu.h:543,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:81,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:10,
from net//openvswitch/conntrack.c:14:
include/net/ipv6.h:213:16: error: 'struct netns_mib' has no member named 'ipv6_statistics'; did you mean 'ip_statistics'?
_DEVINC(net, ipv6, __, idev, field)
^
include/linux/percpu-defs.h:221:47: note: in definition of macro '__verify_pcpu_ptr'
const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
^~~
>> include/linux/percpu-defs.h:265:47: note: in expansion of macro 'VERIFY_PERCPU_PTR'
#define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
^~~~~~~~~~~~~~~~~
>> include/linux/percpu-defs.h:266:26: note: in expansion of macro 'per_cpu_ptr'
#define raw_cpu_ptr(ptr) per_cpu_ptr(ptr, 0)
^~~~~~~~~~~
>> include/net/snmp.h:161:27: note: in expansion of macro 'raw_cpu_ptr'
__typeof__(*mib) *ptr = raw_cpu_ptr(mib); \
^~~~~~~~~~~
>> include/net/snmp.h:170:3: note: in expansion of macro '__SNMP_ADD_STATS64'
__SNMP_ADD_STATS64(mib, field, addend); \
^~~~~~~~~~~~~~~~~~
>> include/net/snmp.h:174:40: note: in expansion of macro 'SNMP_ADD_STATS64'
#define __SNMP_INC_STATS64(mib, field) SNMP_ADD_STATS64(mib, field, 1)
^~~~~~~~~~~~~~~~
include/net/ipv6.h:171:2: note: in expansion of macro '__SNMP_INC_STATS64'
mod##SNMP_INC_STATS64((net)->mib.statname##_statistics, (field));\
^~~
include/net/ipv6.h:213:3: note: in expansion of macro '_DEVINC'
_DEVINC(net, ipv6, __, idev, field)
^~~~~~~
include/net/ipv6_frag.h:80:2: note: in expansion of macro '__IP6_INC_STATS'
__IP6_INC_STATS(net, __in6_dev_get(dev), IPSTATS_MIB_REASMFAILS);
^~~~~~~~~~~~~~~
include/net/ipv6.h:213:16: error: 'struct netns_mib' has no member named 'ipv6_statistics'; did you mean 'ip_statistics'?
_DEVINC(net, ipv6, __, idev, field)
^
include/linux/percpu-defs.h:262:12: note: in definition of macro 'VERIFY_PERCPU_PTR'
(typeof(*(__p)) __kernel __force *)(__p); \
^~~
>> include/linux/percpu-defs.h:266:26: note: in expansion of macro 'per_cpu_ptr'
#define raw_cpu_ptr(ptr) per_cpu_ptr(ptr, 0)
^~~~~~~~~~~
>> include/net/snmp.h:161:27: note: in expansion of macro 'raw_cpu_ptr'
__typeof__(*mib) *ptr = raw_cpu_ptr(mib); \
^~~~~~~~~~~
>> include/net/snmp.h:170:3: note: in expansion of macro '__SNMP_ADD_STATS64'
__SNMP_ADD_STATS64(mib, field, addend); \
^~~~~~~~~~~~~~~~~~
>> include/net/snmp.h:174:40: note: in expansion of macro 'SNMP_ADD_STATS64'
#define __SNMP_INC_STATS64(mib, field) SNMP_ADD_STATS64(mib, field, 1)
^~~~~~~~~~~~~~~~
include/net/ipv6.h:171:2: note: in expansion of macro '__SNMP_INC_STATS64'
mod##SNMP_INC_STATS64((net)->mib.statname##_statistics, (field));\
^~~
include/net/ipv6.h:213:3: note: in expansion of macro '_DEVINC'
_DEVINC(net, ipv6, __, idev, field)
^~~~~~~
include/net/ipv6_frag.h:80:2: note: in expansion of macro '__IP6_INC_STATS'
__IP6_INC_STATS(net, __in6_dev_get(dev), IPSTATS_MIB_REASMFAILS);
^~~~~~~~~~~~~~~
include/net/ipv6.h:213:16: error: 'struct netns_mib' has no member named 'ipv6_statistics'; did you mean 'ip_statistics'?
_DEVINC(net, ipv6, __, idev, field)
^
include/linux/percpu-defs.h:262:38: note: in definition of macro 'VERIFY_PERCPU_PTR'
(typeof(*(__p)) __kernel __force *)(__p); \
^~~
>> include/linux/percpu-defs.h:266:26: note: in expansion of macro 'per_cpu_ptr'
#define raw_cpu_ptr(ptr) per_cpu_ptr(ptr, 0)
^~~~~~~~~~~
>> include/net/snmp.h:161:27: note: in expansion of macro 'raw_cpu_ptr'
__typeof__(*mib) *ptr = raw_cpu_ptr(mib); \
^~~~~~~~~~~
>> include/net/snmp.h:170:3: note: in expansion of macro '__SNMP_ADD_STATS64'
__SNMP_ADD_STATS64(mib, field, addend); \
^~~~~~~~~~~~~~~~~~
>> include/net/snmp.h:174:40: note: in expansion of macro 'SNMP_ADD_STATS64'
#define __SNMP_INC_STATS64(mib, field) SNMP_ADD_STATS64(mib, field, 1)
^~~~~~~~~~~~~~~~
include/net/ipv6.h:171:2: note: in expansion of macro '__SNMP_INC_STATS64'
mod##SNMP_INC_STATS64((net)->mib.statname##_statistics, (field));\
^~~
include/net/ipv6.h:213:3: note: in expansion of macro '_DEVINC'
_DEVINC(net, ipv6, __, idev, field)
^~~~~~~
include/net/ipv6_frag.h:80:2: note: in expansion of macro '__IP6_INC_STATS'
__IP6_INC_STATS(net, __in6_dev_get(dev), IPSTATS_MIB_REASMFAILS);
^~~~~~~~~~~~~~~
In file included from include/net/netns/mib.h:5:0,
from include/net/net_namespace.h:16,
from include/linux/netdevice.h:42,
from include/net/sock.h:51,
from include/linux/tcp.h:23,
from net//openvswitch/conntrack.c:16:
>> include/net/snmp.h:162:30: error: request for member 'syncp' in something not a structure or union
u64_stats_update_begin(&ptr->syncp); \
^
>> include/net/snmp.h:170:3: note: in expansion of macro '__SNMP_ADD_STATS64'
__SNMP_ADD_STATS64(mib, field, addend); \
^~~~~~~~~~~~~~~~~~
>> include/net/snmp.h:174:40: note: in expansion of macro 'SNMP_ADD_STATS64'
#define __SNMP_INC_STATS64(mib, field) SNMP_ADD_STATS64(mib, field, 1)
^~~~~~~~~~~~~~~~
include/net/ipv6.h:171:2: note: in expansion of macro '__SNMP_INC_STATS64'
mod##SNMP_INC_STATS64((net)->mib.statname##_statistics, (field));\
^~~
include/net/ipv6.h:213:3: note: in expansion of macro '_DEVINC'
_DEVINC(net, ipv6, __, idev, field)
^~~~~~~
include/net/ipv6_frag.h:80:2: note: in expansion of macro '__IP6_INC_STATS'
__IP6_INC_STATS(net, __in6_dev_get(dev), IPSTATS_MIB_REASMFAILS);
^~~~~~~~~~~~~~~
>> include/net/snmp.h:163:6: error: request for member 'mibs' in something not a structure or union
ptr->mibs[field] += addend; \
^
>> include/net/snmp.h:170:3: note: in expansion of macro '__SNMP_ADD_STATS64'
__SNMP_ADD_STATS64(mib, field, addend); \
^~~~~~~~~~~~~~~~~~
>> include/net/snmp.h:174:40: note: in expansion of macro 'SNMP_ADD_STATS64'
#define __SNMP_INC_STATS64(mib, field) SNMP_ADD_STATS64(mib, field, 1)
^~~~~~~~~~~~~~~~
include/net/ipv6.h:171:2: note: in expansion of macro '__SNMP_INC_STATS64'
mod##SNMP_INC_STATS64((net)->mib.statname##_statistics, (field));\
^~~
include/net/ipv6.h:213:3: note: in expansion of macro '_DEVINC'
_DEVINC(net, ipv6, __, idev, field)
^~~~~~~
include/net/ipv6_frag.h:80:2: note: in expansion of macro '__IP6_INC_STATS'
__IP6_INC_STATS(net, __in6_dev_get(dev), IPSTATS_MIB_REASMFAILS);
^~~~~~~~~~~~~~~
include/net/snmp.h:164:28: error: request for member 'syncp' in something not a structure or union
u64_stats_update_end(&ptr->syncp); \
^
vim +/syncp +162 include/net/snmp.h
4ce3c183f Eric Dumazet 2010-06-30 158
13415e46c Eric Dumazet 2016-04-27 159 #define __SNMP_ADD_STATS64(mib, field, addend) \
4ce3c183f Eric Dumazet 2010-06-30 160 do { \
903ceff7c Christoph Lameter 2014-08-17 @161 __typeof__(*mib) *ptr = raw_cpu_ptr(mib); \
4ce3c183f Eric Dumazet 2010-06-30 @162 u64_stats_update_begin(&ptr->syncp); \
4ce3c183f Eric Dumazet 2010-06-30 @163 ptr->mibs[field] += addend; \
4ce3c183f Eric Dumazet 2010-06-30 164 u64_stats_update_end(&ptr->syncp); \
4ce3c183f Eric Dumazet 2010-06-30 165 } while (0)
8f0ea0fe3 Eric Dumazet 2011-06-10 166
6aef70a85 Eric Dumazet 2016-04-27 167 #define SNMP_ADD_STATS64(mib, field, addend) \
4ce3c183f Eric Dumazet 2010-06-30 168 do { \
ba7863f4d Eric Dumazet 2016-04-28 169 local_bh_disable(); \
13415e46c Eric Dumazet 2016-04-27 @170 __SNMP_ADD_STATS64(mib, field, addend); \
ba7863f4d Eric Dumazet 2016-04-28 171 local_bh_enable(); \
4ce3c183f Eric Dumazet 2010-06-30 172 } while (0)
8f0ea0fe3 Eric Dumazet 2011-06-10 173
13415e46c Eric Dumazet 2016-04-27 @174 #define __SNMP_INC_STATS64(mib, field) SNMP_ADD_STATS64(mib, field, 1)
4ce3c183f Eric Dumazet 2010-06-30 175 #define SNMP_INC_STATS64(mib, field) SNMP_ADD_STATS64(mib, field, 1)
13415e46c Eric Dumazet 2016-04-27 176 #define __SNMP_UPD_PO_STATS64(mib, basefield, addend) \
4ce3c183f Eric Dumazet 2010-06-30 177 do { \
698365fa1 WANG Cong 2014-05-05 178 __typeof__(*mib) *ptr; \
903ceff7c Christoph Lameter 2014-08-17 179 ptr = raw_cpu_ptr((mib)); \
4ce3c183f Eric Dumazet 2010-06-30 180 u64_stats_update_begin(&ptr->syncp); \
4ce3c183f Eric Dumazet 2010-06-30 181 ptr->mibs[basefield##PKTS]++; \
4ce3c183f Eric Dumazet 2010-06-30 182 ptr->mibs[basefield##OCTETS] += addend; \
4ce3c183f Eric Dumazet 2010-06-30 183 u64_stats_update_end(&ptr->syncp); \
4ce3c183f Eric Dumazet 2010-06-30 184 } while (0)
8f0ea0fe3 Eric Dumazet 2011-06-10 185 #define SNMP_UPD_PO_STATS64(mib, basefield, addend) \
8f0ea0fe3 Eric Dumazet 2011-06-10 186 do { \
ba7863f4d Eric Dumazet 2016-04-28 187 local_bh_disable(); \
13415e46c Eric Dumazet 2016-04-27 188 __SNMP_UPD_PO_STATS64(mib, basefield, addend); \
ba7863f4d Eric Dumazet 2016-04-28 189 local_bh_enable(); \
8f0ea0fe3 Eric Dumazet 2011-06-10 190 } while (0)
4ce3c183f Eric Dumazet 2010-06-30 191 #else
13415e46c Eric Dumazet 2016-04-27 192 #define __SNMP_INC_STATS64(mib, field) __SNMP_INC_STATS(mib, field)
4ce3c183f Eric Dumazet 2010-06-30 193 #define SNMP_INC_STATS64(mib, field) SNMP_INC_STATS(mib, field)
4ce3c183f Eric Dumazet 2010-06-30 194 #define SNMP_DEC_STATS64(mib, field) SNMP_DEC_STATS(mib, field)
13415e46c Eric Dumazet 2016-04-27 195 #define __SNMP_ADD_STATS64(mib, field, addend) __SNMP_ADD_STATS(mib, field, addend)
4ce3c183f Eric Dumazet 2010-06-30 196 #define SNMP_ADD_STATS64(mib, field, addend) SNMP_ADD_STATS(mib, field, addend)
4ce3c183f Eric Dumazet 2010-06-30 197 #define SNMP_UPD_PO_STATS64(mib, basefield, addend) SNMP_UPD_PO_STATS(mib, basefield, addend)
13415e46c Eric Dumazet 2016-04-27 198 #define __SNMP_UPD_PO_STATS64(mib, basefield, addend) __SNMP_UPD_PO_STATS(mib, basefield, addend)
4ce3c183f Eric Dumazet 2010-06-30 199 #endif
4ce3c183f Eric Dumazet 2010-06-30 200
:::::: The code at line 162 was first introduced by commit
:::::: 4ce3c183fcade7f4b30a33dae90cd774c3d9e094 snmp: 64bit ipstats_mib for all arches
:::::: TO: Eric Dumazet <eric.dumazet@gmail.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27651 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 3/3] rds: Extend RDS API for IPv6 support
From: Santosh Shilimkar @ 2018-07-13 22:00 UTC (permalink / raw)
To: David Miller, ka-cheong.poon; +Cc: netdev, sowmini.varadhan, rds-devel
In-Reply-To: <20180713.142507.1025746468893234363.davem@davemloft.net>
Hi Dave,
On 7/13/2018 2:25 PM, David Miller wrote:
> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> Date: Fri, 13 Jul 2018 04:02:59 -0700
>
>> @@ -52,7 +52,7 @@
>> #define RDS_RECVERR 5
>> #define RDS_CONG_MONITOR 6
>> #define RDS_GET_MR_FOR_DEST 7
>> -#define SO_RDS_TRANSPORT 8
>> +#define SO_RDS_TRANSPORT 9
>
> There is no way you can change this value without breaking
> applications.
>
Downstream Oracle shipping application have been built
with 9 as a SO_RDS_TRANSPORT from beginning. 8 is used
for RDS_CONN_RESET but support for it doesn't exist
upstream yet. Ka-cheong was aligning them so that we
have same number upstream as well as in shipping products.
Ofcourse any application built using upstream header and
using SO_RDS_TRANSPORT will break but since this particular
option was added for special case(application wants to
upfront select transport instead letting bind figure it out),
our hope its not used by other application(s).
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH net-next v6 01/11] net: sched: use rcu for action cookie update
From: David Miller @ 2018-07-13 22:11 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: vladbu, netdev, jhs, jiri, ast, daniel, kliteyn, jiri
In-Reply-To: <CAM_iQpWGofJ_wVuoP8+hHYi5=LM8+3dC-sCMBaY8KEjwrMnNLw@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 13 Jul 2018 14:51:15 -0700
> Can we at least agree you have no justification for this change in
> this changelog?
He stated that he wishes to make this subsystem more lockless, and he
cannot do that without making the action cookie handling use RCU.
I agree with the stated goal, and the necessity of this kind of change.
Therefore I applied the patch.
I really don't see what the problem is.
I also gave a couple days for this patch set to get reviewed. If you
have a problem, please respond to the patch posting. When I see nobody
is reviewing, that is when I step in and make my own judgment.
So when you want your objection to be heard, please do so in a timely
manner. That helps all of us.
Thank you.
^ permalink raw reply
* Re: [PATCH iproute2-next 0/9] TC more JSON support
From: Stephen Hemminger @ 2018-07-13 22:22 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David Ahern, netdev, Stephen Hemminger, Jiri Pirko, Cong Wang,
Jamal Hadi Salim
In-Reply-To: <20180713142942.49d24264@cakuba.lan>
On Fri, 13 Jul 2018 14:29:42 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Fri, 13 Jul 2018 16:48:28 -0400, David Ahern wrote:
> > On 7/9/18 3:48 PM, Stephen Hemminger wrote:
> > > From: Stephen Hemminger <sthemmin@microsoft.com>
> > >
> > > Update core of TC command and library to do more JSON.
> > > Most of this patch set is about getting tc utility functions
> > > to be more friendly to the json_print infrastructure.
> > >
> > > Stephen Hemminger (9):
> > > tc: use JSON in error handling
> > > tc: use const char in util
> > > tc: convert stats print to json
> > > tc/cbq: use sprint_rate
> > > tc/util: remove print_rate
> > > tc/util: remove unused print_size
> > > tc/util: remove unused print_time
> > > tc/util: add print helpers for JSON
> > > tc/sfq: add json support
> > >
> > > tc/q_cbq.c | 15 ++++-----
> > > tc/q_sfq.c | 65 +++++++++++++++++++++---------------
> > > tc/tc.c | 19 ++++++-----
> > > tc/tc_util.c | 94 +++++++++++++++++++++++++++-------------------------
> > > tc/tc_util.h | 11 +++---
> > > 5 files changed, 109 insertions(+), 95 deletions(-)
> > >
> >
> > I'd prefer some tc folks to take a look at the json output and verify
> > everything is good.
> >
> > Jamal, Jiri, Jakub, Cong, others?
> >
> > There is a second set with 30 patches as well.
>
> AFAIK the 31 patches supersede this set? I only have tests that use
> JSON for MQ and RED qdiscs, and those work fine with the v2 applied!
This is what I used to test the trivial ones. Some require more parameters.
#! /bin/sh
for q in cbq cbs choke clsact codel drr dsmark fifo \
fq fq_codel gred hfsc hhf htb ingress mqprio \
multiq netem pie prio qfq red rr sfb sfq tbf
do
echo -n $q ": "
sudo tc qdisc add dev dummy0 root $q 2>/dev/null
if [ $? -ne 0 ]; then
echo "can not test"
else
/sbin/tc qdisc show dev dummy0 >$q.orig
./tc/tc qdisc show dev dummy0 >$q.new
if cmp $q.new $q.orig; then
echo -n "ok"
else
echo -n "differ"
fi
./tc/tc -j qdisc show dev dummy0 >$q.json
if python -mjson.tool <$q.json >/dev/null; then
echo " json ok"
else
echo " json format error"
fi
sudo tc qdisc del dev dummy0 root
fi
done
^ permalink raw reply
* Re: [PATCH iproute2-next] iplink: add support for reporting multiple XDP programs
From: Stephen Hemminger @ 2018-07-13 22:23 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: alexei.starovoitov, daniel, dsahern, netdev, oss-drivers
In-Reply-To: <20180713142037.503b7b01@cakuba.lan>
On Fri, 13 Jul 2018 14:20:37 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> On Fri, 13 Jul 2018 13:59:41 -0700, Stephen Hemminger wrote:
> > On Fri, 13 Jul 2018 13:43:59 -0700
> > Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> >
> > >
> > > +static void xdp_dump_prog_one(FILE *fp, struct rtattr *tb[IFLA_XDP_MAX + 1],
> > > + __u32 attr, bool link, bool details, char *pfx)
> > > +{
> > > + __u32 prog_id;
> > > +
> > > + if (!tb[attr])
> > > + return;
> > > +
> > > + prog_id = rta_getattr_u32(tb[attr]);
> > > + if (!details) {
> > > + if (prog_id && !link && attr == IFLA_XDP_PROG_ID)
> > > + fprintf(fp, "/id:%u", prog_id);
> > > + return;
> > > + }
> > > +
> > > + if (prog_id) {
> > > + fprintf(fp, "%s prog/xdp%s ", _SL_, pfx);
> > > + bpf_dump_prog_info(fp, prog_id);
> > > + }
> >
> > Maybe const char *pfx.
>
> Will do! Looking again at this code, I think I will also do this:
>
> diff --git a/ip/iplink_xdp.c b/ip/iplink_xdp.c
> index 0328bc01a981..68629834cc00 100644
> --- a/ip/iplink_xdp.c
> +++ b/ip/iplink_xdp.c
> @@ -121,6 +121,12 @@ static void xdp_dump_json(struct rtattr *tb[IFLA_XDP_MAX + 1])
> xdp_dump_json_one(tb, IFLA_XDP_SKB_PROG_ID, XDP_ATTACHED_SKB);
> xdp_dump_json_one(tb, IFLA_XDP_DRV_PROG_ID, XDP_ATTACHED_DRV);
> xdp_dump_json_one(tb, IFLA_XDP_HW_PROG_ID, XDP_ATTACHED_HW);
> + /* Older kernel - use IFLA_XDP_PROG_ID */
> + if (tb[IFLA_XDP_PROG_ID] &&
> + !(tb[IFLA_XDP_ATTACHED_SKB] ||
> + tb[IFLA_XDP_ATTACHED_DRV] ||
> + tb[IFLA_XDP_ATTACHED_HW]))
> + xdp_dump_json_one(tb, IFLA_XDP_PROG_ID, mode);
> close_json_array(PRINT_JSON, NULL);
>
> close_json_object();
>
> So that on older kernels we will still be able to depend on the
> contents of the "attached" array, even if kernel does not know to
> report program per-mode, yet.
>
> > I prefer to not use "printf(fp," and use print_string(PRINT_FP, NULL, "%s", ...)
> > because otherwise you end up mixing strings and json format output in the
> > same result.
> >
> > You should be able to do
> > tc -j ...
> > and always get valid JSON output.
> >
> > One quick way to test json validation is to pipe it into python:
> > tc -j ... | python -mjson.tool
>
> Note that XDP has separate print functions for plain text and JSON, and
> the flow gets separated early on:
>
> mode = rta_getattr_u8(tb[IFLA_XDP_ATTACHED]);
> if (mode == XDP_ATTACHED_NONE)
> return;
> else if (is_json_context())
> return details ? (void)0 : xdp_dump_json(tb);
>
> ... non-JSON handling follows...
>
> The use of fprintfs is therefore okay. Do you have a preference for
> using the wrapper, even if fprintf is safe? It's brevity vs
> consistency, I guess. We'd need a separate patch for that, 'cause I'm
> not touching all the fprintfs in the file, anyway.
The only preference for the wrapper is that it is easy way to make
sure all code is JSON aware. Since fp is always stdout in current
code, maybe just convert to printf.
^ permalink raw reply
* Re: [PATCH bpf-next v5 0/3] bpf: btf: print bpftool map data with btf
From: Daniel Borkmann @ 2018-07-13 22:35 UTC (permalink / raw)
To: Okash Khawaja
Cc: Jakub Kicinski, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <20180713213550.GA5667@w1t1fb>
On 07/13/2018 11:35 PM, Okash Khawaja wrote:
> On Fri, Jul 13, 2018 at 10:49:01PM +0200, Daniel Borkmann wrote:
>> On 07/12/2018 05:30 AM, Jakub Kicinski wrote:
>>> On Wed, 11 Jul 2018 20:08:03 -0700, Okash Khawaja wrote:
>>>> Hi,
>>>>
>>>> Here are the changes from v4:
>>>>
>>>> patch 2:
>>>>
>>>> - sort headers in btf_dumper.c
>>>> - remove extra parentheses
>>>> - include asm/byteorder.h
>>>> - compile error when big and small endian bitfields macro undefined
>>>
>>> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>>
>> Hmm, strange, by accident I just noticed that only your bpf fix ever made
>> it to patchwork, Okash.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_project_netdev_list_-3Fsubmitter-3D74458-26state-3D-2A&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=4wHrS7MHHFLZe_WCJwRVhA&m=wkiBQFYWPyiN9WONHLY0WiZxcOwNRhXaMMLIE551mCA&s=RggQzClRdkwawboGLPgPXHOdUtYffxeOwlcBlFru-P4&e=
>>
>> Potentially because you've sent with attachments which got dropped on
>> the list?
> interesting because i send all patches using quilt mail, the same way i
> sent bpf fix. i can try git-send-email.
>
> also i dropped Acked-by as i changed patch versions. is it common thing
> to do? or should i keep the Acked-by?
Depends on whether the pieces that have been ACKed changed in the
meantime or not.
^ permalink raw reply
* Re: [PATCH net-next] net: ip6_gre: get ipv6hdr after skb_cow_head()
From: William Tu @ 2018-07-13 22:39 UTC (permalink / raw)
To: Prashant Bhole
Cc: David S . Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Linux Kernel Network Developers
In-Reply-To: <20180713054050.5656-1-bhole_prashant_q7@lab.ntt.co.jp>
On Thu, Jul 12, 2018 at 10:40 PM, Prashant Bhole
<bhole_prashant_q7@lab.ntt.co.jp> wrote:
> A KASAN:use-after-free bug was found related to ip6-erspan
> while running selftests/net/ip6_gre_headroom.sh
>
> It happens because of following sequence:
> - ipv6hdr pointer is obtained from skb
> - skb_cow_head() is called, skb->head memory is reallocated
> - old data is accessed using ipv6hdr pointer
>
> skb_cow_head() call was added in e41c7c68ea77 ("ip6erspan: make sure
> enough headroom at xmit."), but looking at the history there was a
> chance of similar bug because gre_handle_offloads() and pskb_trim()
> can also reallocate skb->head memory. Fixes tag points to commit
> which introduced possibility of this bug.
>
> This patch moves ipv6hdr pointer assignment after skb_cow_head() call.
>
> Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> ---
Thanks for the fix.
Acked-by: William Tu <u9012063@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf-next v5 0/3] bpf: btf: print bpftool map data with btf
From: Okash Khawaja @ 2018-07-13 22:43 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jakub Kicinski, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <1e80f262-9b3f-e4ff-0e89-7a07098d1b50@iogearbox.net>
On Sat, Jul 14, 2018 at 12:35:03AM +0200, Daniel Borkmann wrote:
> On 07/13/2018 11:35 PM, Okash Khawaja wrote:
> > On Fri, Jul 13, 2018 at 10:49:01PM +0200, Daniel Borkmann wrote:
> >> On 07/12/2018 05:30 AM, Jakub Kicinski wrote:
> >>> On Wed, 11 Jul 2018 20:08:03 -0700, Okash Khawaja wrote:
> >>>> Hi,
> >>>>
> >>>> Here are the changes from v4:
> >>>>
> >>>> patch 2:
> >>>>
> >>>> - sort headers in btf_dumper.c
> >>>> - remove extra parentheses
> >>>> - include asm/byteorder.h
> >>>> - compile error when big and small endian bitfields macro undefined
> >>>
> >>> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> >>
> >> Hmm, strange, by accident I just noticed that only your bpf fix ever made
> >> it to patchwork, Okash.
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_project_netdev_list_-3Fsubmitter-3D74458-26state-3D-2A&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=4wHrS7MHHFLZe_WCJwRVhA&m=wkiBQFYWPyiN9WONHLY0WiZxcOwNRhXaMMLIE551mCA&s=RggQzClRdkwawboGLPgPXHOdUtYffxeOwlcBlFru-P4&e=
> >>
> >> Potentially because you've sent with attachments which got dropped on
> >> the list?
> > interesting because i send all patches using quilt mail, the same way i
> > sent bpf fix. i can try git-send-email.
> >
> > also i dropped Acked-by as i changed patch versions. is it common thing
> > to do? or should i keep the Acked-by?
>
> Depends on whether the pieces that have been ACKed changed in the
> meantime or not.
right, thanks. makes sense :)
regarding patches not showing in patchwork, i've checked that the
patches are not attachments. is it going to be a problem with
upstreaming if they don't show up in patchwork? should i send patches
again?
^ permalink raw reply
* [PATCH iproute2-next v2] iplink: add support for reporting multiple XDP programs
From: Jakub Kicinski @ 2018-07-13 22:54 UTC (permalink / raw)
To: alexei.starovoitov, daniel, dsahern, stephen
Cc: netdev, oss-drivers, Jakub Kicinski
Kernel now supports attaching XDP programs in the driver
and hardware at the same time. Print that information
correctly.
In case there are multiple programs attached kernel will
not provide IFLA_XDP_PROG_ID, so don't expect it to be
there (this also improves the printing for very old kernels
slightly, as it avoids unnecessary "prog/xdp" line).
In short mode preserve the current outputs but don't print
IDs if there are multiple.
6: netdevsim0: <BROADCAST,NOARP> mtu 1500 xdpoffload/id:11 qdisc [...]
and:
6: netdevsim0: <BROADCAST,NOARP> mtu 1500 xdpmulti qdisc [...]
ip link output will keep using prog/xdp prefix if only one program
is attached, but can also print multiple program lines:
prog/xdp id 8 tag fc7a51d1a693a99e jited
vs:
prog/xdpdrv id 8 tag fc7a51d1a693a99e jited
prog/xdpoffload id 9 tag fc7a51d1a693a99e
JSON output gains a new array called "attached" which will
contain the full list of attached programs along with their
attachment modes:
"xdp": {
"mode": 3,
"prog": {
"id": 11,
"tag": "fc7a51d1a693a99e",
"jited": 0
},
"attached": [ {
"mode": 3,
"prog": {
"id": 11,
"tag": "fc7a51d1a693a99e",
"jited": 0
}
} ]
},
In case there are multiple programs attached the general "xdp"
section will not contain program information:
"xdp": {
"mode": 4,
"attached": [ {
"mode": 1,
"prog": {
"id": 10,
"tag": "fc7a51d1a693a99e",
"jited": 1
}
},{
"mode": 3,
"prog": {
"id": 11,
"tag": "fc7a51d1a693a99e",
"jited": 0
}
} ]
},
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
v2:
- const char * for constant string;
- add more compat for older kernels.
---
ip/iplink_xdp.c | 73 +++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 61 insertions(+), 12 deletions(-)
diff --git a/ip/iplink_xdp.c b/ip/iplink_xdp.c
index dd4fd1fd3a3b..4a490bc8fb66 100644
--- a/ip/iplink_xdp.c
+++ b/ip/iplink_xdp.c
@@ -91,6 +91,18 @@ int xdp_parse(int *argc, char ***argv, struct iplink_req *req,
return 0;
}
+static void xdp_dump_json_one(struct rtattr *tb[IFLA_XDP_MAX + 1], __u32 attr,
+ __u8 mode)
+{
+ if (!tb[attr])
+ return;
+
+ open_json_object(NULL);
+ print_uint(PRINT_JSON, "mode", NULL, mode);
+ bpf_dump_prog_info(NULL, rta_getattr_u32(tb[attr]));
+ close_json_object();
+}
+
static void xdp_dump_json(struct rtattr *tb[IFLA_XDP_MAX + 1])
{
__u32 prog_id = 0;
@@ -104,13 +116,48 @@ static void xdp_dump_json(struct rtattr *tb[IFLA_XDP_MAX + 1])
print_uint(PRINT_JSON, "mode", NULL, mode);
if (prog_id)
bpf_dump_prog_info(NULL, prog_id);
+
+ open_json_array(PRINT_JSON, "attached");
+ if (tb[IFLA_XDP_SKB_PROG_ID] ||
+ tb[IFLA_XDP_DRV_PROG_ID] ||
+ tb[IFLA_XDP_HW_PROG_ID]) {
+ xdp_dump_json_one(tb, IFLA_XDP_SKB_PROG_ID, XDP_ATTACHED_SKB);
+ xdp_dump_json_one(tb, IFLA_XDP_DRV_PROG_ID, XDP_ATTACHED_DRV);
+ xdp_dump_json_one(tb, IFLA_XDP_HW_PROG_ID, XDP_ATTACHED_HW);
+ } else if (tb[IFLA_XDP_PROG_ID]) {
+ /* Older kernel - use IFLA_XDP_PROG_ID */
+ xdp_dump_json_one(tb, IFLA_XDP_PROG_ID, mode);
+ }
+ close_json_array(PRINT_JSON, NULL);
+
close_json_object();
}
+static void xdp_dump_prog_one(FILE *fp, struct rtattr *tb[IFLA_XDP_MAX + 1],
+ __u32 attr, bool link, bool details,
+ const char *pfx)
+{
+ __u32 prog_id;
+
+ if (!tb[attr])
+ return;
+
+ prog_id = rta_getattr_u32(tb[attr]);
+ if (!details) {
+ if (prog_id && !link && attr == IFLA_XDP_PROG_ID)
+ fprintf(fp, "/id:%u", prog_id);
+ return;
+ }
+
+ if (prog_id) {
+ fprintf(fp, "%s prog/xdp%s ", _SL_, pfx);
+ bpf_dump_prog_info(fp, prog_id);
+ }
+}
+
void xdp_dump(FILE *fp, struct rtattr *xdp, bool link, bool details)
{
struct rtattr *tb[IFLA_XDP_MAX + 1];
- __u32 prog_id = 0;
__u8 mode;
parse_rtattr_nested(tb, IFLA_XDP_MAX, xdp);
@@ -124,27 +171,29 @@ void xdp_dump(FILE *fp, struct rtattr *xdp, bool link, bool details)
else if (is_json_context())
return details ? (void)0 : xdp_dump_json(tb);
else if (details && link)
- fprintf(fp, "%s prog/xdp", _SL_);
+ /* don't print mode */;
else if (mode == XDP_ATTACHED_DRV)
fprintf(fp, "xdp");
else if (mode == XDP_ATTACHED_SKB)
fprintf(fp, "xdpgeneric");
else if (mode == XDP_ATTACHED_HW)
fprintf(fp, "xdpoffload");
+ else if (mode == XDP_ATTACHED_MULTI)
+ fprintf(fp, "xdpmulti");
else
fprintf(fp, "xdp[%u]", mode);
- if (tb[IFLA_XDP_PROG_ID])
- prog_id = rta_getattr_u32(tb[IFLA_XDP_PROG_ID]);
- if (!details) {
- if (prog_id && !link)
- fprintf(fp, "/id:%u", prog_id);
- fprintf(fp, " ");
- return;
+ xdp_dump_prog_one(fp, tb, IFLA_XDP_PROG_ID, link, details, "");
+
+ if (mode == XDP_ATTACHED_MULTI) {
+ xdp_dump_prog_one(fp, tb, IFLA_XDP_SKB_PROG_ID, link, details,
+ "generic");
+ xdp_dump_prog_one(fp, tb, IFLA_XDP_DRV_PROG_ID, link, details,
+ "drv");
+ xdp_dump_prog_one(fp, tb, IFLA_XDP_HW_PROG_ID, link, details,
+ "offload");
}
- if (prog_id) {
+ if (!details || !link)
fprintf(fp, " ");
- bpf_dump_prog_info(fp, prog_id);
- }
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH iproute2-next] iplink: add support for reporting multiple XDP programs
From: Jakub Kicinski @ 2018-07-13 22:59 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexei.starovoitov, daniel, dsahern, netdev, oss-drivers
In-Reply-To: <20180713152330.7a2ec1dc@xeon-e3>
On Fri, 13 Jul 2018 15:23:30 -0700, Stephen Hemminger wrote:
> > > I prefer to not use "printf(fp," and use print_string(PRINT_FP, NULL, "%s", ...)
> > > because otherwise you end up mixing strings and json format output in the
> > > same result.
> > >
> > > You should be able to do
> > > tc -j ...
> > > and always get valid JSON output.
> > >
> > > One quick way to test json validation is to pipe it into python:
> > > tc -j ... | python -mjson.tool
> >
> > Note that XDP has separate print functions for plain text and JSON, and
> > the flow gets separated early on:
> >
> > mode = rta_getattr_u8(tb[IFLA_XDP_ATTACHED]);
> > if (mode == XDP_ATTACHED_NONE)
> > return;
> > else if (is_json_context())
> > return details ? (void)0 : xdp_dump_json(tb);
> >
> > ... non-JSON handling follows...
> >
> > The use of fprintfs is therefore okay. Do you have a preference for
> > using the wrapper, even if fprintf is safe? It's brevity vs
> > consistency, I guess. We'd need a separate patch for that, 'cause I'm
> > not touching all the fprintfs in the file, anyway.
>
> The only preference for the wrapper is that it is easy way to make
> sure all code is JSON aware.
Yes...
> Since fp is always stdout in current code, maybe just convert to printf.
...or maybe we could consider adding a wrapper for printf that wouldn't
take all the unnecessary parameters print_string() takes, yet clearly
indicate autor knows about JSON output concerns?
^ permalink raw reply
* Re: [bpf-next PATCH] samples/bpf: xdp_redirect_cpu handle parsing of double VLAN tagged packets
From: Daniel Borkmann @ 2018-07-13 23:13 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev
Cc: florian.maury-cv, Daniel Borkmann, marek, Alexei Starovoitov
In-Reply-To: <153149249232.12554.16301790063697986772.stgit@firesoul>
On 07/13/2018 04:35 PM, Jesper Dangaard Brouer wrote:
> People noticed that the code match on IEEE 802.1ad (ETH_P_8021AD) ethertype,
> and this implies Q-in-Q or double tagged VLANs. Thus, we better parse
> the next VLAN header too. It is even marked as a TODO.
>
> This is relevant for real world use-cases, as XDP cpumap redirect can be
> used when the NIC RSS hashing is broken. E.g. the ixgbe driver HW cannot
> handle double tagged VLAN packets, and places everything into a single
> RX queue. Using cpumap redirect, users can redistribute traffic across
> CPUs to solve this, which is faster than the network stacks RPS solution.
>
> It is left as an exerise how to distribute the packets across CPUs. It
> would be convenient to use the RX hash, but that is not _yet_ exposed
> to XDP programs. For now, users can code their own hash, as I've demonstrated
> in the Suricata code (where Q-in-Q is handled correctly).
>
> Reported-by: Florian Maury <florian.maury-cv@x-cli.eu>
> Reported-by: Marek Majkowski <marek@cloudflare.com>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied to bpf-next, thanks Jesper!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox