* [PATCH net] net/ipv4: defensive cipso option parsing
From: Stefan Nuernberger @ 2018-09-17 15:11 UTC (permalink / raw)
To: netdev; +Cc: aams, yujuan.qi, paul, Stefan Nuernberger, stable
commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
a possible infinite loop in the IP option parsing of CIPSO. The fix
assumes that ip_options_compile filtered out all zero length options and
that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
While this assumption currently holds true, add explicit checks for zero
length and invalid length options to be safe for the future. Even though
ip_options_compile should have validated the options, the introduction of
new one-byte options can still confuse this code without the additional
checks.
Signed-off-by: Stefan Nuernberger <snu@amazon.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Simon Veith <sveith@amazon.de>
Cc: stable@vger.kernel.org
---
net/ipv4/cipso_ipv4.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 82178cc69c96..f291b57b8474 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1512,7 +1512,7 @@ static int cipso_v4_parsetag_loc(const struct cipso_v4_doi *doi_def,
*
* Description:
* Parse the packet's IP header looking for a CIPSO option. Returns a pointer
- * to the start of the CIPSO option on success, NULL if one if not found.
+ * to the start of the CIPSO option on success, NULL if one is not found.
*
*/
unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
@@ -1522,9 +1522,11 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
int optlen;
int taglen;
- for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
+ for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 1; ) {
switch (optptr[0]) {
case IPOPT_CIPSO:
+ if (!optptr[1] || optptr[1] > optlen)
+ return NULL;
return optptr;
case IPOPT_END:
return NULL;
@@ -1534,6 +1536,10 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
default:
taglen = optptr[1];
}
+
+ if (!taglen || taglen > optlen)
+ break;
+
optlen -= taglen;
optptr += taglen;
}
--
2.19.0
^ permalink raw reply related
* Re: [PATH RFC net-next 1/8] net: phy: Move linkmode helpers to somewhere public
From: Maxime Chevallier @ 2018-09-17 9:48 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-2-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:49 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>phylink has some useful helpers to working with linkmode bitmaps.
>Move them to there own header so other code can use them.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATCH net-next] selftests/tls: Add MSG_WAITALL in recv() syscall
From: David Miller @ 2018-09-17 15:15 UTC (permalink / raw)
To: vakul.garg
Cc: netdev, linux-kselftest, linux-kernel, shuah, davejwatson,
doronrk
In-Reply-To: <20180916043428.24329-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Sun, 16 Sep 2018 10:04:28 +0530
> A number of tls selftests rely upon recv() to return an exact number of
> data bytes. When tls record crypto is done using an async accelerator,
> it is possible that recv() returns lesser than expected number bytes.
> This leads to failure of many test cases. To fix it, MSG_WAITALL has
> been used in flags passed to recv() syscall.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATH RFC net-next 2/8] net: phy: Add phydev_warn()
From: Maxime Chevallier @ 2018-09-17 9:49 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-3-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:50 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>Not all new style LINK_MODE bits can be converted into old style
>SUPPORTED bits. We need to warn when such a conversion is attempted.
>Add a helper for this.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Arnaldo Carvalho de Melo @ 2018-09-17 15:16 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo, Jakub Kicinski, Daniel Borkmann,
Thomas Richter, Hendrik Brueckner, Jiri Olsa, Namhyung Kim,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180913185629.su22fnimluoezntg@ast-mbp>
Em Thu, Sep 13, 2018 at 11:56:31AM -0700, Alexei Starovoitov escreveu:
> On Thu, Sep 13, 2018 at 03:32:40PM -0300, Arnaldo Carvalho de Melo wrote:
> > Please do some testing with my perf/libbpf+str_error_r branch, it has
> > two patches to get this fixed, the one I sent and a prep one making
> > libbpf link against libapi.
> > [acme@jouet perf]$ git log --oneline -2
> > a7ab924b7fec (HEAD -> perf/urgent, acme.korg/perf/libbpf+str_error_r) tools lib bpf: Use str_error_r() to fix the build in Alpine Linux
> > fb4a79e04c2b tools lib bpf: Build and link to tools/lib/api/
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/libbpf%2bstr_error_r&id=fb4a79e04c2b37ee873a3b31a3250925cf466fff
> we cannot do this.
> lib/api is GPL we cannot use it in LGPL library.
So, look at this second attempt, are you ok with it?
Builds with all the Alpine Linux test build containers and some more,
still building with all the others:
1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0
2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822
3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0
4 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0
5 alpine:3.8 : Ok gcc (Alpine 6.4.0) 6.4.0
6 alpine:edge : Ok gcc (Alpine 6.4.0) 6.4.0
7 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
8 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
9 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
10 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
11 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
12 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
13 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
14 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2
15 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2
16 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
17 debian:experimental : Ok gcc (Debian 8.2.0-4) 8.2.0
18 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 8.2.0-4) 8.2.0
19 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 8.2.0-4) 8.2.0
commit 1ca0d8249e5bd335b1c33a33569e4ed94025128e
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Fri Sep 14 16:47:14 2018 -0300
tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE systems
Same problem that got fixed in a similar fashion in tools/perf/ in
c8b5f2c96d1b ("tools: Introduce str_error_r()"), fix it in the same
way, licensing needs to be sorted out to libbpf to use libapi, so,
for this simple case, just get the same wrapper in tools/lib/bpf.
This makes libbpf and its users (bpftool, selftests, perf) to build
again in Alpine Linux 3.[45678] and edge.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Quentin Monnet <quentin.monnet@netronome.com>
Cc: Thomas Richter <tmricht@linux.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Yonghong Song <yhs@fb.com>
Fixes: 1ce6a9fc1549 ("bpf: fix build error in libbpf with EXTRA_CFLAGS="-Wp, -D_FORTIFY_SOURCE=2 -O2"")
Link: https://lkml.kernel.org/n/tip-i8ckf6s06e7tayw7xxhhhkux@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
index 13a861135127..6eb9bacd1948 100644
--- a/tools/lib/bpf/Build
+++ b/tools/lib/bpf/Build
@@ -1 +1 @@
-libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o
+libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o str_error.o
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 2abd0f112627..bdb94939fd60 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -50,6 +50,7 @@
#include "libbpf.h"
#include "bpf.h"
#include "btf.h"
+#include "str_error.h"
#ifndef EM_BPF
#define EM_BPF 247
@@ -469,7 +470,7 @@ static int bpf_object__elf_init(struct bpf_object *obj)
obj->efile.fd = open(obj->path, O_RDONLY);
if (obj->efile.fd < 0) {
char errmsg[STRERR_BUFSIZE];
- char *cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ char *cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to open %s: %s\n", obj->path, cp);
return -errno;
@@ -810,8 +811,7 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
data->d_size, name, idx);
if (err) {
char errmsg[STRERR_BUFSIZE];
- char *cp = strerror_r(-err, errmsg,
- sizeof(errmsg));
+ char *cp = str_error(-err, errmsg, sizeof(errmsg));
pr_warning("failed to alloc program %s (%s): %s",
name, obj->path, cp);
@@ -1140,7 +1140,7 @@ bpf_object__create_maps(struct bpf_object *obj)
*pfd = bpf_create_map_xattr(&create_attr);
if (*pfd < 0 && create_attr.btf_key_type_id) {
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("Error in bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n",
map->name, cp, errno);
create_attr.btf_fd = 0;
@@ -1155,7 +1155,7 @@ bpf_object__create_maps(struct bpf_object *obj)
size_t j;
err = *pfd;
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to create map (name: '%s'): %s\n",
map->name, cp);
for (j = 0; j < i; j++)
@@ -1339,7 +1339,7 @@ load_program(enum bpf_prog_type type, enum bpf_attach_type expected_attach_type,
}
ret = -LIBBPF_ERRNO__LOAD;
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("load bpf program failed: %s\n", cp);
if (log_buf && log_buf[0] != '\0') {
@@ -1654,7 +1654,7 @@ static int check_path(const char *path)
dir = dirname(dname);
if (statfs(dir, &st_fs)) {
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to statfs %s: %s\n", dir, cp);
err = -errno;
}
@@ -1690,7 +1690,7 @@ int bpf_program__pin_instance(struct bpf_program *prog, const char *path,
}
if (bpf_obj_pin(prog->instances.fds[instance], path)) {
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to pin program: %s\n", cp);
return -errno;
}
@@ -1708,7 +1708,7 @@ static int make_dir(const char *path)
err = -errno;
if (err) {
- cp = strerror_r(-err, errmsg, sizeof(errmsg));
+ cp = str_error(-err, errmsg, sizeof(errmsg));
pr_warning("failed to mkdir %s: %s\n", path, cp);
}
return err;
@@ -1770,7 +1770,7 @@ int bpf_map__pin(struct bpf_map *map, const char *path)
}
if (bpf_obj_pin(map->fd, path)) {
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to pin map: %s\n", cp);
return -errno;
}
diff --git a/tools/lib/bpf/str_error.c b/tools/lib/bpf/str_error.c
new file mode 100644
index 000000000000..b8798114a357
--- /dev/null
+++ b/tools/lib/bpf/str_error.c
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: LGPL-2.1
+#undef _GNU_SOURCE
+#include <string.h>
+#include <stdio.h>
+#include "str_error.h"
+
+/*
+ * Wrapper to allow for building in non-GNU systems such as Alpine Linux's musl
+ * libc, while checking strerror_r() return to avoid having to check this in
+ * all places calling it.
+ */
+char *str_error(int err, char *dst, int len)
+{
+ int ret = strerror_r(err, dst, len);
+ if (ret)
+ snprintf(dst, len, "ERROR: strerror_r(%d)=%d", err, ret);
+ return dst;
+}
diff --git a/tools/lib/bpf/str_error.h b/tools/lib/bpf/str_error.h
new file mode 100644
index 000000000000..b9a22564ddc6
--- /dev/null
+++ b/tools/lib/bpf/str_error.h
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.1
+#ifndef BPF_STR_ERROR
+#define BPF_STR_ERROR
+
+char *str_error(int err, char *dst, int len);
+#endif // BPF_STR_ERROR
^ permalink raw reply related
* Re: [PATH RFC net-next 3/8] net: phy: Add helper to convert MII ADV register to a linkmode
From: Maxime Chevallier @ 2018-09-17 9:50 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-4-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:51 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>The phy_mii_ioctl can be used to write a value into the MII_ADVERTISE
>register in the PHY. Since this changes the state of the PHY, we need
>to make the same change to phydev->advertising. Add a helper which can
>convert the register value to a linkmode.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATH RFC net-next 4/8] net: phy: Add helper for advertise to lcl value
From: Maxime Chevallier @ 2018-09-17 9:51 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-5-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:52 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>Add a helper to convert the local advertising to an LCL capabilities,
>which is then used to resolve pause flow control settings.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATH RFC net-next 5/8] net: phy: Add limkmode equivalents to some of the MII ethtool helpers
From: Maxime Chevallier @ 2018-09-17 9:53 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-6-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:53 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>Add helpers which take a linkmode rather than a u32 ethtool for
>advertising settings.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATCH] net: ethernet: remove redundant null pointer check before of_node_put
From: David Miller @ 2018-09-17 15:20 UTC (permalink / raw)
To: zhongjiang; +Cc: fugang.duan, netdev, linux-kernel
In-Reply-To: <1537103622-63482-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Sun, 16 Sep 2018 21:13:42 +0800
> of_node_put has taken the null pinter check into account. So it is
> safe to remove the duplicated check before of_node_put.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied.
^ permalink raw reply
* Re: iproute2: Debian 9 No ELF support
From: Daniel Borkmann @ 2018-09-17 9:57 UTC (permalink / raw)
To: yuzibode; +Cc: netdev
In-Reply-To: <20180917082353.ebtapq7oxirrzrcu@yubo-2>
On 09/17/2018 10:23 AM, Bo YU wrote:
> Hello,
> I have followed the instructions from:
>
> https://cilium.readthedocs.io/en/latest/bpf/#bpftool
>
> to test xdp program.
> But i can not enable elf support.
>
> ./configure --prefix=/usr
> ```output
> TC schedulers
> ATM no
>
> libc has setns: yes
> SELinux support: no
> ELF support: no
> libmnl support: yes
> Berkeley DB: yes
> need for strlcpy: yes
> libcap support: yes
> ```
> And i have installed libelf-dev :
> ```output
> sudo apt show libelf-dev
> Package: libelf-dev
> Version: 0.168-1
> Priority: optional
> Section: libdevel
> Source: elfutils
> Maintainer: Kurt Roeckx <kurt@roeckx.be>
> Installed-Size: 353 kB
> Depends: libelf1 (= 0.168-1)
> Conflicts: libelfg0-dev
> Homepage: https://sourceware.org/elfutils/
> Tag: devel::library, role::devel-lib
> ```
>
> And gcc version:
> gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
>
> uname -a:
> Linux debian 4.18.0-rc1+ #2 SMP Sun Jun 24 16:53:57 HKT 2018 x86_64 GNU/Linux
>
> Any help is appreciate.
Debian's official iproute2 packaging build says 'libelf-dev' [0], and having
libelf-dev installed should work ...
[...]
Build-Depends: bison,
debhelper (>= 10~),
flex,
iptables-dev,
libatm1-dev,
libcap-dev,
libdb-dev,
libelf-dev,
libmnl-dev,
libselinux1-dev,
linux-libc-dev,
pkg-config,
po-debconf,
zlib1g-dev,
[...]
Did you ran into this one perhaps [1]? Do you have zlib1g-dev installed?
[0] https://salsa.debian.org/debian/iproute2/blob/master/debian/control
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885071
^ permalink raw reply
* [PATCH v2 1/2] netlink: add NLA_REJECT policy type
From: Johannes Berg @ 2018-09-17 9:57 UTC (permalink / raw)
To: netdev; +Cc: Marcelo Ricardo Leitner, Michal Kubecek, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
In some situations some netlink attributes may be used for output
only (kernel->userspace) or may be reserved for future use. It's
then helpful to be able to prevent userspace from using them in
messages sent to the kernel, since they'd otherwise be ignored and
any future will become impossible if this happens.
Add NLA_REJECT to the policy which does nothing but reject (with
EINVAL) validation of any messages containing this attribute.
Allow for returning a specific extended ACK error message in the
validation_data pointer.
While at it clear up the documentation a bit - the NLA_BITFIELD32
documentation was added to the list of len field descriptions.
Also, use NL_SET_BAD_ATTR() in one place where it's open-coded.
The specific case I have in mind now is a shared nested attribute
containing request/response data, and it would be pointless and
potentially confusing to have userspace include response data in
the messages that actually contain a request.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
v2: preserve behaviour of overwriting the extack message, with
either the generic or the specific one now
---
include/net/netlink.h | 13 ++++++++++++-
lib/nlattr.c | 23 ++++++++++++++++-------
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 0c154f98e987..b318b0a9f6c3 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -180,6 +180,7 @@ enum {
NLA_S32,
NLA_S64,
NLA_BITFIELD32,
+ NLA_REJECT,
__NLA_TYPE_MAX,
};
@@ -208,9 +209,19 @@ enum {
* NLA_MSECS Leaving the length field zero will verify the
* given type fits, using it verifies minimum length
* just like "All other"
- * NLA_BITFIELD32 A 32-bit bitmap/bitselector attribute
+ * NLA_BITFIELD32 Unused
+ * NLA_REJECT Unused
* All other Minimum length of attribute payload
*
+ * Meaning of `validation_data' field:
+ * NLA_BITFIELD32 This is a 32-bit bitmap/bitselector attribute and
+ * validation data must point to a u32 value of valid
+ * flags
+ * NLA_REJECT This attribute is always rejected and validation data
+ * may point to a string to report as the error instead
+ * of the generic one in extended ACK.
+ * All other Unused
+ *
* Example:
* static const struct nla_policy my_policy[ATTR_MAX+1] = {
* [ATTR_FOO] = { .type = NLA_U16 },
diff --git a/lib/nlattr.c b/lib/nlattr.c
index e335bcafa9e4..36d74b079151 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -69,7 +69,8 @@ static int validate_nla_bitfield32(const struct nlattr *nla,
}
static int validate_nla(const struct nlattr *nla, int maxtype,
- const struct nla_policy *policy)
+ const struct nla_policy *policy,
+ const char **error_msg)
{
const struct nla_policy *pt;
int minlen = 0, attrlen = nla_len(nla), type = nla_type(nla);
@@ -87,6 +88,11 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
}
switch (pt->type) {
+ case NLA_REJECT:
+ if (pt->validation_data && error_msg)
+ *error_msg = pt->validation_data;
+ return -EINVAL;
+
case NLA_FLAG:
if (attrlen > 0)
return -ERANGE;
@@ -180,11 +186,10 @@ int nla_validate(const struct nlattr *head, int len, int maxtype,
int rem;
nla_for_each_attr(nla, head, len, rem) {
- int err = validate_nla(nla, maxtype, policy);
+ int err = validate_nla(nla, maxtype, policy, NULL);
if (err < 0) {
- if (extack)
- extack->bad_attr = nla;
+ NL_SET_BAD_ATTR(extack, nla);
return err;
}
}
@@ -250,11 +255,15 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
u16 type = nla_type(nla);
if (type > 0 && type <= maxtype) {
+ static const char _msg[] = "Attribute failed policy validation";
+ const char *msg = _msg;
+
if (policy) {
- err = validate_nla(nla, maxtype, policy);
+ err = validate_nla(nla, maxtype, policy, &msg);
if (err < 0) {
- NL_SET_ERR_MSG_ATTR(extack, nla,
- "Attribute failed policy validation");
+ NL_SET_BAD_ATTR(extack, nla);
+ if (extack)
+ extack->_msg = msg;
goto errout;
}
}
--
2.14.4
^ permalink raw reply related
* [PATCH v2 2/2] netlink: add ethernet address policy types
From: Johannes Berg @ 2018-09-17 9:57 UTC (permalink / raw)
To: netdev; +Cc: Marcelo Ricardo Leitner, Michal Kubecek, Johannes Berg
In-Reply-To: <20180917095729.11185-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Commonly, ethernet addresses are just using a policy of
{ .len = ETH_ALEN }
which leaves userspace free to send more data than it should,
which may hide bugs.
Introduce NLA_EXACT_LEN which checks for exact size, rejecting
the attribute if it's not exactly that length. Also add
NLA_EXACT_LEN_WARN which requires the minimum length and will
warn on longer attributes, for backward compatibility.
Use these to define NLA_POLICY_ETH_ADDR (new strict policy) and
NLA_POLICY_ETH_ADDR_COMPAT (compatible policy with warning);
these are used like this:
static const struct nla_policy <name>[...] = {
[NL_ATTR_NAME] = NLA_POLICY_ETH_ADDR,
...
};
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
v2: add only NLA_EXACT_LEN/NLA_EXACT_LEN_WARN and build on top
of that for ethernet address validation, so it can be extended
for other types (e.g. IPv6 addresses)
---
include/net/netlink.h | 13 +++++++++++++
lib/nlattr.c | 8 +++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index b318b0a9f6c3..318b1ded3833 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -181,6 +181,8 @@ enum {
NLA_S64,
NLA_BITFIELD32,
NLA_REJECT,
+ NLA_EXACT_LEN,
+ NLA_EXACT_LEN_WARN,
__NLA_TYPE_MAX,
};
@@ -211,6 +213,10 @@ enum {
* just like "All other"
* NLA_BITFIELD32 Unused
* NLA_REJECT Unused
+ * NLA_EXACT_LEN Attribute must have exactly this length, otherwise
+ * it is rejected.
+ * NLA_EXACT_LEN_WARN Attribute should have exactly this length, a warning
+ * is logged if it is longer, shorter is rejected.
* All other Minimum length of attribute payload
*
* Meaning of `validation_data' field:
@@ -236,6 +242,13 @@ struct nla_policy {
void *validation_data;
};
+#define NLA_POLICY_EXACT_LEN(_len) { .type = NLA_EXACT_LEN, .len = _len }
+#define NLA_POLICY_EXACT_LEN_WARN(_len) { .type = NLA_EXACT_LEN_WARN, \
+ .len = _len }
+
+#define NLA_POLICY_ETH_ADDR NLA_POLICY_EXACT_LEN(ETH_ALEN)
+#define NLA_POLICY_ETH_ADDR_COMPAT NLA_POLICY_EXACT_LEN_WARN(ETH_ALEN)
+
/**
* struct nl_info - netlink source information
* @nlh: Netlink message header of original request
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 36d74b079151..bb6fe5ed4ecf 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -82,12 +82,18 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
BUG_ON(pt->type > NLA_TYPE_MAX);
- if (nla_attr_len[pt->type] && attrlen != nla_attr_len[pt->type]) {
+ if ((nla_attr_len[pt->type] && attrlen != nla_attr_len[pt->type]) ||
+ (pt->type == NLA_EXACT_LEN_WARN && attrlen != pt->len)) {
pr_warn_ratelimited("netlink: '%s': attribute type %d has an invalid length.\n",
current->comm, type);
}
switch (pt->type) {
+ case NLA_EXACT_LEN:
+ if (attrlen != pt->len)
+ return -ERANGE;
+ break;
+
case NLA_REJECT:
if (pt->validation_data && error_msg)
*error_msg = pt->validation_data;
--
2.14.4
^ permalink raw reply related
* Re: [PATCH 0/2] add Ethernet driver support for mt2712
From: Andrew Lunn @ 2018-09-17 15:24 UTC (permalink / raw)
To: Biao Huang, peppe.cavallaro, alexandre.torgue, joabreu
Cc: davem, robh+dt, honghui.zhang, yt.shen, liguo.zhang, mark.rutland,
sean.wang, nelson.chang, matthias.bgg, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <1537165763-13112-1-git-send-email-biao.huang@mediatek.com>
On Mon, Sep 17, 2018 at 02:29:21PM +0800, Biao Huang wrote:
Adding in the STMMAC driver maintainers.
> Ethernet in mt2712 is totally different from that in
> drivers/net/ethernet/mediatek/*, so we add new folder for mt2712 SoC.
>
> The mt2712 Ethernet IP is from Synopsys, and we notice that there is a
> reference driver in drivers/net/ethernet/synopsys/*. But
> 1. our version is only for 10/100/1000Mbps, not for 2.5/4/5Gbps.
> mt2712 Ethernet design is differnet from that in synopsys folder in many
> aspects, and some key features are not included in mt2712, such as rss
> and split header. At the same time, some features we need have not been
> implenmented in synopsys folder.
In general, we don't have two very similar drivers. We try to have one
driver. If the problem was just missing features in the stmmac driver,
you can add them. I doubt not supporting 2.5/4/5Gbps in your silicon
is an issue, since very few STMMAC devices have this. By split header,
do you mean support for TSO? That seems to be a gmac4 or newer
feature, but the driver supports not having tso support in hardware.
Giuseppe, Alexandre, Jose: Please can you look at the proposed driver
and see how much it really differs from the STMMAC driver. How easy
would it be to extend stmmac it to support the mt2712?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] net: ethernet: Fix a unused function warning.
From: David Miller @ 2018-09-17 15:24 UTC (permalink / raw)
To: zhongjiang; +Cc: bryan.whitehead, UNGLinuxDriver, netdev, linux-kernel
In-Reply-To: <1537181059-53563-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Mon, 17 Sep 2018 18:44:19 +0800
> Fix the following compile warning:
>
> drivers/net/ethernet/microchip/lan743x_main.c:2964:12: warning: ‘lan743x_pm_suspend’ defined but not used [-Wunused-function]
> static int lan743x_pm_suspend(struct device *dev)
> drivers/net/ethernet/microchip/lan743x_main.c:2987:12: warning: ‘lan743x_pm_resume’ defined but not used [-Wunused-function]
> static int lan743x_pm_resume(struct device *dev)
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATH RFC net-next 0/8] Continue towards using linkmode in phylib
From: Maxime Chevallier @ 2018-09-17 10:01 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-1-git-send-email-andrew@lunn.ch>
Hi Andrew,
On Fri, 14 Sep 2018 23:38:48 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>These patches contain some further cleanup and helpers, and the first
>real patch towards using linkmode bitmaps in phylink.
>
>It is RFC because i don't like patch #7 and maybe somebody has a
>better idea how to do this. Ideally, we want to initialise a linux
>generic bitmap at compile time.
Thanks for that series. I've reviewed what I feel confident enough to,
I'll be happy to test the runtime "features" listing that I think you
plan to implement.
Maxime
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-17 15:28 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Ard Biesheuvel, Andrew Lutomirski, David Miller, Andrew Lunn,
Eric Biggers, Greg Kroah-Hartman, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <35BC21D7-01F4-4F91-A7E9-8D15DE5B95D6@amacapital.net>
On Mon, Sep 17, 2018 at 4:52 PM Andy Lutomirski <luto@amacapital.net> wrote:
> > * (Nit) The GCC command line -include'd .h files contain variable and
> > function definitions so they are actually .c files.
>
> Hmm. I would suggest just getting rid of the -include magic entirely. The resulting ifdef will be more comprehensible.
I really don't think so, actually. The way the -include stuff works
now is that the glue code is inlined in the same place that the
assembly object file is added to the build object list, so it gels
together cleanly, as the thing is defined and set in one single place.
I could go back to the ifdefs - and even make them as clean as
possible - but I think that puts more things in more places and is
therefore more confusing. The -include system now works extremely
well.
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-17 15:31 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Ard Biesheuvel, Andrew Lutomirski, David Miller, Andrew Lunn,
Eric Biggers, Greg Kroah-Hartman, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <35BC21D7-01F4-4F91-A7E9-8D15DE5B95D6@amacapital.net>
On Mon, Sep 17, 2018 at 4:52 PM Andy Lutomirski <luto@amacapital.net> wrote:
> I think the module organization needs to change. It needs to be possible to have chacha20 built in but AES or whatever as a module.
Okay, I'll do that for v5.
> I might have agreed before Spectre :(. Unfortunately, unless we do some magic, I think the code would look something like:
>
> if (static_branch_likely(have_simd)) arch_chacha20();
>
> ...where arch_chacha20 is a *pointer*. And that will generate a retpoline and run very, very slowly. (I just rewrote some of the x86 entry code to eliminate one retpoline. I got a 5% speedup on some tests according to the kbuild bot.)
Actually, the way it works now benefits from the compilers inliner and
the branch predictor. I benchmarked this without any retpoline
slowdowns, and the branch predictor becomes correct pretty much all
the time. We can tinker with this after the initial merge, if you
really want, but avoiding function pointers and instead using ordinary
branches really winds up being quite fast.
^ permalink raw reply
* Re: [RFC PATCH 3/4] udp: implement GRO plain UDP sockets.
From: Paolo Abeni @ 2018-09-17 10:06 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: David S. Miller, Willem de Bruijn, Steffen Klassert
In-Reply-To: <1e140072-15f6-755c-28be-61534b243d62@gmail.com>
Hi,
On Fri, 2018-09-14 at 09:48 -0700, Eric Dumazet wrote:
> Are you sure the data is actually fully copied to user space ?
>
> tools/testing/selftests/net/udpgso_bench_rx.c
>
> uses :
>
> static char rbuf[ETH_DATA_LEN];
> /* MSG_TRUNC will make return value full datagram length */
> ret = recv(fd, rbuf, len, MSG_TRUNC | MSG_DONTWAIT);
>
> So you need to change this program.
Thank for the feedback.
You are right, I need to update udpgso_bench_rx. Making it
unconditionally read up to 64K bytes, I measure:
Before:
udp rx: 962 MB/s 685339 calls/s
After:
udp rx: 1344 MB/s 22812 calls/s
Top perf offenders for udpgso_bench_rx:
31.83% [kernel] [k] copy_user_enhanced_fast_string
8.90% [kernel] [k] skb_release_data
7.97% [kernel] [k] free_pcppages_bulk
6.82% [kernel] [k] copy_page_to_iter
3.41% [kernel] [k] skb_copy_datagram_iter
2.01% [kernel] [k] free_unref_page
1.92% [kernel] [k] __entry_SYSCALL_64_trampoline
Trivial note: with this even UDP sockets would benefit from remote skb
freeing, as the cost of skb_release_data is relevant for the GSO
packets.
> Also, GRO reception would mean that userspace can retrieve,
> not only full bytes of X datagrams, but also the gso_size (or length of individual datagrams)
>
> You can not know the size of the packets in advance, the sender will decide.
Thanks for pointing that out. I guess that implementing something like
cmsg(UDP_SEGMENT) as Willem suggests in in 8/8 patch would do, right?
I can have a look at that _if_ there is interest in this approch,
Cheers,
Paolo
^ permalink raw reply
* Re: [RFC PATCH 2/4] net: enable UDP gro on demand.
From: Paolo Abeni @ 2018-09-17 10:18 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Network Development, David Miller, Willem de Bruijn,
steffen.klassert
In-Reply-To: <CAF=yD-+OfMMzP-aX=O2KO+XJy0o0zgRf5LJG3ELNABhf_aUh7w@mail.gmail.com>
On Sun, 2018-09-16 at 14:23 -0400, Willem de Bruijn wrote:
> That udp gro implementation is clearly less complete than yours in
> this patchset. The point I wanted to bring up for discussion is not the
> protocol implementation, but the infrastructure for enabling it
> conditionally.
I'm still [trying to] processing your patchset ;) So please perdon me
for any obvious interpretation mistakes...
> Assuming cycle cost is comparable, what do you think of using the
> existing sk offload callbacks to enable this on a per-socket basis?
I have no objection about that, if there are no performance drawbacks.
In my measures retpoline costs is relevant for every indirect call
added. Using the existing sk offload approach will require an
additional indirect call per packet compared to the implementation
here.
> As for the protocol-wide knob, I do strongly prefer something that can
> work for all protocols, not just UDP.
I like the general infrastructure idea. I think there is some agreement
in avoiding the addition of more user-controllable knobs, as we already
have a lot of them. If I read your patch correctly, user-space need to
enable/disable the UDO GSO explicitly via procfs, right?
I tried to look for something that does not require user action.
> I also implemented a version that
> atomically swaps the struct ptr instead of the flag based approach I sent
> for review. I'm fairly agnostic about that point.
I think/fear security oriented guys may scream for the somewhat large
deconstification ?!?
> One subtle issue is that I
> believe we need to keep the gro_complete callbacks enabled, as gro
> packets may be queued for completion when gro_receive gets disabled.
Good point, thanks! I missed that.
Cheers,
Paolo
^ permalink raw reply
* Re: [PATCH bpf-next] tools/bpf: bpftool: improve output format for bpftool net
From: Daniel Borkmann @ 2018-09-17 10:19 UTC (permalink / raw)
To: Yonghong Song, ast, netdev; +Cc: kernel-team
In-Reply-To: <20180914214920.2636189-1-yhs@fb.com>
On 09/14/2018 11:49 PM, Yonghong Song wrote:
> This is a followup patch for Commit f6f3bac08ff9
> ("tools/bpf: bpftool: add net support").
> Some improvements are made for the bpftool net output.
> Specially, plain output is more concise such that
> per attachment should nicely fit in one line.
> Compared to previous output, the prog tag is removed
> since it can be easily obtained with program id.
> Similar to xdp attachments, the device name is added
> to tc_filters attachments.
>
> The bpf program attached through shared block
> mechanism is supported as well.
> $ ip link add dev v1 type veth peer name v2
> $ tc qdisc add dev v1 ingress_block 10 egress_block 20 clsact
> $ tc qdisc add dev v2 ingress_block 10 egress_block 20 clsact
> $ tc filter add block 10 protocol ip prio 25 bpf obj bpf_shared.o sec ingress flowid 1:1
> $ tc filter add block 20 protocol ip prio 30 bpf obj bpf_cyclic.o sec classifier flowid 1:1
> $ bpftool net
> xdp [
> ]
> tc_filters [
> v2(7) qdisc_clsact_ingress bpf_shared.o:[ingress] id 23
> v2(7) qdisc_clsact_egress bpf_cyclic.o:[classifier] id 24
> v1(8) qdisc_clsact_ingress bpf_shared.o:[ingress] id 23
> v1(8) qdisc_clsact_egress bpf_cyclic.o:[classifier] id 24
Just one minor note for this one here, do we even need the "qdisc_" prefix? Couldn't it just simply
be "clsact/ingress", "clsact/egress", "htb" etc?
> ]
>
> The documentation and "bpftool net help" are updated
> to make it clear that current implementation only
> supports xdp and tc attachments. For programs
> attached to cgroups, "bpftool cgroup" can be used
> to dump attachments. For other programs e.g.
> sk_{filter,skb,msg,reuseport} and lwt/seg6,
> iproute2 tools should be used.
>
> The new output:
> $ bpftool net
> xdp [
> eth0(2) id/drv 198
Could we change the "id/{drv,offload,generic} xyz" into e.g. "eth0(2) {driver,offload,generic} id 198",
meaning, the "id xyz" being a child of either "driver", "offload" or "generic". Reason would be two-fold:
i) we can keep the "id xyz" notion consistent as used under "tc_filters", and ii) it allows to put further
information aside from just "id" member under "driver", "offload" or "generic" in the future.
> ]
> tc_filters [
Nit: can we use just "tc" for the above? Main use case would be clsact with one of its two hooks anyway,
and the term "filter" is sort of tc historic; while being correct bpf progs would do much more than just
filtering, and context is pretty clear anyway from qdisc that we subsequently dump.
> eth0(2) qdisc_clsact_ingress fbflow_icmp id 335 act [{icmp_action id 336}]
> eth0(2) qdisc_clsact_egress fbflow_egress id 334
> ]
> $ bpftool -jp net
> [{
> "xdp": [{
> "devname": "eth0",
> "ifindex": 2,
> "id/drv": 198
> }
> ],
> "tc_filters": [{
> "devname": "eth0",
> "ifindex": 2,
> "kind": "qdisc_clsact_ingress",
> "name": "fbflow_icmp",
> "id": 335,
> "act": [{
> "name": "icmp_action",
> "id": 336
> }
> ]
> },{
> "devname": "eth0",
> "ifindex": 2,
> "kind": "qdisc_clsact_egress",
> "name": "fbflow_egress",
> "id": 334
> }
> ]
> }
> ]
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH net-next RFC 7/8] udp: gro behind static key
From: Paolo Abeni @ 2018-09-17 10:24 UTC (permalink / raw)
To: Willem de Bruijn, netdev; +Cc: steffen.klassert, davem, Willem de Bruijn
In-Reply-To: <20180914175941.213950-8-willemdebruijn.kernel@gmail.com>
On Fri, 2018-09-14 at 13:59 -0400, Willem de Bruijn wrote:
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 4f6aa95a9b12..f44fe328aa0f 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -405,7 +405,7 @@ static struct sk_buff *udp4_gro_receive(struct list_head *head,
> {
> struct udphdr *uh = udp_gro_udphdr(skb);
>
> - if (unlikely(!uh))
> + if (unlikely(!uh) || !static_branch_unlikely(&udp_encap_needed_key))
> goto flush;
>
> /* Don't bother verifying checksum if we're going to flush anyway. */
If I read this correctly, once udp_encap_needed_key is enabled, it will
never be turned off, because the tunnel and encap socket shut down does
not cope with udp_encap_needed_key.
Perhaps we should take care of that, too.
Cheers,
Paolo
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-17 15:52 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andrew Lutomirski, David Miller, Andrew Lunn, Eric Biggers,
Greg Kroah-Hartman, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <CAKv+Gu8QgRo-Oex2Sk5unET3FMq+1Cp2btAWXCB8xsALxjatHg@mail.gmail.com>
Hi Ard,
On Mon, Sep 17, 2018 at 7:26 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> OK, so let me summarize my remaining concerns as well. I may be a bit
> more finicky than Andy, though.
Yes, and generally hostile to this whole initiative since the
beginning. But I am very grateful for your reviews nonetheless, and
I'll do my best to incorporate as much as is reasonable.
> I would like to urge Jason to
> bear with us and bring this discussion to a close before resubmitting.
What I fear is that either:
- You don't like the Zinc initiative in one way or another, and the
desire to "keep discussing" and adding more things is less out of
their necessity and more out of a desire to stall it indefinitely.
- You're going to bikeshed and bikeshed and waste tons of time until
Zinc copies lots of the same design decisions from the present crypto
API.
I do sincerely hope these are only fears and not what actually is
going on. I'll do my best to take into serious consideration what you
say -- many are indeed extremely helpful -- but I certainly won't be
wholesale accepting all the things you've mentioned.
Nevertheless, I'll make sure v5 has a pretty healthy quantity of
improvements in it before resubmitting.
> * simd_relax() is currently not called by the crypto routines
> themselves. This means that the worst case scheduling latency is
> unbounded, which is unacceptable for the -rt kernel. The worst case
> scheduling latency should never be proportional to the input size.
> (Apologies for not spotting that earlier)
Good catch. I actually did this correct when porting the crypto API to
use Zinc (in those later top commits in v4), but I hadn't in the Zinc
code itself. I'll address this for v5.
> maintainership
> responsibilities
Samuel and I intend to maintain Zinc in lib/zinc/ and send future
updates to it through Greg's tree, as mentioned in the 00/ cover
letter. The maintainership of the existing crypto API won't change.
> * The current organization of the code puts all available (for the
> arch) versions of all routines into a single module, which can only be
> built in once we update random.c to use Zinc's chacha20 routines. This
> bloats the core kernel (which is a huge deal for embedded systems that
> have very strict boot requirements).
I'll split each Zinc primitive into a separate module for v5, per your
and Andy's desire. And the SIMD code is already toggle-able via a
Kconfig menu option.
> we should
> work with Andy Polyakov (as I have done several times over the past 5+
> years) to upstream the changes we apply to the kernel version of the
> code.
Indeed this is the intent.
> The same applies to code from other sources, btw, but I am not
> personally familiar with them.
Good news on this front:
- Rene wrote the MIPS code specifically for WireGuard, so that _is_ upstream.
- Samuel wrote the BLAKE2 assembly, and he's the co-maintainer of Zinc with me.
- I talk to Dan and Peter a decent amount about qhasm.
- I'm in very close contact with the team behind HACL*, and they're
treating Zinc as a target -- stylistically and with regards to kernel
requirements -- which means they're looking at what's happening in
this patchset and adjusting accordingly.
> * If upstreaming the changes is not an option, they should be applied
> as a separate patch and not hidden in a 5000 line patch without any
> justification or documentation (but Jason is already working on that)
Indeed this is already underway.
Thanks again for your review.
Jason
^ permalink raw reply
* [PATCH rdma-next 0/4] mlx5 vport loopback
From: Leon Romanovsky @ 2018-09-17 10:30 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Mark Bloch, Yishai Hadas,
Saeed Mahameed, linux-netdev
From: Leon Romanovsky <leonro@mellanox.com>
Hi,
This is short series from Mark which extends handling of loopback
traffic. Originally mlx5 IB dynamically enabled/disabled both unicast
and multicast based on number of users. However RAW ethernet QPs need
more granular access.
Thanks
Mark Bloch (4):
net/mlx5: Rename incorrect naming in IFC file
RDMA/mlx5: Refactor transport domain bookkeeping logic
RDMA/mlx5: Allow creating RAW ethernet QP with loopback support
RDMA/mlx5: Enable vport loopback when user context or QP mandate
drivers/infiniband/hw/mlx5/main.c | 61 ++++++++++----
drivers/infiniband/hw/mlx5/mlx5_ib.h | 16 +++-
drivers/infiniband/hw/mlx5/qp.c | 96 +++++++++++++++++-----
.../net/ethernet/mellanox/mlx5/core/en_common.c | 2 +-
include/linux/mlx5/mlx5_ifc.h | 4 +-
include/uapi/rdma/mlx5-abi.h | 2 +
6 files changed, 138 insertions(+), 43 deletions(-)
^ permalink raw reply
* [PATCH mlx5-next 1/4] net/mlx5: Rename incorrect naming in IFC file
From: Leon Romanovsky @ 2018-09-17 10:30 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Mark Bloch, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180917103049.18235-1-leon@kernel.org>
From: Mark Bloch <markb@mellanox.com>
Remove a trailing underscore from the multicast/unicast names.
Signed-off-by: Mark Bloch <markb@mellanox.com>
Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/hw/mlx5/qp.c | 4 ++--
drivers/net/ethernet/mellanox/mlx5/core/en_common.c | 2 +-
include/linux/mlx5/mlx5_ifc.h | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 1f35ecbefffe..8bada4b94444 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -1279,7 +1279,7 @@ static int create_raw_packet_qp_tir(struct mlx5_ib_dev *dev,
if (dev->rep)
MLX5_SET(tirc, tirc, self_lb_block,
- MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST_);
+ MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST);
err = mlx5_core_create_tir(dev->mdev, in, inlen, &rq->tirn);
@@ -1582,7 +1582,7 @@ static int create_rss_raw_qp_tir(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
create_tir:
if (dev->rep)
MLX5_SET(tirc, tirc, self_lb_block,
- MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST_);
+ MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST);
err = mlx5_core_create_tir(dev->mdev, in, inlen, &qp->rss_qp.tirn);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_common.c b/drivers/net/ethernet/mellanox/mlx5/core/en_common.c
index db3278cc052b..3078491cc0d0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_common.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_common.c
@@ -153,7 +153,7 @@ int mlx5e_refresh_tirs(struct mlx5e_priv *priv, bool enable_uc_lb)
if (enable_uc_lb)
MLX5_SET(modify_tir_in, in, ctx.self_lb_block,
- MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST_);
+ MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST);
MLX5_SET(modify_tir_in, in, bitmask.self_lb_en, 1);
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 3a4a2e0567e9..4c7a1d25d73b 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -2559,8 +2559,8 @@ enum {
};
enum {
- MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST_ = 0x1,
- MLX5_TIRC_SELF_LB_BLOCK_BLOCK_MULTICAST_ = 0x2,
+ MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST = 0x1,
+ MLX5_TIRC_SELF_LB_BLOCK_BLOCK_MULTICAST = 0x2,
};
struct mlx5_ifc_tirc_bits {
--
2.14.4
^ permalink raw reply related
* [PATCH rdma-next 3/4] RDMA/mlx5: Allow creating RAW ethernet QP with loopback support
From: Leon Romanovsky @ 2018-09-17 10:30 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Mark Bloch, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180917103049.18235-1-leon@kernel.org>
From: Mark Bloch <markb@mellanox.com>
Expose two new flags:
MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC
MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_MC
Those flags can be used at creation time in order to allow a QP
to be able to receive loopback traffic (unicast and multicast).
We store the state in the QP to be used on the destroy path
to indicate with which flags the QP was created with.
Signed-off-by: Mark Bloch <markb@mellanox.com>
Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/hw/mlx5/mlx5_ib.h | 2 +-
drivers/infiniband/hw/mlx5/qp.c | 62 ++++++++++++++++++++++++++++--------
include/uapi/rdma/mlx5-abi.h | 2 ++
3 files changed, 52 insertions(+), 14 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index 7b2af7e719c4..b258adb93097 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -440,7 +440,7 @@ struct mlx5_ib_qp {
struct list_head cq_send_list;
struct mlx5_rate_limit rl;
u32 underlay_qpn;
- bool tunnel_offload_en;
+ u32 flags_en;
/* storage for qp sub type when core qp type is IB_QPT_DRIVER */
enum ib_qp_type qp_sub_type;
};
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 8bada4b94444..428e417e01da 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -1258,8 +1258,9 @@ static bool tunnel_offload_supported(struct mlx5_core_dev *dev)
static int create_raw_packet_qp_tir(struct mlx5_ib_dev *dev,
struct mlx5_ib_rq *rq, u32 tdn,
- bool tunnel_offload_en)
+ u32 *qp_flags_en)
{
+ u8 lb_flag = 0;
u32 *in;
void *tirc;
int inlen;
@@ -1274,12 +1275,21 @@ static int create_raw_packet_qp_tir(struct mlx5_ib_dev *dev,
MLX5_SET(tirc, tirc, disp_type, MLX5_TIRC_DISP_TYPE_DIRECT);
MLX5_SET(tirc, tirc, inline_rqn, rq->base.mqp.qpn);
MLX5_SET(tirc, tirc, transport_domain, tdn);
- if (tunnel_offload_en)
+ if (*qp_flags_en & MLX5_QP_FLAG_TUNNEL_OFFLOADS)
MLX5_SET(tirc, tirc, tunneled_offload_en, 1);
- if (dev->rep)
- MLX5_SET(tirc, tirc, self_lb_block,
- MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST);
+ if (*qp_flags_en & MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC)
+ lb_flag |= MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST;
+
+ if (*qp_flags_en & MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_MC)
+ lb_flag |= MLX5_TIRC_SELF_LB_BLOCK_BLOCK_MULTICAST;
+
+ if (dev->rep) {
+ lb_flag |= MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST;
+ *qp_flags_en |= MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC;
+ }
+
+ MLX5_SET(tirc, tirc, self_lb_block, lb_flag);
err = mlx5_core_create_tir(dev->mdev, in, inlen, &rq->tirn);
@@ -1332,8 +1342,7 @@ static int create_raw_packet_qp(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
goto err_destroy_sq;
- err = create_raw_packet_qp_tir(dev, rq, tdn,
- qp->tunnel_offload_en);
+ err = create_raw_packet_qp_tir(dev, rq, tdn, &qp->flags_en);
if (err)
goto err_destroy_rq;
}
@@ -1410,6 +1419,7 @@ static int create_rss_raw_qp_tir(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
u32 tdn = mucontext->tdn;
struct mlx5_ib_create_qp_rss ucmd = {};
size_t required_cmd_sz;
+ u8 lb_flag = 0;
if (init_attr->qp_type != IB_QPT_RAW_PACKET)
return -EOPNOTSUPP;
@@ -1444,7 +1454,9 @@ static int create_rss_raw_qp_tir(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
return -EOPNOTSUPP;
}
- if (ucmd.flags & ~MLX5_QP_FLAG_TUNNEL_OFFLOADS) {
+ if (ucmd.flags & ~(MLX5_QP_FLAG_TUNNEL_OFFLOADS |
+ MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC |
+ MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_MC)) {
mlx5_ib_dbg(dev, "invalid flags\n");
return -EOPNOTSUPP;
}
@@ -1461,6 +1473,16 @@ static int create_rss_raw_qp_tir(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
return -EOPNOTSUPP;
}
+ if (ucmd.flags & MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC || dev->rep) {
+ lb_flag |= MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST;
+ qp->flags_en |= MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC;
+ }
+
+ if (ucmd.flags & MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_MC) {
+ lb_flag |= MLX5_TIRC_SELF_LB_BLOCK_BLOCK_MULTICAST;
+ qp->flags_en |= MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_MC;
+ }
+
err = ib_copy_to_udata(udata, &resp, min(udata->outlen, sizeof(resp)));
if (err) {
mlx5_ib_dbg(dev, "copy failed\n");
@@ -1484,6 +1506,8 @@ static int create_rss_raw_qp_tir(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
if (ucmd.flags & MLX5_QP_FLAG_TUNNEL_OFFLOADS)
MLX5_SET(tirc, tirc, tunneled_offload_en, 1);
+ MLX5_SET(tirc, tirc, self_lb_block, lb_flag);
+
if (ucmd.rx_hash_fields_mask & MLX5_RX_HASH_INNER)
hfso = MLX5_ADDR_OF(tirc, tirc, rx_hash_field_selector_inner);
else
@@ -1580,10 +1604,6 @@ static int create_rss_raw_qp_tir(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
MLX5_SET(rx_hash_field_select, hfso, selected_fields, selected_fields);
create_tir:
- if (dev->rep)
- MLX5_SET(tirc, tirc, self_lb_block,
- MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST);
-
err = mlx5_core_create_tir(dev->mdev, in, inlen, &qp->rss_qp.tirn);
if (err)
@@ -1710,7 +1730,23 @@ static int create_qp_common(struct mlx5_ib_dev *dev, struct ib_pd *pd,
mlx5_ib_dbg(dev, "Tunnel offload isn't supported\n");
return -EOPNOTSUPP;
}
- qp->tunnel_offload_en = true;
+ qp->flags_en |= MLX5_QP_FLAG_TUNNEL_OFFLOADS;
+ }
+
+ if (ucmd.flags & MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC) {
+ if (init_attr->qp_type != IB_QPT_RAW_PACKET) {
+ mlx5_ib_dbg(dev, "Self-LB UC isn't supported\n");
+ return -EOPNOTSUPP;
+ }
+ qp->flags_en |= MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC;
+ }
+
+ if (ucmd.flags & MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_MC) {
+ if (init_attr->qp_type != IB_QPT_RAW_PACKET) {
+ mlx5_ib_dbg(dev, "Self-LB UM isn't supported\n");
+ return -EOPNOTSUPP;
+ }
+ qp->flags_en |= MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_MC;
}
if (init_attr->create_flags & IB_QP_CREATE_SOURCE_QPN) {
diff --git a/include/uapi/rdma/mlx5-abi.h b/include/uapi/rdma/mlx5-abi.h
index addbb9c4529e..e584ba40208e 100644
--- a/include/uapi/rdma/mlx5-abi.h
+++ b/include/uapi/rdma/mlx5-abi.h
@@ -45,6 +45,8 @@ enum {
MLX5_QP_FLAG_BFREG_INDEX = 1 << 3,
MLX5_QP_FLAG_TYPE_DCT = 1 << 4,
MLX5_QP_FLAG_TYPE_DCI = 1 << 5,
+ MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_UC = 1 << 6,
+ MLX5_QP_FLAG_TIR_ALLOW_SELF_LB_MC = 1 << 7,
};
enum {
--
2.14.4
^ permalink raw reply related
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