* Re: [PATCH v3 bpf-next 0/4] selftests/bpf: fix compiling loop{1,2,3}.c on s390
From: Andrii Nakryiko @ 2019-07-09 17:50 UTC (permalink / raw)
To: Ilya Leoshkevich
Cc: bpf, Networking, Stanislav Fomichev, Y Song, David S. Miller,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190709151809.37539-1-iii@linux.ibm.com>
On Tue, Jul 9, 2019 at 8:18 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> Use PT_REGS_RC(ctx) instead of ctx->rax, which is not present on s390.
>
> This patch series consists of three preparatory commits, which make it
> possible to use PT_REGS_RC in BPF selftests, followed by the actual fix.
>
> Since the last time, I've tested it with x86_64-linux-gnu-,
> aarch64-linux-gnu-, arm-linux-gnueabihf-, mips64el-linux-gnuabi64-,
> powerpc64le-linux-gnu-, s390x-linux-gnu- and sparc64-linux-gnu-
> compilers, and found that I also need to add arm64 support.
>
> Like s390, arm64 exports user_pt_regs instead of struct pt_regs to
> userspace.
>
> I've also made fixes for a few unrelated build problems, which I will
> post separately.
>
> v1->v2: Split into multiple patches.
> v2->v3: Added arm64 support.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>
>
Acked-by: Andrii Nakryiko <andriin@fb.com>
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/4] selftests/bpf: make PT_REGS_* work in userspace
From: Andrii Nakryiko @ 2019-07-09 17:48 UTC (permalink / raw)
To: Ilya Leoshkevich
Cc: bpf, Networking, Stanislav Fomichev, Y Song, David S. Miller,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190709151809.37539-4-iii@linux.ibm.com>
On Tue, Jul 9, 2019 at 8:19 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> Right now, on certain architectures, these macros are usable only with
> kernel headers. This patch makes it possible to use them with userspace
> headers and, as a consequence, not only in BPF samples, but also in BPF
> selftests.
>
> On s390, provide the forward declaration of struct pt_regs and cast it
> to user_pt_regs in PT_REGS_* macros. This is necessary, because instead
> of the full struct pt_regs, s390 exposes only its first member
> user_pt_regs to userspace, and bpf_helpers.h is used with both userspace
> (in selftests) and kernel (in samples) headers. It was added in commit
> 466698e654e8 ("s390/bpf: correct broken uapi for
> BPF_PROG_TYPE_PERF_EVENT program type").
>
> Ditto on arm64.
>
> On x86, provide userspace versions of PT_REGS_* macros. Unlike s390 and
> arm64, x86 provides struct pt_regs to both userspace and kernel, however,
> with different member names.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
Just curious, what did you use as a reference for which register
corresponds to which PARM, RET, etc for different archs? I've tried to
look it up the other day, and it wasn't as straightforward to find as
I hoped for, so maybe I'm missing something obvious.
> tools/testing/selftests/bpf/bpf_helpers.h | 61 +++++++++++++++--------
> 1 file changed, 41 insertions(+), 20 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> index 73071a94769a..212ec564e5c3 100644
> --- a/tools/testing/selftests/bpf/bpf_helpers.h
> +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> @@ -358,6 +358,7 @@ static int (*bpf_skb_adjust_room)(void *ctx, __s32 len_diff, __u32 mode,
>
> #if defined(bpf_target_x86)
>
> +#ifdef __KERNEL__
> #define PT_REGS_PARM1(x) ((x)->di)
> #define PT_REGS_PARM2(x) ((x)->si)
> #define PT_REGS_PARM3(x) ((x)->dx)
> @@ -368,19 +369,35 @@ static int (*bpf_skb_adjust_room)(void *ctx, __s32 len_diff, __u32 mode,
> #define PT_REGS_RC(x) ((x)->ax)
> #define PT_REGS_SP(x) ((x)->sp)
> #define PT_REGS_IP(x) ((x)->ip)
> +#else
> +#define PT_REGS_PARM1(x) ((x)->rdi)
> +#define PT_REGS_PARM2(x) ((x)->rsi)
> +#define PT_REGS_PARM3(x) ((x)->rdx)
> +#define PT_REGS_PARM4(x) ((x)->rcx)
> +#define PT_REGS_PARM5(x) ((x)->r8)
> +#define PT_REGS_RET(x) ((x)->rsp)
> +#define PT_REGS_FP(x) ((x)->rbp)
> +#define PT_REGS_RC(x) ((x)->rax)
> +#define PT_REGS_SP(x) ((x)->rsp)
> +#define PT_REGS_IP(x) ((x)->rip)
Will this also work for 32-bit x86?
> +#endif
<snip>
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] bpf, libbpf: add a new API bpf_object__reuse_maps()
From: Andrii Nakryiko @ 2019-07-09 17:40 UTC (permalink / raw)
To: Anton Protopopov
Cc: Daniel Borkmann, Alexei Starovoitov, Martin KaFai Lau, Song Liu,
Yonghong Song, Networking, bpf, open list, Andrii Nakryiko
In-Reply-To: <CAGn_itw=BqWXn7ibg6M7j4r2T5CMo0paBhBoQQv7b+x7D2g2ww@mail.gmail.com>
On Mon, Jul 8, 2019 at 1:37 PM Anton Protopopov
<a.s.protopopov@gmail.com> wrote:
>
> пн, 8 июл. 2019 г. в 13:54, Andrii Nakryiko <andrii.nakryiko@gmail.com>:
> >
> > On Fri, Jul 5, 2019 at 2:53 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > >
> > > On 07/05/2019 10:44 PM, Anton Protopopov wrote:
> > > > Add a new API bpf_object__reuse_maps() which can be used to replace all maps in
> > > > an object by maps pinned to a directory provided in the path argument. Namely,
> > > > each map M in the object will be replaced by a map pinned to path/M.name.
> > > >
> > > > Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
> > > > ---
> > > > tools/lib/bpf/libbpf.c | 34 ++++++++++++++++++++++++++++++++++
> > > > tools/lib/bpf/libbpf.h | 2 ++
> > > > tools/lib/bpf/libbpf.map | 1 +
> > > > 3 files changed, 37 insertions(+)
> > > >
> > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > > index 4907997289e9..84c9e8f7bfd3 100644
> > > > --- a/tools/lib/bpf/libbpf.c
> > > > +++ b/tools/lib/bpf/libbpf.c
> > > > @@ -3144,6 +3144,40 @@ int bpf_object__unpin_maps(struct bpf_object *obj, const char *path)
> > > > return 0;
> > > > }
> > > >
> > > > +int bpf_object__reuse_maps(struct bpf_object *obj, const char *path)
> >
> > As is, bpf_object__reuse_maps() can be easily implemented by user
> > applications, as it's only using public libbpf APIs, so I'm not 100%
> > sure we need to add method like that to libbpf.
>
> The bpf_object__reuse_maps() can definitely be implemented by user
> applications, however, to use it a user also needs to re-implement the
> bpf_prog_load_xattr funciton, so it seemed to me that adding this
> functionality to the library is a better way.
I'm still not convinced. Looking at bpf_prog_load_xattr, I think some
of what it's doing should be part of bpf_object__object_xattr anyway
(all the expected type setting for programs).
Besides that, there isn't much more than just bpf_object__open and
bpf_object__load, to be honest. By doing open and load explicitly,
user gets an opportunity to do whatever adjustment they need: reuse
maps, adjust map sizes, etc. So I think we should improve
bpf_object__open to "guess" program attach types and add map
definition flags to allow reuse declaratively.
>
> >
> > > > +{
> > > > + struct bpf_map *map;
> > > > +
> > > > + if (!obj)
> > > > + return -ENOENT;
> > > > +
> > > > + if (!path)
> > > > + return -EINVAL;
> > > > +
> > > > + bpf_object__for_each_map(map, obj) {
> > > > + int len, err;
> > > > + int pinned_map_fd;
> > > > + char buf[PATH_MAX];
> > >
> > > We'd need to skip the case of bpf_map__is_internal(map) since they are always
> > > recreated for the given object.
> > >
> > > > + len = snprintf(buf, PATH_MAX, "%s/%s", path, bpf_map__name(map));
> > > > + if (len < 0) {
> > > > + return -EINVAL;
> > > > + } else if (len >= PATH_MAX) {
> > > > + return -ENAMETOOLONG;
> > > > + }
> > > > +
> > > > + pinned_map_fd = bpf_obj_get(buf);
> > > > + if (pinned_map_fd < 0)
> > > > + return pinned_map_fd;
> > >
> > > Should we rather have a new map definition attribute that tells to reuse
> > > the map if it's pinned in bpf fs, and if not, we create it and later on
> > > pin it? This is what iproute2 is doing and which we're making use of heavily.
> >
> > I'd like something like that as well. This would play nicely with
> > recently added BTF-defined maps as well.
> >
> > I think it should be not just pin/don't pin flag, but rather pinning
> > strategy, to accommodate various typical strategies of handling maps
> > that are already pinned. So something like this:
> >
> > 1. BPF_PIN_NOTHING - default, don't pin;
> > 2. BPF_PIN_EXCLUSIVE - pin, but if map is already pinned - fail;
> > 3. BPF_PIN_SET - pin; if existing map exists, reset its state to be
> > exact state of object's map;
> > 4. BPF_PIN_MERGE - pin, if map exists, fill in NULL entries only (this
> > is how Cilium is pinning PROG_ARRAY maps, if I understand correctly);
> > 5. BPF_PIN_MERGE_OVERWRITE - pin, if map exists, overwrite non-NULL values.
> >
> > This list is only for illustrative purposes, ideally people that have
> > a lot of experience using pinning for real-world use cases would chime
> > in on what strategies are useful and make sense.
>
> My case was simply to reuse existing maps when reloading a program.
> Does it make sense for you to add only the simplest cases of listed above?
Of course, it's enum, so we can start with few clearly useful ones and
then expand more if we ever have a need. But I think we still need a
bit wider discussion and let people who use pinning to chime in.
>
> Also, libbpf doesn't use standard naming conventions for pinning maps.
We talked about this in another thread related to BTF-defined maps. I
think the way to go with this is to actually define a default pinning
root path, but allow to override it on bpf_object__open, if user needs
a different one.
> Does it make sense to provide a list of already open maps to the
> bpf_prog_load_xattr function as an attribute? In this case a user
> can execute his own policy on pinning, but still will have an option
> to reuse, reset, and merge maps.
As explained above, I don't think there isn't much added value in
bpf_prog_load, so I'd advise to just switch to explicit
bpf_object__open + bpf_object__load and get maximum control and
flexibility.
>
> >
> > > In bpf_object__reuse_maps() bailing out if bpf_obj_get() fails is perhaps
> > > too limiting for a generic API as new version of an object file may contain
> > > new maps which are not yet present in bpf fs at that point.
> > >
> > > > + err = bpf_map__reuse_fd(map, pinned_map_fd);
> > > > + if (err)
> > > > + return err;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > int bpf_object__pin_programs(struct bpf_object *obj, const char *path)
> > > > {
> > > > struct bpf_program *prog;
> > > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > > > index d639f47e3110..7fe465a1be76 100644
> > > > --- a/tools/lib/bpf/libbpf.h
> > > > +++ b/tools/lib/bpf/libbpf.h
> > > > @@ -82,6 +82,8 @@ int bpf_object__variable_offset(const struct bpf_object *obj, const char *name,
> > > > LIBBPF_API int bpf_object__pin_maps(struct bpf_object *obj, const char *path);
> > > > LIBBPF_API int bpf_object__unpin_maps(struct bpf_object *obj,
> > > > const char *path);
> > > > +LIBBPF_API int bpf_object__reuse_maps(struct bpf_object *obj,
> > > > + const char *path);
> > > > LIBBPF_API int bpf_object__pin_programs(struct bpf_object *obj,
> > > > const char *path);
> > > > LIBBPF_API int bpf_object__unpin_programs(struct bpf_object *obj,
> > > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > > > index 2c6d835620d2..66a30be6696c 100644
> > > > --- a/tools/lib/bpf/libbpf.map
> > > > +++ b/tools/lib/bpf/libbpf.map
> > > > @@ -172,5 +172,6 @@ LIBBPF_0.0.4 {
> > > > btf_dump__new;
> > > > btf__parse_elf;
> > > > bpf_object__load_xattr;
> > > > + bpf_object__reuse_maps;
> > > > libbpf_num_possible_cpus;
> > > > } LIBBPF_0.0.3;
> > > >
> > >
^ permalink raw reply
* Re: [PATCH iproute2 1/2] Revert "ip6tunnel: fix 'ip -6 {show|change} dev <name>' cmds"
From: Stephen Hemminger @ 2019-07-09 17:39 UTC (permalink / raw)
To: David Ahern; +Cc: Andrea Claudi, netdev, dsahern
In-Reply-To: <2460e246-5032-7804-fbc7-e689cebb4abe@gmail.com>
On Tue, 9 Jul 2019 11:14:00 -0600
David Ahern <dsahern@gmail.com> wrote:
> On 7/9/19 7:16 AM, Andrea Claudi wrote:
> > This reverts commit ba126dcad20e6d0e472586541d78bdd1ac4f1123.
> > It breaks tunnel creation when using 'dev' parameter:
> >
> > $ ip link add type dummy
> > $ ip -6 tunnel add ip6tnl1 mode ip6ip6 remote 2001:db8:ffff:100::2 local 2001:db8:ffff:100::1 hoplimit 1 tclass 0x0 dev dummy0
> > add tunnel "ip6tnl0" failed: File exists
> >
> > dev parameter must be used to specify the device to which
> > the tunnel is binded, and not the tunnel itself.
> >
>
> Stephen: since this reverts a commit in 5.2 it should be in 5.2 as well.
5.2 has been released. Probably not worth doing 5.2.1 for corner case like this.
^ permalink raw reply
* Re: [PATCH iproute2 1/2] Revert "ip6tunnel: fix 'ip -6 {show|change} dev <name>' cmds"
From: Mahesh Bandewar (महेश बंडेवार) @ 2019-07-09 17:31 UTC (permalink / raw)
To: Andrea Claudi; +Cc: linux-netdev, stephen, dsahern
In-Reply-To: <5caaac096e5bbbf88ad3aedcc50ff2451f94105c.1562667648.git.aclaudi@redhat.com>
On Tue, Jul 9, 2019 at 6:16 AM Andrea Claudi <aclaudi@redhat.com> wrote:
>
> This reverts commit ba126dcad20e6d0e472586541d78bdd1ac4f1123.
> It breaks tunnel creation when using 'dev' parameter:
>
> $ ip link add type dummy
> $ ip -6 tunnel add ip6tnl1 mode ip6ip6 remote 2001:db8:ffff:100::2 local 2001:db8:ffff:100::1 hoplimit 1 tclass 0x0 dev dummy0
> add tunnel "ip6tnl0" failed: File exists
>
> dev parameter must be used to specify the device to which
> the tunnel is binded, and not the tunnel itself.
>
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Reviewed-by: Matteo Croce <mcroce@redhat.com>
> Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
> ---
> ip/ip6tunnel.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/ip/ip6tunnel.c b/ip/ip6tunnel.c
> index 56fd3466ed062..999408ed801b1 100644
> --- a/ip/ip6tunnel.c
> +++ b/ip/ip6tunnel.c
> @@ -298,8 +298,6 @@ static int parse_args(int argc, char **argv, int cmd, struct ip6_tnl_parm2 *p)
> p->link = ll_name_to_index(medium);
> if (!p->link)
> return nodev(medium);
> - else
> - strlcpy(p->name, medium, sizeof(p->name));
NACK
I see that ba126dcad20e6d0e472586541d78bdd1ac4f1123 has broke
something but that doesn't mean revert of the original fix is correct
way of fixing it. The original fix is fixing the show and change
command. Shouldn't you try fixing the add command so that all (show,
change, and add) work correctly?
> }
> return 0;
> }
> --
> 2.20.1
>
^ permalink raw reply
* [PATCH net-next iproute2 v1] devlink: Show devlink port number
From: Parav Pandit @ 2019-07-09 17:26 UTC (permalink / raw)
To: netdev; +Cc: stephen, jiri, dsahern, Parav Pandit
In-Reply-To: <20190709163352.20371-1-parav@mellanox.com>
Show devlink port number whenever kernel reports that attribute.
An example output for a physical port.
$ devlink port show
pci/0000:06:00.1/65535: type eth netdev eth1_p1 flavour physical port 1
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
---
Changelog:
v0->v1:
- Declare and assign port_number as two different lines.
---
devlink/devlink.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 559f624e..c5491877 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -2806,6 +2806,12 @@ static void pr_out_port(struct dl *dl, struct nlattr **tb)
pr_out_str(dl, "flavour", port_flavour_name(port_flavour));
}
+ if (tb[DEVLINK_ATTR_PORT_NUMBER]) {
+ uint32_t port_number;
+
+ port_number = mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_NUMBER]);
+ pr_out_uint(dl, "port", port_number);
+ }
if (tb[DEVLINK_ATTR_PORT_SPLIT_GROUP])
pr_out_uint(dl, "split_group",
mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_SPLIT_GROUP]));
--
2.19.2
^ permalink raw reply related
* RE: [PATCH net-next iproute2] devlink: Show devlink port number
From: Parav Pandit @ 2019-07-09 17:21 UTC (permalink / raw)
To: David Ahern, netdev@vger.kernel.org
Cc: stephen@networkplumber.org, Jiri Pirko, dsahern@kernel.org
In-Reply-To: <cb5ec628-9274-5c09-1412-2c80b12890e2@gmail.com>
> -----Original Message-----
> From: David Ahern <dsahern@gmail.com>
> Sent: Tuesday, July 9, 2019 10:41 PM
> To: Parav Pandit <parav@mellanox.com>; netdev@vger.kernel.org
> Cc: stephen@networkplumber.org; Jiri Pirko <jiri@mellanox.com>;
> dsahern@kernel.org
> Subject: Re: [PATCH net-next iproute2] devlink: Show devlink port number
>
> On 7/9/19 10:33 AM, Parav Pandit wrote:
> > @@ -2806,6 +2806,11 @@ static void pr_out_port(struct dl *dl, struct
> > nlattr **tb)
> >
> > pr_out_str(dl, "flavour", port_flavour_name(port_flavour));
> > }
> > + if (tb[DEVLINK_ATTR_PORT_NUMBER]) {
> > + uint32_t port_number =
> > +
> mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_NUMBER]);
>
> declare and assign separately; nothing is gained when it is split across lines
> like that.
>
Ok. I was misled by an example of port_flavour which assigns and declare in same line.
Sending v1.
> > + pr_out_uint(dl, "port", port_number);
> > + }
> > if (tb[DEVLINK_ATTR_PORT_SPLIT_GROUP])
> > pr_out_uint(dl, "split_group",
> >
> mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_SPLIT_GROUP]));
^ permalink raw reply
* Re: [PATCH iproute2 1/2] Revert "ip6tunnel: fix 'ip -6 {show|change} dev <name>' cmds"
From: David Ahern @ 2019-07-09 17:14 UTC (permalink / raw)
To: Andrea Claudi, netdev; +Cc: stephen, dsahern
In-Reply-To: <5caaac096e5bbbf88ad3aedcc50ff2451f94105c.1562667648.git.aclaudi@redhat.com>
On 7/9/19 7:16 AM, Andrea Claudi wrote:
> This reverts commit ba126dcad20e6d0e472586541d78bdd1ac4f1123.
> It breaks tunnel creation when using 'dev' parameter:
>
> $ ip link add type dummy
> $ ip -6 tunnel add ip6tnl1 mode ip6ip6 remote 2001:db8:ffff:100::2 local 2001:db8:ffff:100::1 hoplimit 1 tclass 0x0 dev dummy0
> add tunnel "ip6tnl0" failed: File exists
>
> dev parameter must be used to specify the device to which
> the tunnel is binded, and not the tunnel itself.
>
Stephen: since this reverts a commit in 5.2 it should be in 5.2 as well.
^ permalink raw reply
* Re: [PATCH net-next iproute2] devlink: Show devlink port number
From: David Ahern @ 2019-07-09 17:11 UTC (permalink / raw)
To: Parav Pandit, netdev; +Cc: stephen, jiri, dsahern
In-Reply-To: <20190709163352.20371-1-parav@mellanox.com>
On 7/9/19 10:33 AM, Parav Pandit wrote:
> @@ -2806,6 +2806,11 @@ static void pr_out_port(struct dl *dl, struct nlattr **tb)
>
> pr_out_str(dl, "flavour", port_flavour_name(port_flavour));
> }
> + if (tb[DEVLINK_ATTR_PORT_NUMBER]) {
> + uint32_t port_number =
> + mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_NUMBER]);
declare and assign separately; nothing is gained when it is split across
lines like that.
> + pr_out_uint(dl, "port", port_number);
> + }
> if (tb[DEVLINK_ATTR_PORT_SPLIT_GROUP])
> pr_out_uint(dl, "split_group",
> mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_SPLIT_GROUP]));
^ permalink raw reply
* Re: [PATCH v1 01/22] docs: Documentation/*.txt: rename all ReST files to *.rst
From: Rob Herring @ 2019-07-09 17:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, linux-fbdev, linux-ia64, kvm, linux-sh,
linux-pci, dri-devel, platform-driver-x86, kernel-hardening,
sparclinux, linux-arch, linux-s390, Jonathan Corbet, x86,
linux-security-module, devicetree, linux-watchdog,
Mauro Carvalho Chehab, linux-block, linux-gpio,
openipmi-developer, linux-arm-kernel, linaro-mm-sig, linux-parisc,
linux-mm, netdev, linux-wireless, linux-kernel, iommu,
linux-crypto
In-Reply-To: <6b6b6db8d6de9b66223dd6d4b43eb60ead4c71d7.1560891322.git.mchehab+samsung@kernel.org>
On Tue, Jun 18, 2019 at 06:05:25PM -0300, Mauro Carvalho Chehab wrote:
> Those files are actually at ReST format. Ok, currently, they
> don't belong to any place yet at the organized book series,
> but we don't want patches to break them as ReST files. So,
> rename them and add a :orphan: in order to shut up warning
> messages like those:
>
> ...
> Documentation/svga.rst: WARNING: document isn't included in any toctree
> Documentation/switchtec.rst: WARNING: document isn't included in any toctree
> ...
>
> Later patches will move them to a better place and remove the
> :orphan: markup.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> I had to remove the long list of maintainers got by
> getpatch.pl, as it was too long. I opted to keep only the
> mailing lists.
>
> Documentation/ABI/removed/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-devices-node | 2 +-
> Documentation/ABI/testing/procfs-diskstats | 2 +-
> Documentation/ABI/testing/sysfs-block | 2 +-
> .../ABI/testing/sysfs-class-switchtec | 2 +-
> .../ABI/testing/sysfs-devices-system-cpu | 4 +-
> .../{DMA-API-HOWTO.txt => DMA-API-HOWTO.rst} | 2 +
> Documentation/{DMA-API.txt => DMA-API.rst} | 8 ++-
> .../{DMA-ISA-LPC.txt => DMA-ISA-LPC.rst} | 4 +-
> ...{DMA-attributes.txt => DMA-attributes.rst} | 2 +
> Documentation/{IPMI.txt => IPMI.rst} | 2 +
> .../{IRQ-affinity.txt => IRQ-affinity.rst} | 2 +
> .../{IRQ-domain.txt => IRQ-domain.rst} | 2 +
> Documentation/{IRQ.txt => IRQ.rst} | 2 +
> .../{Intel-IOMMU.txt => Intel-IOMMU.rst} | 2 +
> Documentation/PCI/pci.rst | 8 +--
> Documentation/{SAK.txt => SAK.rst} | 3 +-
> Documentation/{SM501.txt => SM501.rst} | 2 +
> Documentation/admin-guide/hw-vuln/l1tf.rst | 2 +-
> .../admin-guide/kernel-parameters.txt | 4 +-
> .../{atomic_bitops.txt => atomic_bitops.rst} | 3 +-
> Documentation/block/biodoc.txt | 2 +-
> .../{bt8xxgpio.txt => bt8xxgpio.rst} | 3 +-
> Documentation/{btmrvl.txt => btmrvl.rst} | 2 +
> ...-mapping.txt => bus-virt-phys-mapping.rst} | 54 +++++++++---------
> ...g-warn-once.txt => clearing-warn-once.rst} | 2 +
> Documentation/{cpu-load.txt => cpu-load.rst} | 2 +
> .../{cputopology.txt => cputopology.rst} | 2 +
> Documentation/{crc32.txt => crc32.rst} | 2 +
> Documentation/{dcdbas.txt => dcdbas.rst} | 2 +
> ...ging-modules.txt => debugging-modules.rst} | 2 +
> ...hci1394.txt => debugging-via-ohci1394.rst} | 2 +
> Documentation/{dell_rbu.txt => dell_rbu.rst} | 3 +-
> Documentation/device-mapper/statistics.rst | 4 +-
> .../devicetree/bindings/phy/phy-bindings.txt | 2 +-
Acked-by: Rob Herring <robh@kernel.org>
> Documentation/{digsig.txt => digsig.rst} | 2 +
> Documentation/driver-api/usb/dma.rst | 6 +-
> Documentation/driver-model/device.rst | 2 +-
> Documentation/{efi-stub.txt => efi-stub.rst} | 2 +
> Documentation/{eisa.txt => eisa.rst} | 2 +
> Documentation/fb/vesafb.rst | 2 +-
> Documentation/filesystems/sysfs.txt | 2 +-
> ...ex-requeue-pi.txt => futex-requeue-pi.rst} | 2 +
> .../{gcc-plugins.txt => gcc-plugins.rst} | 2 +
> Documentation/gpu/drm-mm.rst | 2 +-
> Documentation/{highuid.txt => highuid.rst} | 4 +-
> .../{hw_random.txt => hw_random.rst} | 2 +
> .../{hwspinlock.txt => hwspinlock.rst} | 2 +
> Documentation/ia64/irq-redir.rst | 2 +-
> .../{intel_txt.txt => intel_txt.rst} | 2 +
> .../{io-mapping.txt => io-mapping.rst} | 2 +
> .../{io_ordering.txt => io_ordering.rst} | 2 +
> Documentation/{iostats.txt => iostats.rst} | 2 +
> ...flags-tracing.txt => irqflags-tracing.rst} | 3 +-
> Documentation/{isa.txt => isa.rst} | 2 +
> Documentation/{isapnp.txt => isapnp.rst} | 2 +
> ...hreads.txt => kernel-per-CPU-kthreads.rst} | 4 +-
> Documentation/{kobject.txt => kobject.rst} | 6 +-
> Documentation/{kprobes.txt => kprobes.rst} | 3 +-
> Documentation/{kref.txt => kref.rst} | 2 +
> Documentation/laptops/thinkpad-acpi.rst | 6 +-
> Documentation/{ldm.txt => ldm.rst} | 5 +-
> Documentation/locking/rt-mutex.rst | 2 +-
> ...kup-watchdogs.txt => lockup-watchdogs.rst} | 2 +
> Documentation/{lsm.txt => lsm.rst} | 2 +
> Documentation/{lzo.txt => lzo.rst} | 2 +
> Documentation/{mailbox.txt => mailbox.rst} | 2 +
> Documentation/memory-barriers.txt | 6 +-
> ...hameleon-bus.txt => men-chameleon-bus.rst} | 2 +
> Documentation/networking/scaling.rst | 4 +-
> .../{nommu-mmap.txt => nommu-mmap.rst} | 2 +
> Documentation/{ntb.txt => ntb.rst} | 2 +
> Documentation/{numastat.txt => numastat.rst} | 3 +-
> Documentation/{padata.txt => padata.rst} | 2 +
> ...port-lowlevel.txt => parport-lowlevel.rst} | 2 +
> ...-semaphore.txt => percpu-rw-semaphore.rst} | 2 +
> Documentation/{phy.txt => phy.rst} | 2 +
> Documentation/{pi-futex.txt => pi-futex.rst} | 2 +
> Documentation/{pnp.txt => pnp.rst} | 13 +++--
> ...reempt-locking.txt => preempt-locking.rst} | 4 +-
> Documentation/{pwm.txt => pwm.rst} | 2 +
> Documentation/{rbtree.txt => rbtree.rst} | 54 +++++++++---------
> .../{remoteproc.txt => remoteproc.rst} | 4 +-
> Documentation/{rfkill.txt => rfkill.rst} | 2 +
> ...ust-futex-ABI.txt => robust-futex-ABI.rst} | 2 +
> ...{robust-futexes.txt => robust-futexes.rst} | 2 +
> Documentation/{rpmsg.txt => rpmsg.rst} | 2 +
> Documentation/{rtc.txt => rtc.rst} | 8 ++-
> Documentation/s390/vfio-ccw.rst | 6 +-
> Documentation/{sgi-ioc4.txt => sgi-ioc4.rst} | 2 +
> Documentation/{siphash.txt => siphash.rst} | 2 +
> .../{smsc_ece1099.txt => smsc_ece1099.rst} | 2 +
> .../{speculation.txt => speculation.rst} | 2 +
> .../{static-keys.txt => static-keys.rst} | 2 +
> Documentation/{svga.txt => svga.rst} | 2 +
> .../{switchtec.txt => switchtec.rst} | 4 +-
> .../{sync_file.txt => sync_file.rst} | 2 +
> Documentation/sysctl/kernel.txt | 4 +-
> Documentation/sysctl/vm.txt | 2 +-
> Documentation/{tee.txt => tee.rst} | 2 +
> .../{this_cpu_ops.txt => this_cpu_ops.rst} | 2 +
> Documentation/trace/kprobetrace.rst | 2 +-
> .../translations/ko_KR/memory-barriers.txt | 6 +-
> Documentation/translations/zh_CN/IRQ.txt | 4 +-
> .../translations/zh_CN/filesystems/sysfs.txt | 2 +-
> .../translations/zh_CN/io_ordering.txt | 4 +-
> ...access.txt => unaligned-memory-access.rst} | 2 +
> ...ed-device.txt => vfio-mediated-device.rst} | 4 +-
> Documentation/{vfio.txt => vfio.rst} | 2 +
> .../{video-output.txt => video-output.rst} | 3 +-
> Documentation/watchdog/hpwdt.rst | 2 +-
> Documentation/x86/topology.rst | 2 +-
> Documentation/{xillybus.txt => xillybus.rst} | 2 +
> Documentation/{xz.txt => xz.rst} | 2 +
> Documentation/{zorro.txt => zorro.rst} | 7 ++-
> MAINTAINERS | 56 +++++++++----------
> arch/Kconfig | 4 +-
> arch/arm/Kconfig | 2 +-
> arch/ia64/hp/common/sba_iommu.c | 12 ++--
> arch/ia64/sn/pci/pci_dma.c | 4 +-
> arch/parisc/Kconfig | 2 +-
> arch/parisc/kernel/pci-dma.c | 2 +-
> arch/sh/Kconfig | 2 +-
> arch/sparc/Kconfig | 2 +-
> arch/unicore32/include/asm/io.h | 2 +-
> arch/x86/Kconfig | 4 +-
> arch/x86/include/asm/dma-mapping.h | 4 +-
> arch/x86/kernel/amd_gart_64.c | 2 +-
> block/partitions/Kconfig | 2 +-
> drivers/base/core.c | 2 +-
> drivers/char/Kconfig | 4 +-
> drivers/char/hw_random/core.c | 2 +-
> drivers/char/ipmi/Kconfig | 2 +-
> drivers/char/ipmi/ipmi_si_hotmod.c | 2 +-
> drivers/char/ipmi/ipmi_si_intf.c | 2 +-
> drivers/dma-buf/Kconfig | 2 +-
> drivers/gpio/Kconfig | 2 +-
> drivers/parisc/sba_iommu.c | 16 +++---
> drivers/pci/switch/Kconfig | 2 +-
> drivers/platform/x86/Kconfig | 4 +-
> drivers/platform/x86/dcdbas.c | 2 +-
> drivers/platform/x86/dell_rbu.c | 2 +-
> drivers/pnp/isapnp/Kconfig | 2 +-
> drivers/vfio/Kconfig | 2 +-
> drivers/vfio/mdev/Kconfig | 2 +-
> include/asm-generic/bitops/atomic.h | 2 +-
> include/linux/dma-mapping.h | 2 +-
> include/linux/hw_random.h | 2 +-
> include/linux/io-mapping.h | 2 +-
> include/linux/jump_label.h | 2 +-
> include/linux/kobject.h | 2 +-
> include/linux/kobject_ns.h | 2 +-
> include/linux/rbtree.h | 2 +-
> include/linux/rbtree_augmented.h | 2 +-
> include/media/videobuf-dma-sg.h | 2 +-
> init/Kconfig | 2 +-
> kernel/dma/debug.c | 2 +-
> kernel/padata.c | 2 +-
> lib/Kconfig | 2 +-
> lib/Kconfig.debug | 2 +-
> lib/crc32.c | 2 +-
> lib/kobject.c | 4 +-
> lib/lzo/lzo1x_decompress_safe.c | 2 +-
> lib/xz/Kconfig | 2 +-
> mm/Kconfig | 2 +-
> mm/nommu.c | 2 +-
> samples/kprobes/kprobe_example.c | 2 +-
> samples/kprobes/kretprobe_example.c | 2 +-
> scripts/gcc-plugins/Kconfig | 2 +-
> security/Kconfig | 2 +-
> tools/include/linux/rbtree.h | 2 +-
> tools/include/linux/rbtree_augmented.h | 2 +-
> 173 files changed, 397 insertions(+), 242 deletions(-)
> rename Documentation/{DMA-API-HOWTO.txt => DMA-API-HOWTO.rst} (99%)
> rename Documentation/{DMA-API.txt => DMA-API.rst} (99%)
> rename Documentation/{DMA-ISA-LPC.txt => DMA-ISA-LPC.rst} (98%)
> rename Documentation/{DMA-attributes.txt => DMA-attributes.rst} (99%)
> rename Documentation/{IPMI.txt => IPMI.rst} (99%)
> rename Documentation/{IRQ-affinity.txt => IRQ-affinity.rst} (99%)
> rename Documentation/{IRQ-domain.txt => IRQ-domain.rst} (99%)
> rename Documentation/{IRQ.txt => IRQ.rst} (99%)
> rename Documentation/{Intel-IOMMU.txt => Intel-IOMMU.rst} (99%)
> rename Documentation/{SAK.txt => SAK.rst} (99%)
> rename Documentation/{SM501.txt => SM501.rst} (99%)
> rename Documentation/{atomic_bitops.txt => atomic_bitops.rst} (99%)
> rename Documentation/{bt8xxgpio.txt => bt8xxgpio.rst} (99%)
> rename Documentation/{btmrvl.txt => btmrvl.rst} (99%)
> rename Documentation/{bus-virt-phys-mapping.txt => bus-virt-phys-mapping.rst} (93%)
> rename Documentation/{clearing-warn-once.txt => clearing-warn-once.rst} (96%)
> rename Documentation/{cpu-load.txt => cpu-load.rst} (99%)
> rename Documentation/{cputopology.txt => cputopology.rst} (99%)
> rename Documentation/{crc32.txt => crc32.rst} (99%)
> rename Documentation/{dcdbas.txt => dcdbas.rst} (99%)
> rename Documentation/{debugging-modules.txt => debugging-modules.rst} (98%)
> rename Documentation/{debugging-via-ohci1394.txt => debugging-via-ohci1394.rst} (99%)
> rename Documentation/{dell_rbu.txt => dell_rbu.rst} (99%)
> rename Documentation/{digsig.txt => digsig.rst} (99%)
> rename Documentation/{efi-stub.txt => efi-stub.rst} (99%)
> rename Documentation/{eisa.txt => eisa.rst} (99%)
> rename Documentation/{futex-requeue-pi.txt => futex-requeue-pi.rst} (99%)
> rename Documentation/{gcc-plugins.txt => gcc-plugins.rst} (99%)
> rename Documentation/{highuid.txt => highuid.rst} (99%)
> rename Documentation/{hw_random.txt => hw_random.rst} (99%)
> rename Documentation/{hwspinlock.txt => hwspinlock.rst} (99%)
> rename Documentation/{intel_txt.txt => intel_txt.rst} (99%)
> rename Documentation/{io-mapping.txt => io-mapping.rst} (99%)
> rename Documentation/{io_ordering.txt => io_ordering.rst} (99%)
> rename Documentation/{iostats.txt => iostats.rst} (99%)
> rename Documentation/{irqflags-tracing.txt => irqflags-tracing.rst} (99%)
> rename Documentation/{isa.txt => isa.rst} (99%)
> rename Documentation/{isapnp.txt => isapnp.rst} (98%)
> rename Documentation/{kernel-per-CPU-kthreads.txt => kernel-per-CPU-kthreads.rst} (99%)
> rename Documentation/{kobject.txt => kobject.rst} (99%)
> rename Documentation/{kprobes.txt => kprobes.rst} (99%)
> rename Documentation/{kref.txt => kref.rst} (99%)
> rename Documentation/{ldm.txt => ldm.rst} (98%)
> rename Documentation/{lockup-watchdogs.txt => lockup-watchdogs.rst} (99%)
> rename Documentation/{lsm.txt => lsm.rst} (99%)
> rename Documentation/{lzo.txt => lzo.rst} (99%)
> rename Documentation/{mailbox.txt => mailbox.rst} (99%)
> rename Documentation/{men-chameleon-bus.txt => men-chameleon-bus.rst} (99%)
> rename Documentation/{nommu-mmap.txt => nommu-mmap.rst} (99%)
> rename Documentation/{ntb.txt => ntb.rst} (99%)
> rename Documentation/{numastat.txt => numastat.rst} (99%)
> rename Documentation/{padata.txt => padata.rst} (99%)
> rename Documentation/{parport-lowlevel.txt => parport-lowlevel.rst} (99%)
> rename Documentation/{percpu-rw-semaphore.txt => percpu-rw-semaphore.rst} (99%)
> rename Documentation/{phy.txt => phy.rst} (99%)
> rename Documentation/{pi-futex.txt => pi-futex.rst} (99%)
> rename Documentation/{pnp.txt => pnp.rst} (98%)
> rename Documentation/{preempt-locking.txt => preempt-locking.rst} (99%)
> rename Documentation/{pwm.txt => pwm.rst} (99%)
> rename Documentation/{rbtree.txt => rbtree.rst} (94%)
> rename Documentation/{remoteproc.txt => remoteproc.rst} (99%)
> rename Documentation/{rfkill.txt => rfkill.rst} (99%)
> rename Documentation/{robust-futex-ABI.txt => robust-futex-ABI.rst} (99%)
> rename Documentation/{robust-futexes.txt => robust-futexes.rst} (99%)
> rename Documentation/{rpmsg.txt => rpmsg.rst} (99%)
> rename Documentation/{rtc.txt => rtc.rst} (99%)
> rename Documentation/{sgi-ioc4.txt => sgi-ioc4.rst} (99%)
> rename Documentation/{siphash.txt => siphash.rst} (99%)
> rename Documentation/{smsc_ece1099.txt => smsc_ece1099.rst} (99%)
> rename Documentation/{speculation.txt => speculation.rst} (99%)
> rename Documentation/{static-keys.txt => static-keys.rst} (99%)
> rename Documentation/{svga.txt => svga.rst} (99%)
> rename Documentation/{switchtec.txt => switchtec.rst} (98%)
> rename Documentation/{sync_file.txt => sync_file.rst} (99%)
> rename Documentation/{tee.txt => tee.rst} (99%)
> rename Documentation/{this_cpu_ops.txt => this_cpu_ops.rst} (99%)
> rename Documentation/{unaligned-memory-access.txt => unaligned-memory-access.rst} (99%)
> rename Documentation/{vfio-mediated-device.txt => vfio-mediated-device.rst} (99%)
> rename Documentation/{vfio.txt => vfio.rst} (99%)
> rename Documentation/{video-output.txt => video-output.rst} (99%)
> rename Documentation/{xillybus.txt => xillybus.rst} (99%)
> rename Documentation/{xz.txt => xz.rst} (99%)
> rename Documentation/{zorro.txt => zorro.rst} (99%)
^ permalink raw reply
* Re: [PATCH iproute2-next 2/3] tc: add mpls actions
From: Stephen Hemminger @ 2019-07-09 17:00 UTC (permalink / raw)
To: John Hurley
Cc: netdev, davem, jiri, xiyou.wangcong, dsahern,
willemdebruijn.kernel, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1562687972-23549-3-git-send-email-john.hurley@netronome.com>
On Tue, 9 Jul 2019 16:59:31 +0100
John Hurley <john.hurley@netronome.com> wrote:
> if (!tb[TCA_MPLS_PARMS]) {
> + print_string(PRINT_FP, NULL, "%s", "[NULL mpls parameters]");
This is an error message please just use fprintf(stderr instead
^ permalink raw reply
* Cloud Service providers Contact List
From: scarlett.hickman @ 2019-07-09 16:42 UTC (permalink / raw)
To: netdev
Hi,
Would you be interested in Cloud Service providers Contact List? We are
happy to provide the database across globe, specifically North America,
EMEA, APAC and Latin America.
We also have other users like: Microsoft Azure, Google Cloud, Alibaba
Cloud, IBM, Oracle, Virtustream CenturyLink, Rackspace, Joyent, Skytap,
Interoute, Fujitsu,NTT Communications and many more.
All Fields: Names, Title, Email, Phone, Company Name, Company URL, Company
physical address, Industry, website, Company Size (Revenue and Employee)
Please let me know your targeted criteria with geography to provide you
with detailed information for your review Await your response.
Regards
Scarlett Hickman
Marketing Manager
To opt-out replay in subject line.
^ permalink raw reply
* [PATCH net-next iproute2] devlink: Show devlink port number
From: Parav Pandit @ 2019-07-09 16:33 UTC (permalink / raw)
To: netdev; +Cc: stephen, jiri, dsahern, Parav Pandit
Show devlink port number whenever kernel reports that attribute.
An example output for a physical port.
$ devlink port show
pci/0000:06:00.1/65535: type eth netdev eth1_p1 flavour physical port 1
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
---
devlink/devlink.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 559f624e..dba74e04 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -2806,6 +2806,11 @@ static void pr_out_port(struct dl *dl, struct nlattr **tb)
pr_out_str(dl, "flavour", port_flavour_name(port_flavour));
}
+ if (tb[DEVLINK_ATTR_PORT_NUMBER]) {
+ uint32_t port_number =
+ mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_NUMBER]);
+ pr_out_uint(dl, "port", port_number);
+ }
if (tb[DEVLINK_ATTR_PORT_SPLIT_GROUP])
pr_out_uint(dl, "split_group",
mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_SPLIT_GROUP]));
--
2.19.2
^ permalink raw reply related
* Re: [PATCH bpf] bpf: net: Set sk_bpf_storage back to NULL for cloned sk
From: Stanislav Fomichev @ 2019-07-09 16:33 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: bpf, netdev, Alexei Starovoitov, Daniel Borkmann, David Miller,
kernel-team
In-Reply-To: <20190611214557.2700117-1-kafai@fb.com>
On 06/11, Martin KaFai Lau wrote:
> The cloned sk should not carry its parent-listener's sk_bpf_storage.
> This patch fixes it by setting it back to NULL.
Have you thought about some kind of inheritance for listener sockets'
storage? Suppose I have a situation where I write something
to listener's sk storage (directly or via recently added sockopts hooks)
and I want to inherit that state for a freshly established connection.
I was looking into adding possibility to call bpf_get_listener_sock form
BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB callback to manually
copy some data form the listener socket, but I don't think
at this point there is any association between newly established
socket and the listener.
Thoughts/ideas?
(Btw, sorry for digging up this old mail, but it feels relevant).
> Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
> net/core/sock.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 2b3701958486..d90fd04622e5 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1850,6 +1850,9 @@ struct sock *sk_clone_lock(const struct sock *sk, const gfp_t priority)
> goto out;
> }
> RCU_INIT_POINTER(newsk->sk_reuseport_cb, NULL);
> +#ifdef CONFIG_BPF_SYSCALL
> + RCU_INIT_POINTER(newsk->sk_bpf_storage, NULL);
> +#endif
>
> newsk->sk_err = 0;
> newsk->sk_err_soft = 0;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Add page_pool_destroy() during RX ring cleanup.
From: Andy Gospodarek @ 2019-07-09 16:31 UTC (permalink / raw)
To: Ilias Apalodimas; +Cc: Andy Gospodarek, Michael Chan, davem, netdev
In-Reply-To: <20190709152057.GA4452@apalos>
On Tue, Jul 09, 2019 at 06:20:57PM +0300, Ilias Apalodimas wrote:
> Hi,
>
> > > Add page_pool_destroy() in bnxt_free_rx_rings() during normal RX ring
> > > cleanup, as Ilias has informed us that the following commit has been
> > > merged:
> > >
> > > 1da4bbeffe41 ("net: core: page_pool: add user refcnt and reintroduce page_pool_destroy")
> > >
> > > The special error handling code to call page_pool_free() can now be
> > > removed. bnxt_free_rx_rings() will always be called during normal
> > > shutdown or any error paths.
> > >
> > > Fixes: 322b87ca55f2 ("bnxt_en: add page_pool support")
> > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > Cc: Andy Gospodarek <gospo@broadcom.com>
> > > Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> > > ---
> > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 ++------
> > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > index e9d3bd8..2b5b0ab 100644
> > > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > > @@ -2500,6 +2500,7 @@ static void bnxt_free_rx_rings(struct bnxt *bp)
> > > if (xdp_rxq_info_is_reg(&rxr->xdp_rxq))
> > > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > >
> > > + page_pool_destroy(rxr->page_pool);
> > > rxr->page_pool = NULL;
> > >
> > > kfree(rxr->rx_tpa);
> > > @@ -2560,19 +2561,14 @@ static int bnxt_alloc_rx_rings(struct bnxt *bp)
> > > return rc;
> > >
> > > rc = xdp_rxq_info_reg(&rxr->xdp_rxq, bp->dev, i);
> > > - if (rc < 0) {
> > > - page_pool_free(rxr->page_pool);
> > > - rxr->page_pool = NULL;
> > > + if (rc < 0)
> > > return rc;
> > > - }
> > >
> > > rc = xdp_rxq_info_reg_mem_model(&rxr->xdp_rxq,
> > > MEM_TYPE_PAGE_POOL,
> > > rxr->page_pool);
> > > if (rc) {
> > > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > > - page_pool_free(rxr->page_pool);
> > > - rxr->page_pool = NULL;
> >
> > Rather than deleting these lines it would also be acceptable to do:
> >
> > if (rc) {
> > xdp_rxq_info_unreg(&rxr->xdp_rxq);
> > - page_pool_free(rxr->page_pool);
> > + page_pool_destroy(rxr->page_pool);
> > rxr->page_pool = NULL;
> > return rc;
> > }
> >
> > but anytime there is a failure to bnxt_alloc_rx_rings the driver will
> > immediately follow it up with a call to bnxt_free_rx_rings, so
> > page_pool_destroy will be called.
> >
> > Thanks for pushing this out so quickly!
> >
>
> I also can't find page_pool_release_page() or page_pool_put_page() called when
> destroying the pool. Can you try to insmod -> do some traffic -> rmmod ?
> If there's stale buffers that haven't been unmapped properly you'll get a
> WARN_ON for them.
I did that test a few times with a few different bpf progs but I do not
see any WARN messages. Of course this does not mean that the code we
have is 100% correct.
Presumably you are talking about one of these messages, right?
215 /* The distance should not be able to become negative */
216 WARN(inflight < 0, "Negative(%d) inflight packet-pages", inflight);
or
356 /* Drivers should fix this, but only problematic when DMA is used */
357 WARN(1, "Still in-flight pages:%d hold:%u released:%u",
358 distance, hold_cnt, release_cnt);
> This part was added later on in the API when Jesper fixed in-flight packet
> handling
^ permalink raw reply
* Re: [PATCH v2 2/2] rtw88: pci: Use DMA sync instead of remapping in RX ISR
From: Christoph Hellwig @ 2019-07-09 16:15 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, Larry Finger,
David Laight, linux-wireless, netdev, linux-kernel, linux,
Daniel Drake
In-Reply-To: <20190709102059.7036-2-jian-hong@endlessm.com>
On Tue, Jul 09, 2019 at 06:21:01PM +0800, Jian-Hong Pan wrote:
> Since each skb in RX ring is reused instead of new allocation, we can
> treat the DMA in a more efficient way by DMA synchronization.
>
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> ---
> drivers/net/wireless/realtek/rtw88/pci.c | 35 ++++++++++++++++++++++--
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
> index e9fe3ad896c8..28ca76f71dfe 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -206,6 +206,35 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb,
> return 0;
> }
>
> +static int rtw_pci_sync_rx_desc_cpu(struct rtw_dev *rtwdev, dma_addr_t dma)
> +{
> + struct device *dev = rtwdev->dev;
> + int buf_sz = RTK_PCI_RX_BUF_SIZE;
> +
> + dma_sync_single_for_cpu(dev, dma, buf_sz, PCI_DMA_FROMDEVICE);
> +
> + return 0;
> +}
No need to return a value from this helper. In fact I'm not even sure
you need the helper at all. Also please use the DMA_FROM_DEVICE
constant instead of the deprecated PCI variant.
> +static int rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
> + struct rtw_pci_rx_ring *rx_ring,
> + u32 idx, u32 desc_sz)
> +{
> + struct device *dev = rtwdev->dev;
> + struct rtw_pci_rx_buffer_desc *buf_desc;
> + int buf_sz = RTK_PCI_RX_BUF_SIZE;
> +
> + dma_sync_single_for_device(dev, dma, buf_sz, PCI_DMA_FROMDEVICE);
> +
> + buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
> + idx * desc_sz);
> + memset(buf_desc, 0, sizeof(*buf_desc));
> + buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
> + buf_desc->dma = cpu_to_le32(dma);
> +
> + return 0;
> +}
Same comment on the PCI constant and the return value here.
^ permalink raw reply
* Re: [PATCH] crypto: user - make NETLINK_CRYPTO work inside netns
From: Herbert Xu @ 2019-07-09 16:14 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: linux-crypto, netdev, David S . Miller, Stephan Mueller,
Steffen Klassert, Don Zickus
In-Reply-To: <CAFqZXNs2XysEWVzmfXSczH-+oX5iwwRC3+9fL3tWYEfDRbqLig@mail.gmail.com>
On Tue, Jul 09, 2019 at 05:28:35PM +0200, Ondrej Mosnacek wrote:
>
> I admit I'm not an expert on Linux namespaces, but aren't you
> confusing network and user namespaces? Unless I'm mistaken, these
> changes only affect _network_ namespaces (which only isolate the
> network stuff itself) and the semantics of the netlink_capable(skb,
> CAP_NET_ADMIN) calls remain unchanged - they check if the opener of
> the socket has the CAP_NET_ADMIN capability within the global _user_
> namespace.
Good point. I think your patch should be OK then.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3 bpf-next 0/4] selftests/bpf: fix compiling loop{1,2,3}.c on s390
From: Stanislav Fomichev @ 2019-07-09 16:07 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, netdev, ys114321, davem, ast, daniel
In-Reply-To: <20190709151809.37539-1-iii@linux.ibm.com>
On 07/09, Ilya Leoshkevich wrote:
> Use PT_REGS_RC(ctx) instead of ctx->rax, which is not present on s390.
>
> This patch series consists of three preparatory commits, which make it
> possible to use PT_REGS_RC in BPF selftests, followed by the actual fix.
>
> Since the last time, I've tested it with x86_64-linux-gnu-,
> aarch64-linux-gnu-, arm-linux-gnueabihf-, mips64el-linux-gnuabi64-,
> powerpc64le-linux-gnu-, s390x-linux-gnu- and sparc64-linux-gnu-
> compilers, and found that I also need to add arm64 support.
>
> Like s390, arm64 exports user_pt_regs instead of struct pt_regs to
> userspace.
>
> I've also made fixes for a few unrelated build problems, which I will
> post separately.
>
> v1->v2: Split into multiple patches.
> v2->v3: Added arm64 support.
For the whole series:
Reviewed-by: Stanislav Fomichev <sdf@google.com>
This should probably go to bpf, not bpf-next since it fixes the
existing compilation problem.
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>
>
^ permalink raw reply
* [PATCH iproute2-next 3/3] man: update man pages for TC MPLS actions
From: John Hurley @ 2019-07-09 15:59 UTC (permalink / raw)
To: netdev
Cc: davem, jiri, xiyou.wangcong, dsahern, willemdebruijn.kernel,
simon.horman, jakub.kicinski, oss-drivers, John Hurley
In-Reply-To: <1562687972-23549-1-git-send-email-john.hurley@netronome.com>
Add a man page describing the newly added TC mpls manipulation actions.
Signed-off-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
man/man8/tc-mpls.8 | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 156 insertions(+)
create mode 100644 man/man8/tc-mpls.8
diff --git a/man/man8/tc-mpls.8 b/man/man8/tc-mpls.8
new file mode 100644
index 0000000..84ef2ef
--- /dev/null
+++ b/man/man8/tc-mpls.8
@@ -0,0 +1,156 @@
+.TH "MPLS manipulation action in tc" 8 "22 May 2019" "iproute2" "Linux"
+
+.SH NAME
+mpls - mpls manipulation module
+.SH SYNOPSIS
+.in +8
+.ti -8
+.BR tc " ... " "action mpls" " { "
+.IR POP " | " PUSH " | " MODIFY " | "
+.BR dec_ttl " } [ "
+.IR CONTROL " ]"
+
+.ti -8
+.IR POP " := "
+.BR pop " " protocol
+.IR MPLS_PROTO
+
+.ti -8
+.IR PUSH " := "
+.BR push " [ " protocol
+.IR MPLS_PROTO " ]"
+.RB " [ " tc
+.IR MPLS_TC " ] "
+.RB " [ " ttl
+.IR MPLS_TTL " ] "
+.RB " [ " bos
+.IR MPLS_BOS " ] "
+.BI label " MPLS_LABEL"
+
+.ti -8
+.IR MODIFY " := "
+.BR modify " [ " label
+.IR MPLS_LABEL " ]"
+.RB " [ " tc
+.IR MPLS_TC " ] "
+.RB " [ " ttl
+.IR MPLS_TTL " ] "
+
+.ti -8
+.IR CONTROL " := { "
+.BR reclassify " | " pipe " | " drop " | " continue " | " pass " | " goto " " chain " " CHAIN_INDEX " }"
+.SH DESCRIPTION
+The
+.B mpls
+action performs mpls encapsulation or decapsulation on a packet, reflected by the
+operation modes
+.IR POP ", " PUSH ", " MODIFY " and " DEC_TTL .
+The
+.I POP
+mode requires the ethertype of the header that follows the MPLS header (e.g.
+IPv4 or another MPLS). It will remove the outer MPLS header and replace the
+ethertype in the MAC header with that passed. The
+.IR PUSH " and " MODIFY
+modes update the current MPLS header information or add a new header.
+.IR PUSH
+requires at least an
+.IR MPLS_LABEL ". "
+.I DEC_TTL
+requires no arguments and simply subtracts 1 from the MPLS header TTL field.
+
+.SH OPTIONS
+.TP
+.B pop
+Decapsulation mode. Requires the protocol of the next header.
+.TP
+.B push
+Encapsulation mode. Requires at least the
+.B label
+option.
+.TP
+.B modify
+Replace mode. Existing MPLS tag is replaced.
+.BR label ", "
+.BR tc ", "
+and
+.B ttl
+are all optional.
+.TP
+.B dec_ttl
+Decrement the TTL field on the outer most MPLS header.
+.TP
+.BI label " MPLS_LABEL"
+Specify the MPLS LABEL for the outer MPLS header.
+.I MPLS_LABEL
+is an unsigned 20bit integer, the format is detected automatically (e.g. prefix
+with
+.RB ' 0x '
+for hexadecimal interpretation, etc.).
+.TP
+.BI protocol " MPLS_PROTO"
+Choose the protocol to use. For push actions this must be
+.BR mpls_uc " or " mpls_mc " (" mpls_uc
+is the default). For pop actions it should be the protocol of the next header.
+This option cannot be used with modify.
+.TP
+.BI tc " MPLS_TC"
+Choose the TC value for the outer MPLS header. Decimal number in range of 0-7.
+Defaults to 0.
+.TP
+.BI ttl " MPLS_TTL"
+Choose the TTL value for the outer MPLS header. Number in range of 0-255. A
+non-zero default value will be selected if this is not explicitly set.
+.TP
+.BI bos " MPLS_BOS"
+Manually configure the bottom of stack bit for an MPLS header push. The default
+is for TC to automatically set (or unset) the bit based on the next header of
+the packet.
+.TP
+.I CONTROL
+How to continue after executing this action.
+.RS
+.TP
+.B reclassify
+Restarts classification by jumping back to the first filter attached to this
+action's parent.
+.TP
+.B pipe
+Continue with the next action, this is the default.
+.TP
+.B drop
+Packet will be dropped without running further actions.
+.TP
+.B continue
+Continue classification with next filter in line.
+.TP
+.B pass
+Return to calling qdisc for packet processing. This ends the classification
+process.
+.RE
+.SH EXAMPLES
+The following example encapsulates incoming IP packets on eth0 into MPLS with
+a label 123 and sends them out eth1:
+
+.RS
+.EX
+#tc qdisc add dev eth0 handle ffff: ingress
+#tc filter add dev eth0 protocol ip parent ffff: flower \\
+ action mpls push protocol mpls_uc label 123 \\
+ action mirred egress redirect dev eth1
+.EE
+.RE
+
+In this example, incoming MPLS unicast packets on eth0 are decapsulated and to
+ip packets and output to eth1:
+
+.RS
+.EX
+#tc qdisc add dev eth0 handle ffff: ingress
+#tc filter add dev eth0 protocol mpls_uc parent ffff: flower \\
+ action mpls pop protocol ipv4 \\
+ action mirred egress redirect dev eth0
+.EE
+.RE
+
+.SH SEE ALSO
+.BR tc (8)
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2-next 2/3] tc: add mpls actions
From: John Hurley @ 2019-07-09 15:59 UTC (permalink / raw)
To: netdev
Cc: davem, jiri, xiyou.wangcong, dsahern, willemdebruijn.kernel,
simon.horman, jakub.kicinski, oss-drivers, John Hurley
In-Reply-To: <1562687972-23549-1-git-send-email-john.hurley@netronome.com>
Create a new action type for TC that allows the pushing, popping, and
modifying of MPLS headers.
Signed-off-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
tc/Makefile | 1 +
tc/m_mpls.c | 275 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 276 insertions(+)
create mode 100644 tc/m_mpls.c
diff --git a/tc/Makefile b/tc/Makefile
index 60abdde..09ff369 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -39,6 +39,7 @@ TCMODULES += q_drr.o
TCMODULES += q_qfq.o
TCMODULES += m_gact.o
TCMODULES += m_mirred.o
+TCMODULES += m_mpls.o
TCMODULES += m_nat.o
TCMODULES += m_pedit.o
TCMODULES += m_ife.o
diff --git a/tc/m_mpls.c b/tc/m_mpls.c
new file mode 100644
index 0000000..d2700ec
--- /dev/null
+++ b/tc/m_mpls.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/* Copyright (C) 2019 Netronome Systems, Inc. */
+
+#include <linux/if_ether.h>
+#include <linux/tc_act/tc_mpls.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include "utils.h"
+#include "rt_names.h"
+#include "tc_util.h"
+
+static const char * const action_names[] = {
+ [TCA_MPLS_ACT_POP] = "pop",
+ [TCA_MPLS_ACT_PUSH] = "push",
+ [TCA_MPLS_ACT_MODIFY] = "modify",
+ [TCA_MPLS_ACT_DEC_TTL] = "dec_ttl",
+};
+
+static void explain(void)
+{
+ fprintf(stderr,
+ "Usage: mpls pop [ protocol MPLS_PROTO ]\n"
+ " mpls push [ protocol MPLS_PROTO ] [ label MPLS_LABEL ] [ tc MPLS_TC ] [ ttl MPLS_TTL ] [ bos MPLS_BOS ] [CONTROL]\n"
+ " mpls modify [ label MPLS_LABEL ] [ tc MPLS_TC ] [ ttl MPLS_TTL ] [CONTROL]\n"
+ " for pop MPLS_PROTO is next header of packet - e.g. ip or mpls_uc\n"
+ " for push MPLS_PROTO is one of mpls_uc or mpls_mc\n"
+ " with default: mpls_uc\n"
+ " CONTROL := reclassify | pipe | drop | continue | pass |\n"
+ " goto chain <CHAIN_INDEX>\n");
+}
+
+static void usage(void)
+{
+ explain();
+ exit(-1);
+}
+
+static bool can_modify_mpls_fields(unsigned int action)
+{
+ return action == TCA_MPLS_ACT_PUSH || action == TCA_MPLS_ACT_MODIFY;
+}
+
+static bool can_modify_ethtype(unsigned int action)
+{
+ return action == TCA_MPLS_ACT_PUSH || action == TCA_MPLS_ACT_POP;
+}
+
+static bool is_valid_label(__u32 label)
+{
+ return label <= 0xfffff;
+}
+
+static bool check_double_action(unsigned int action, const char *arg)
+{
+ if (!action)
+ return false;
+
+ fprintf(stderr,
+ "Error: got \"%s\" but action already set to \"%s\"\n",
+ arg, action_names[action]);
+ explain();
+ return true;
+}
+
+static int parse_mpls(struct action_util *a, int *argc_p, char ***argv_p,
+ int tca_id, struct nlmsghdr *n)
+{
+ struct tc_mpls parm = {};
+ __u32 label = 0xffffffff;
+ unsigned int action = 0;
+ char **argv = *argv_p;
+ struct rtattr *tail;
+ int argc = *argc_p;
+ __u16 proto = 0;
+ __u8 bos = 0xff;
+ __u8 tc = 0xff;
+ __u8 ttl = 0;
+
+ if (matches(*argv, "mpls") != 0)
+ return -1;
+
+ NEXT_ARG();
+
+ while (argc > 0) {
+ if (matches(*argv, "pop") == 0) {
+ if (check_double_action(action, *argv))
+ return -1;
+ action = TCA_MPLS_ACT_POP;
+ } else if (matches(*argv, "push") == 0) {
+ if (check_double_action(action, *argv))
+ return -1;
+ action = TCA_MPLS_ACT_PUSH;
+ } else if (matches(*argv, "modify") == 0) {
+ if (check_double_action(action, *argv))
+ return -1;
+ action = TCA_MPLS_ACT_MODIFY;
+ } else if (matches(*argv, "dec_ttl") == 0) {
+ if (check_double_action(action, *argv))
+ return -1;
+ action = TCA_MPLS_ACT_DEC_TTL;
+ } else if (matches(*argv, "label") == 0) {
+ if (!can_modify_mpls_fields(action))
+ invarg("only valid for push/modify", *argv);
+ NEXT_ARG();
+ if (get_u32(&label, *argv, 0) || !is_valid_label(label))
+ invarg("label must be <=0xFFFFF", *argv);
+ } else if (matches(*argv, "tc") == 0) {
+ if (!can_modify_mpls_fields(action))
+ invarg("only valid for push/modify", *argv);
+ NEXT_ARG();
+ if (get_u8(&tc, *argv, 0) || (tc & ~0x7))
+ invarg("tc field is 3 bits max", *argv);
+ } else if (matches(*argv, "ttl") == 0) {
+ if (!can_modify_mpls_fields(action))
+ invarg("only valid for push/modify", *argv);
+ NEXT_ARG();
+ if (get_u8(&ttl, *argv, 0) || !ttl)
+ invarg("ttl must be >0 and <=255", *argv);
+ } else if (matches(*argv, "bos") == 0) {
+ if (!can_modify_mpls_fields(action))
+ invarg("only valid for push/modify", *argv);
+ NEXT_ARG();
+ if (get_u8(&bos, *argv, 0) || (bos & ~0x1))
+ invarg("bos must be 0 or 1", *argv);
+ } else if (matches(*argv, "protocol") == 0) {
+ if (!can_modify_ethtype(action))
+ invarg("only valid for push/pop", *argv);
+ NEXT_ARG();
+ if (ll_proto_a2n(&proto, *argv))
+ invarg("protocol is invalid", *argv);
+ } else if (matches(*argv, "help") == 0) {
+ usage();
+ } else {
+ break;
+ }
+
+ NEXT_ARG_FWD();
+ }
+
+ if (!action)
+ incomplete_command();
+
+ parse_action_control_dflt(&argc, &argv, &parm.action,
+ false, TC_ACT_PIPE);
+
+ if (argc) {
+ if (matches(*argv, "index") == 0) {
+ NEXT_ARG();
+ if (get_u32(&parm.index, *argv, 10))
+ invarg("illegal index", *argv);
+ NEXT_ARG_FWD();
+ }
+ }
+
+ if (action == TCA_MPLS_ACT_PUSH && !label)
+ missarg("label");
+
+ if (action == TCA_MPLS_ACT_PUSH && proto &&
+ proto != htons(ETH_P_MPLS_UC) && proto != htons(ETH_P_MPLS_MC)) {
+ fprintf(stderr,
+ "invalid push protocol \"0x%04x\" - use mpls_(uc|mc)\n",
+ ntohs(proto));
+ return -1;
+ }
+
+ if (action == TCA_MPLS_ACT_POP && !proto)
+ missarg("protocol");
+
+ parm.m_action = action;
+ tail = addattr_nest(n, MAX_MSG, tca_id | NLA_F_NESTED);
+ addattr_l(n, MAX_MSG, TCA_MPLS_PARMS, &parm, sizeof(parm));
+ if (label != 0xffffffff)
+ addattr_l(n, MAX_MSG, TCA_MPLS_LABEL, &label, sizeof(label));
+ if (proto)
+ addattr_l(n, MAX_MSG, TCA_MPLS_PROTO, &proto, sizeof(proto));
+ if (tc != 0xff)
+ addattr8(n, MAX_MSG, TCA_MPLS_TC, tc);
+ if (ttl)
+ addattr8(n, MAX_MSG, TCA_MPLS_TTL, ttl);
+ if (bos != 0xff)
+ addattr8(n, MAX_MSG, TCA_MPLS_BOS, bos);
+ addattr_nest_end(n, tail);
+
+ *argc_p = argc;
+ *argv_p = argv;
+ return 0;
+}
+
+static int print_mpls(struct action_util *au, FILE *f, struct rtattr *arg)
+{
+ struct rtattr *tb[TCA_MPLS_MAX + 1];
+ struct tc_mpls *parm;
+ SPRINT_BUF(b1);
+ __u32 val;
+
+ if (!arg)
+ return -1;
+
+ parse_rtattr_nested(tb, TCA_MPLS_MAX, arg);
+
+ if (!tb[TCA_MPLS_PARMS]) {
+ print_string(PRINT_FP, NULL, "%s", "[NULL mpls parameters]");
+ return -1;
+ }
+ parm = RTA_DATA(tb[TCA_MPLS_PARMS]);
+
+ print_string(PRINT_ANY, "kind", "%s ", "mpls");
+ print_string(PRINT_ANY, "mpls_action", " %s",
+ action_names[parm->m_action]);
+
+ switch (parm->m_action) {
+ case TCA_MPLS_ACT_POP:
+ if (tb[TCA_MPLS_PROTO]) {
+ __u16 proto;
+
+ proto = rta_getattr_u16(tb[TCA_MPLS_PROTO]);
+ print_string(PRINT_ANY, "protocol", " protocol %s",
+ ll_proto_n2a(proto, b1, sizeof(b1)));
+ }
+ break;
+ case TCA_MPLS_ACT_PUSH:
+ if (tb[TCA_MPLS_PROTO]) {
+ __u16 proto;
+
+ proto = rta_getattr_u16(tb[TCA_MPLS_PROTO]);
+ print_string(PRINT_ANY, "protocol", " protocol %s",
+ ll_proto_n2a(proto, b1, sizeof(b1)));
+ }
+ /* Fallthrough */
+ case TCA_MPLS_ACT_MODIFY:
+ if (tb[TCA_MPLS_LABEL]) {
+ val = rta_getattr_u32(tb[TCA_MPLS_LABEL]);
+ print_uint(PRINT_ANY, "label", " label %u", val);
+ }
+ if (tb[TCA_MPLS_TC]) {
+ val = rta_getattr_u8(tb[TCA_MPLS_TC]);
+ print_uint(PRINT_ANY, "tc", " tc %u", val);
+ }
+ if (tb[TCA_MPLS_BOS]) {
+ val = rta_getattr_u8(tb[TCA_MPLS_BOS]);
+ print_uint(PRINT_ANY, "bos", " bos %u", val);
+ }
+ if (tb[TCA_MPLS_TTL]) {
+ val = rta_getattr_u8(tb[TCA_MPLS_TTL]);
+ print_uint(PRINT_ANY, "ttl", " ttl %u", val);
+ }
+ break;
+ }
+ print_action_control(f, " ", parm->action, "");
+
+ print_uint(PRINT_ANY, "index", "\n\t index %u", parm->index);
+ print_int(PRINT_ANY, "ref", " ref %d", parm->refcnt);
+ print_int(PRINT_ANY, "bind", " bind %d", parm->bindcnt);
+
+ if (show_stats) {
+ if (tb[TCA_MPLS_TM]) {
+ struct tcf_t *tm = RTA_DATA(tb[TCA_MPLS_TM]);
+
+ print_tm(f, tm);
+ }
+ }
+
+ print_string(PRINT_FP, NULL, "%s", "\n");
+
+ return 0;
+}
+
+struct action_util mpls_action_util = {
+ .id = "mpls",
+ .parse_aopt = parse_mpls,
+ .print_aopt = print_mpls,
+};
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2-next 1/3] lib: add mpls_uc and mpls_mc as link layer protocol names
From: John Hurley @ 2019-07-09 15:59 UTC (permalink / raw)
To: netdev
Cc: davem, jiri, xiyou.wangcong, dsahern, willemdebruijn.kernel,
simon.horman, jakub.kicinski, oss-drivers, John Hurley
In-Reply-To: <1562687972-23549-1-git-send-email-john.hurley@netronome.com>
Update the llproto_names array to allow users to reference the mpls
protocol ids with the names 'mpls_uc' for unicast MPLS and 'mpls_mc' for
multicast.
Signed-off-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
lib/ll_proto.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/ll_proto.c b/lib/ll_proto.c
index 78c3961..2a0c1cb 100644
--- a/lib/ll_proto.c
+++ b/lib/ll_proto.c
@@ -78,6 +78,8 @@ __PF(TIPC,tipc)
__PF(AOE,aoe)
__PF(8021Q,802.1Q)
__PF(8021AD,802.1ad)
+__PF(MPLS_UC,mpls_uc)
+__PF(MPLS_MC,mpls_mc)
{ 0x8100, "802.1Q" },
{ 0x88cc, "LLDP" },
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2-next 0/3] add interface to TC MPLS actions
From: John Hurley @ 2019-07-09 15:59 UTC (permalink / raw)
To: netdev
Cc: davem, jiri, xiyou.wangcong, dsahern, willemdebruijn.kernel,
simon.horman, jakub.kicinski, oss-drivers, John Hurley
Recent kernel additions to TC allows the manipulation of MPLS headers as
filter actions.
The following patchset creates an iproute2 interface to the new actions
and includes documentation on how to use it.
John Hurley (3):
lib: add mpls_uc and mpls_mc as link layer protocol names
tc: add mpls actions
man: update man pages for TC MPLS actions
lib/ll_proto.c | 2 +
man/man8/tc-mpls.8 | 156 ++++++++++++++++++++++++++++++
tc/Makefile | 1 +
tc/m_mpls.c | 275 +++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 434 insertions(+)
create mode 100644 man/man8/tc-mpls.8
create mode 100644 tc/m_mpls.c
--
2.7.4
^ permalink raw reply
* Re: [bpf PATCH v2 0/6] bpf: sockmap/tls fixes
From: John Fastabend @ 2019-07-09 15:40 UTC (permalink / raw)
To: Jakub Kicinski, John Fastabend; +Cc: ast, daniel, netdev, edumazet, bpf
In-Reply-To: <20190708231318.1a721ce8@cakuba.netronome.com>
Jakub Kicinski wrote:
> On Mon, 08 Jul 2019 19:13:29 +0000, John Fastabend wrote:
> > Resolve a series of splats discovered by syzbot and an unhash
> > TLS issue noted by Eric Dumazet.
> >
> > The main issues revolved around interaction between TLS and
> > sockmap tear down. TLS and sockmap could both reset sk->prot
> > ops creating a condition where a close or unhash op could be
> > called forever. A rare race condition resulting from a missing
> > rcu sync operation was causing a use after free. Then on the
> > TLS side dropping the sock lock and re-acquiring it during the
> > close op could hang. Finally, sockmap must be deployed before
> > tls for current stack assumptions to be met. This is enforced
> > now. A feature series can enable it.
> >
> > To fix this first refactor TLS code so the lock is held for the
> > entire teardown operation. Then add an unhash callback to ensure
> > TLS can not transition from ESTABLISHED to LISTEN state. This
> > transition is a similar bug to the one found and fixed previously
> > in sockmap. Then apply three fixes to sockmap to fix up races
> > on tear down around map free and close. Finally, if sockmap
> > is destroyed before TLS we add a new ULP op update to inform
> > the TLS stack it should not call sockmap ops. This last one
> > appears to be the most commonly found issue from syzbot.
>
> Looks like strparser is not done'd for offload?
Right so if rx_conf != TLS_SW then the hardware needs to do
the strparser functionality.
>
> About patch 6 - I was recently wondering about the "impossible" syzbot
> report where context is not freed and my conclusion was that there
> can be someone sitting at lock_sock() in tcp_close() already by the
> time we start installing the ULP, so TLS's close will never get called.
> The entire replacing of callbacks business is really shaky :(
Well replacing callbacks is the ULP model. The race we are fixing in
patch 6 is sockmap being free'd which removes psock and resets proto ops
with tcp_close() path.
I don't think there is another race like you describe because tcp_set_ulp
is called from do_tcp_setsockopt which holds the lock and tcp state is
checked to ensure its ESTABLISHED. A closing sock wont be in ESTABLISHED
state so any setup will be aborted. Before patch 1 though I definately
saw this race because we dropped the lock mid-close.
With this series I've been running those syzbot programs over night
without issue on 4 cores. Also selftests pass in ./net/tls and ./bpf/
so I think its stable and resolves many of the issues syzbot has been
stomping around.
>
> Perhaps I'm rumbling, I will take a close look after I get some sleep :)
Yes please do ;)
^ permalink raw reply
* Re: [PATCH net-next iproute2 2/3] tc: Introduce tc ct action
From: Marcelo Ricardo Leitner @ 2019-07-09 15:36 UTC (permalink / raw)
To: Paul Blakey
Cc: Jiri Pirko, Roi Dayan, Yossi Kuperman, Oz Shlomo,
netdev@vger.kernel.org, David Miller, Aaron Conole, Zhike Wang,
Justin Pettit, John Hurley, Rony Efraim, nst-kernel@redhat.com,
Simon Horman
In-Reply-To: <d4f2f3ce-f14d-6026-a271-d627de6d8cea@mellanox.com>
On Tue, Jul 09, 2019 at 06:58:36AM +0000, Paul Blakey wrote:
>
> On 7/8/2019 8:54 PM, Marcelo Ricardo Leitner wrote:
> > On Sun, Jul 07, 2019 at 11:53:47AM +0300, Paul Blakey wrote:
> >> New tc action to send packets to conntrack module, commit
> >> them, and set a zone, labels, mark, and nat on the connection.
> >>
> >> It can also clear the packet's conntrack state by using clear.
> >>
> >> Usage:
> >> ct clear
> >> ct commit [force] [zone] [mark] [label] [nat]
> > Isn't the 'commit' also optional? More like
> > ct [commit [force]] [zone] [mark] [label] [nat]
> >
> >> ct [nat] [zone]
> >>
> >> Signed-off-by: Paul Blakey <paulb@mellanox.com>
> >> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> >> Signed-off-by: Yossi Kuperman <yossiku@mellanox.com>
> >> Acked-by: Jiri Pirko <jiri@mellanox.com>
> >> Acked-by: Roi Dayan <roid@mellanox.com>
> >> ---
> > ...
> >> +static void
> >> +usage(void)
> >> +{
> >> + fprintf(stderr,
> >> + "Usage: ct clear\n"
> >> + " ct commit [force] [zone ZONE] [mark MASKED_MARK] [label MASKED_LABEL] [nat NAT_SPEC]\n"
> > Ditto here then.
>
>
> In commit msg and here, it means there is multiple modes of operation. I
> think it's easier to split those.
Yep, that is good.
More below.
>
> "ct clear" to clear it , not other options can be added here.
>
> "ct commit [force].... " sends to conntrack and commit a connection,
> and only for commit can you specify force mark label, and nat with
> nat_spec....
>
> and the last one, "ct [nat] [zone ZONE]" is to just send the packet to
> conntrack on some zone [optional], restore nat [optional].
>
>
> >
> >> + " ct [nat] [zone ZONE]\n"
> >> + "Where: ZONE is the conntrack zone table number\n"
> >> + " NAT_SPEC is {src|dst} addr addr1[-addr2] [port port1[-port2]]\n"
> >> + "\n");
> >> + exit(-1);
> >> +}
> > ...
> >
> > The validation below doesn't enforce that commit must be there for
> > such case.
> which case? commit is optional. the above are the three valid patterns.
That's the point. But the 2nd example is saying 'commit' word is
mandatory in that mode. It is written as it is a command that was
selected.
One may use just:
ct [zone]
And not
ct commit [zone]
Right?
^ permalink raw reply
* Re: [PATCH net-next 15/16] net/mlx5e: RX, Handle CQE with error at the earliest stage
From: Jiri Pirko @ 2019-07-09 15:34 UTC (permalink / raw)
To: Tariq Toukan
Cc: David S. Miller, netdev, Eran Ben Elisha, ayal, jiri,
Saeed Mahameed, moshe
In-Reply-To: <1562500388-16847-16-git-send-email-tariqt@mellanox.com>
Sun, Jul 07, 2019 at 01:53:07PM CEST, tariqt@mellanox.com wrote:
>From: Saeed Mahameed <saeedm@mellanox.com>
>
>Just to be aligned with the MPWQE handlers, handle RX WQE with error
>for legacy RQs in the top RX handlers, just before calling skb_from_cqe().
>
>CQE error handling will now be called at the same stage regardless of
>the RQ type or netdev mode NIC, Representor, IPoIB, etc ..
>
>This will be useful for down stream patches to improve error CQE
I see only one patch left in this set.
^ 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