On Wed, 18 Nov 2020 09:43:25 -0800, Alexei Starovoitov wrote:
> Just like the kernel doesn't add features for out-of-tree modules
> libbpf doesn't add features for projects where libbpf is optional.
A more fitting comparison would be the kernel refusing to add a new
uAPI call because some applicat
On Thu, 5 Nov 2020 12:45:39 -0800, Andrii Nakryiko wrote:
> That's not true. If you need new functionality like BTF, CO-RE,
> function-by-function verification, etc., then yes, you have to update
> kernel, compiler, libbpf, sometimes pahole. But if you have an BPF
> application that doesn't use and
On Thu, 5 Nov 2020 12:19:00 -0800, Andrii Nakryiko wrote:
> I'll just quote myself here for your convenience.
Sorry, I missed your original email for some reason.
> Submodule is a way that I know of to make this better for end users.
> If there are other ways to pull this off with shared libr
On Thu, 5 Nov 2020 13:22:12 -0800, Andrii Nakryiko wrote:
> test_progs is the only test runner that's run continuously on every
> patch. libbpf CI also runs test_maps and test_verifier. All the other
> test binaries/scripts rely on humans to not forget about them. Which
> works so-so, as you can se
On Thu, 5 Nov 2020 14:57:13 -0800, Jakub Kicinski wrote:
> If you're saying the driver message would still be there if
> verification or translation failed that's perfectly fine, we
> can definitely adjust the test. But some check that driver
> message reporting is working is needed, don't just r
On Thu, 23 Apr 2020 12:58:50 -0700, Andrii Nakryiko wrote:
> To make BPF verifier verbose log more releavant and easier to use to debug
> verification failures, "pop" parts of log that were successfully verified.
> This has effect of leaving only verifier logs that correspond to code branches
> tha
On Tue, 3 Nov 2020 19:11:45 -0800, Alexei Starovoitov wrote:
> When we release new version of libbpf it goes through rigorous testing.
> bpftool gets a lot of test coverage as well.
> iproute2 with shared libbpf will get nothing. It's the same random roll of
> dice.
"Random roll of dice" would be
On Tue, 3 Nov 2020 18:45:59 -0800, Alexei Starovoitov wrote:
> libbpf is the only library I know that is backward and forward compatible.
This is great to hear. It means there will be no problem with iproute2
using the system libbpf. As libbpf is both backward and forward
compatible, iproute2 will
On Mon, 2 Nov 2020 22:58:06 -0800, Andrii Nakryiko wrote:
> But I don't think I got a real answer as to what's the exact reason
> against the submodule. Like what "inappropriate" even means in this
> case? Jesper's security argument so far was the only objective
> criteria, as far as I can tell.
I
aving a timeout for bpf tests, switch it off.
Signed-off-by: Jiri Benc
---
tools/testing/selftests/bpf/settings | 1 +
1 file changed, 1 insertion(+)
create mode 100644 tools/testing/selftests/bpf/settings
diff --git a/tools/testing/selftests/bpf/settings
b/tools/testing/selftests/bpf/setting
g
(there's nothing wrong going on, just some packets are getting dropped) and
hopefully will make admins panic less.
Signed-off-by: Jiri Benc
---
drivers/net/geneve.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
ind
On Fri, 18 Oct 2019 13:03:56 -0700, Tom Herbert wrote:
> More specifically fou allows encapsulation of anything that has an IP
> protocol number. That includes an L3 protocols that have been assigned
> a number (e.g. MPLS, GRE, IPv6, IPv4, EtherIP). So the only need for
> an alternate method to do
Out of the three nc implementations widely in use, at least two (BSD netcat
and nmap-ncat) do not support -l combined with -s. Modify the nc invocation
to be accepted by all of them.
Fixes: 7df5e3db8f63 ("selftests: bpf: tc-bpf flow shaping with EDT")
Cc: Peter Oskolkov
Signed-off-by:
On Wed, 9 Oct 2019 10:58:51 -0400, Willem de Bruijn wrote:
> Yes, this needs a call to gro_cells_receive like geneve_udp_encap_recv
> and vxlan_rcv, instead of returning a negative value back to
> udp_queue_rcv_one_skb. Though that's not a major change.
Willem, how would you do that? The whole fou
On Wed, 9 Oct 2019 09:55:27 +0200, Simon Horman wrote:
> This is the same concerned that was raised by others when I posed a patch
> to allow setting of Geneve options in a similar manner. I think what is
> called for here, as was the case in the Geneve work, is to expose netlink
> attributes for e
dd handling of BPF_LWT_REROUTE to lwt_bpf.c")
Cc: Peter Oskolkov
Signed-off-by: Jiri Benc
---
net/core/lwt_bpf.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c
index f93785e5833c..74cfb8b5ab33 100644
--- a/net/core/lwt_bpf.c
+++ b
On Fri, 4 Oct 2019 18:37:44 +, Yonghong Song wrote:
> distro can package bpf/btf uapi headers into libbpf package.
> Users linking with libbpf.a/libbpf.so can use bpf/btf.h with include
> path pointing to libbpf dev package include directory.
> Could this work?
I don't think it would. Distros
On Fri, 4 Oct 2019 11:30:26 -0700, Jakub Kicinski wrote:
> Surely for distroes tho - they would have kernel headers matching the
> kernel release they ship. If parts of libbpf from GH only work with
> the latest kernel, distroes should ship libbpf from the kernel source,
> rather than GH.
I don't
.
Fixes: 50b3ed57dee9 ("selftests/bpf: test bpf flow dissection")
Cc: Petar Penkov
Signed-off-by: Jiri Benc
---
tools/testing/selftests/bpf/test_flow_dissector.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_flow_dissector.sh
b/tools/testing
The test_flow_dissector and test_lwt_ip_encap selftests were failing for me.
It was caused by the tests not being enough system/distro independent.
Jiri Benc (2):
selftests/bpf: set rp_filter in test_flow_dissector
selftests/bpf: more compatible nc options in test_lwt_ip_encap
tools/testing
Out of the three nc implementations widely in use, at least two (BSD netcat
and nmap-ncat) do not support -l combined with -s. Modify the nc invocation
to be accepted by all of them.
Fixes: 17a90a788473 ("selftests/bpf: test that GSO works in lwt_ip_encap")
Cc: Peter Oskolkov
Signed-of
The progs for bpf selftests use several different notations to force
function inlining. Standardize to what most of them use,
static __always_inline.
Suggested-by: Song Liu
Signed-off-by: Jiri Benc
---
tools/testing/selftests/bpf/progs/pyperf.h| 9 +++--
.../testing/selftests/bpf/progs
this, convert to 'static __always_inline'.
v2: Use 'static __always_inline' instead of 'static inline
__attribute__((always_inline))'
Fixes: c99a84eac026 ("selftests/bpf: test for seg6local End.BPF action")
Signed-off-by: Jiri Benc
---
.../testing/
On Mon, 1 Jul 2019 11:39:27 -0700, Y Song wrote:
> By default, we have
> # define __always_inlineinline __attribute__((always_inline))
>
> So just use __always_inline should be less verbose in your patch.
I'll resubmit, converting everything to __always_inline, targeting
bpf-next.
> BTW,
On Sat, 29 Jun 2019 11:04:54 -0700, Song Liu wrote:
> > Maybe use "__always_inline" as most other tests do?
>
> I meant "static __always_inline".
Sure, I can do that. It doesn't seem to be as consistent as you
suggest, though.
There are three different forms used in selftests/bpf/progs:
stati
tic inline' to fix this.
Fixes: c99a84eac026 ("selftests/bpf: test for seg6local End.BPF action")
Signed-off-by: Jiri Benc
---
.../selftests/bpf/progs/test_lwt_seg6local.c| 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/te
On Wed, 17 Apr 2019 08:43:06 -0700, Richard Cochran wrote:
> If NET_ADMIN is enabled in the container, don't the host and container
> contend with each other for the physical interfaces anyhow?
Physical interfaces are not a problem, as each interface can be only in
a single net name space.
The pr
hile this patch is needed for metadata based tunnels.
Signed-off-by: Jiri Benc
---
drivers/net/geneve.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 3377ac66a347..5583d993480d 100644
--- a/drivers/net/geneve.c
+
On Tue, 6 Nov 2018 22:38:56 +0100, Stefano Brivio wrote:
> - patch 1/11 adds a socket lookup for UDP tunnels that use, by design,
> the same destination port on both endpoints -- i.e. VxLAN and GENEVE
This is not necessarily true with lwtunnels (collect_md mode of VXLAN
and GENEVE). While any s
On Tue, 2 Oct 2018 08:55:19 -0600, David Ahern wrote:
> You want take issue with a name suggest a different one.
I don't have a strong opinion on this. STRICT_HDR? HDR_CHECKED?
VERIFY_HDR? If you feel that your proposal is better, I don't mind.
Thanks,
Jiri
On Tue, 2 Oct 2018 08:57:24 -0600, David Ahern wrote:
> You can when you introduce a new option or a new flag that is required
> to get new behavior like kernel side filtering.
Yes. That was what I tried with the patchset a few years back. It would
be nice to revive the effort.
> I chose a netlin
On Tue, 2 Oct 2018 09:11:17 -0600, David Ahern wrote:
> Generically speaking a filter modifies the output based on the input.
> Specifying a target namespace is an input to the dump that modifies the
> output.
That's conventionally called "algorithm" :-)
Let's just say we have a different underst
On Tue, 2 Oct 2018 13:18:32 +0200, Christian Brauner wrote:
> I didn't find this in the linked thread.
Maybe it was suggested in another thread or in person on a conference,
I can't remember, it's too long ago, sorry.
> What I find interesting and convincing is one of Dave's points:
>
> "I'm beg
On Tue, 2 Oct 2018 13:03:00 +0200, Christian Brauner wrote:
> Well, it's a namespace filter that's how I saw it.
That would imply that without it, you get data from all name spaces
(= unfiltered by name space), which is not what's happening :-)
Jiri
On Mon, 1 Oct 2018 17:28:29 -0700, David Ahern wrote:
> Add a new flag, NLM_F_DUMP_PROPER_HDR, for userspace to indicate to the
> kernel that it believes it is sending the right header struct for the
> dump message type (ifinfomsg, ifaddrmsg, rtmsg, fib_rule_hdr, ...).
Why is this limited to dump
LM_F_DUMP_FILTERED
(if not complemented by a real filter).
I understand that you want to differentiate between data dumped without
and with IFA_TARGET_NETNSID present. But we already have that: the
IFA_TARGET_NETNSID attribute is returned back in the latter case.
Nacked-by: Jiri Benc
Jiri
On Fri, 28 Sep 2018 12:28:41 -0700, David Ahern wrote:
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1898,10 +1898,8 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb,
> struct netlink_callback *cb)
> if (tb[IFLA_IF_NETNSID]) {
> netnsid = nla
On Tue, 25 Sep 2018 09:37:41 -0600, David Ahern wrote:
> For ifaddrmsg ifa_flags aligns with ifi_type which is set by kernel side
> so this should be ok.
Does the existing user space set ifi_type to anything? Does it zero out
the field?
Are we able to find a flag value that is not going to be set
On Tue, 25 Sep 2018 11:49:10 +0200, Christian Brauner wrote:
> So if people really want to hide this issue as much as we can then we
> can play the guessing game. I could send a patch that roughly does the
> following:
>
> if (nlmsg_len(cb->nlh) < sizeof(struct ifinfomsg))
> guessed_header
On Wed, 19 Sep 2018 11:25:17 +0200, Johannes Berg wrote:
> Now, with this patch, all I'm doing is changing the internal behaviour
> of nla_parse/nla_validate - externally, it still overwrites any existing
> message if an error occurs, but internally it keeps the inner-most
> error.
Ah, okay, that
On Wed, 19 Sep 2018 11:15:25 +0200, Johannes Berg wrote:
> For one, having the NL_SET_* macros check it on their own will already
> not work - as we discussed over in the NLA_REJECT thread, we do need to
> be able to override the data, e.g. if somebody does
>
> NL_SET_ERR_MSG(extack, "warning: dep
On Tue, 18 Sep 2018 15:12:11 +0200, Johannes Berg wrote:
> static int validate_nla(const struct nlattr *nla, int maxtype,
> const struct nla_policy *policy,
> - const char **error_msg)
> + struct netlink_ext_ack *extack, bool *extack_se
d behavior, let's
> add a new IFLA_GENEVE_TTL_INHERIT for geneve ttl inherit support.
>
> Reported-by: Jianlin Shi
> Suggested-by: Jiri Benc
> Signed-off-by: Hangbin Liu
Reviewed-by: Jiri Benc
Thanks, Hangbin!
Jiri
pspotmail.com
> Fixes: c411ed854584 ("nsh: add GSO support")
> Signed-off-by: Willem de Bruijn
Acked-by: Jiri Benc
On Thu, 28 Jun 2018 10:05:36 -0700, Jakub Kicinski wrote:
> Can we take this as a follow up through the bpf-next tree or do you
> want us to respin as part of this set?
I think BPF is a separate issue.
Jiri
On Thu, 28 Jun 2018 09:54:52 -0700, Jakub Kicinski wrote:
> Hmm... in practice we could steal top bits of the size parameter for
> some flags, since it seems to be limited to values < 256 today? Is it
> worth it?
>
> It would look something along the lines of:
Something like that, yes. I'll leav
On Wed, 27 Jun 2018 11:49:49 +0200, Daniel Borkmann wrote:
> Looks good to me, and yes in BPF case a mask like TUNNEL_OPTIONS_PRESENT is
> right approach since this is opaque info and solely defined by the BPF prog
> that is using the generic helper.
Wouldn't it make sense to introduce some safegu
if (nsh_len < NSH_BASE_HDR_LEN)
> + goto out;
> if (unlikely(!pskb_may_pull(skb, nsh_len)))
> goto out;
>
Acked-by: Jiri Benc
Thanks, Eric, and shame on me!
Jiri
On Wed, 25 Apr 2018 14:22:45 -0700, John Fastabend wrote:
> --- a/tools/bpf/Makefile
> +++ b/tools/bpf/Makefile
> @@ -76,6 +76,8 @@ $(OUTPUT)bpf_asm: $(OUTPUT)bpf_asm.o
> $(OUTPUT)bpf_exp.yacc.o $(OUTPUT)bpf_exp.le
> $(QUIET_LINK)$(CC) $(CFLAGS) -o $@ $^
>
> $(OUTPUT)bpf_exp.lex.c: $(OUTP
On Wed, 14 Mar 2018 20:37:00 -0700, Alexei Starovoitov wrote:
> Hanness expressed the reasons why RHEL doesn't support ipvlan long ago.
> I couldn't find the complete link. This one mentions some of the issues:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg157614.html
ipvlan improved a
On Fri, 9 Mar 2018 04:53:07 -0800, Eric Dumazet wrote:
> Unless you bring it up ;)
Often, you need some options to be specified, thus you end up creating
another interface anyway.
> Compatibility problems, mostly.
> Some users might depend on existing behavior.
How is this a compatibility probl
On Tue, 6 Mar 2018 18:08:05 +0100, Simon Horman wrote:
> +static int
> +tunnel_key_copy_geneve_opt(const struct nlattr *nla, int dst_len, void *dst,
> +struct netlink_ext_ack *extack)
> +{
> + struct nlattr *tb[TCA_TUNNEL_KEY_ENC_OPT_GENEVE_MAX + 1];
> + int err, da
On Tue, 6 Mar 2018 18:08:04 +0100, Simon Horman wrote:
> - if (!tb[TCA_TUNNEL_KEY_PARMS])
> + if (!tb[TCA_TUNNEL_KEY_PARMS]) {
> + NL_SET_ERR_MSG(extack, "Missing tunnel key parameter");
"parameters" (it's not just one parameter)
> @@ -107,6 +109,7 @@ static int tunnel_key_in
On Thu, 8 Mar 2018 12:51:41 -0800, Eric Dumazet wrote:
> Note that these tunnels are still created for the initial namespace,
> to be the least intrusive for typical setups.
Since this is a knob and must be turned on explicitly, why we don't get
rid of the automatic interfaces even for the initia
On Thu, 8 Mar 2018 23:38:12 -0800, Jakub Kicinski wrote:
> FWIW I couldn't reproduce this one. Out of curiosity what GCC did you
> use?
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
Jiri
Currently, the programs under tools/bpf (with the notable exception of
bpftool) do not respect the output directory (make O=dir). Fix that.
Signed-off-by: Jiri Benc
---
tools/bpf/Makefile | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git
Make the 'install' target depend on the 'all' target to build the binaries
first.
Signed-off-by: Jiri Benc
---
tools/bpf/Makefile | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index c42ca24a072d..e8d9e4125bf
either. It
installs unconditionally to /usr/bin without respecting DESTDIR and prefix.
This patchset improves that behavior.
Jiri Benc (7):
tools: bpftool: silence 'missing initializer' warnings
tools: bpf: respect output directory during build
tools: bpf: consistent make bpf_install
t
Default to quiet build, with V=1 enabling verbose build as is usual.
Signed-off-by: Jiri Benc
---
tools/bpf/Makefile | 38 +++---
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index daca0a4277d1
Even in quiet mode, make finishes with
rm tools/bpf/bpf_exp.lex.c
That's because it considers the file to be intermediate. Silence that by
mentioning the lex.c file instead of the lex.o file; the dependency still
stays.
Signed-off-by: Jiri Benc
---
tools/bpf/Makefile | 2 +-
1 file chang
.
Signed-off-by: Jiri Benc
---
tools/bpf/Makefile | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index e7b15967492e..c42ca24a072d 100644
--- a/tools/bpf/Makefile
+++ b/tools/bpf/Makefile
@@ -1,12 +1,13 @@
# SPDX-License-Identifier
/git/net-next/tools/lib/bpf/bpf.h:26:0,
from prog.c:47:
/home/storage/jbenc/git/net-next/tools/include/uapi/linux/bpf.h:925:8: note:
‘type’ declared here
__u32 type;
^
As these warnings are not useful, switch them off.
Signed-off-by: Jiri Benc
---
tools/bpf/bpftool
Use the descend macro to properly propagate $(subdir) to bpftool.
Signed-off-by: Jiri Benc
---
tools/bpf/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index e8d9e4125bf3..daca0a4277d1 100644
--- a/tools/bpf/Makefile
On Tue, 6 Mar 2018 15:39:07 +0100, Daniel Borkmann wrote:
> Thanks for the fix, Jiri! The standard approach to resolve such header
> dependencies under
> tools/ would be to add a copy of magic.h uapi header into
> tools/include/uapi/linux/magic.h.
>
> Both bpftool and libbpf have tools/include/u
;
^
Fix this the same way it is already in tools/lib/bpf/libbpf.c and
tools/lib/api/fs/fs.c.
Signed-off-by: Jiri Benc
---
tools/bpf/bpftool/common.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c
index 0b482c0070e0
On Wed, 28 Feb 2018 08:12:41 +0100, Jiri Pirko wrote:
> Yeah, or if you have an older iproute2 package. I would keep the existing
> dmesg msgs for now. In the future, when everyone is used to exacks, then
> we can remove them.
How do we ensure that this will actually happen in the future? Usually,
On Tue, 27 Feb 2018 17:38:08 +0200, Ido Schimmel wrote:
> if (port_dev->flags & IFF_LOOPBACK) {
> + NL_SET_ERR_MSG(extack, "Loopback device can't be added as a
> team port");
> netdev_err(dev, "Device %s is loopback device. Loopback devices
> can't be added as a te
On Fri, 23 Feb 2018 04:39:37 -0500, Andrew Cann wrote:
> In a program I'm writing I have a network namespace with a virtual (TAP)
> network interface assigned to it. I would like it so that the interface is
> automatically destroyed when the namespace is destroyed (ie. when the last
> process in th
se of passing multiple netns identifying properties into
> the same request EINVAL seems the perfect candidate and the error
> message seems instructive to userspace programs.
Agreed.
Acked-by: Jiri Benc
Thanks,
Jiri
On Tue, 6 Feb 2018 14:19:02 +0100, Christian Brauner wrote:
> +/* Verify that rtnetlink requests supporting network namespace ids
> + * do not pass additional properties potentially referring to different
> + * network namespaces.
> + */
> +static int rtnl_ensure_unique_netns(struct nlattr *tb[],
On Tue, 06 Feb 2018 16:31:29 -0600, Eric W. Biederman wrote:
> Frankly. If we are talking precedence it should be:
> fds
> netnsids
> pids
The current order is 1. pids, 2. fds, though. Not that it matters much,
see below.
> I do think it makes a lot of sense to error if someone passes in
> dupli
On Fri, 26 Jan 2018 00:34:51 +0100, Nicolas Dichtel wrote:
> Why meaningful? The user knows that the answer is like if if was done in
> another
> netns. It enables to have only one netlink socket instead of one per netns.
> But
> the code using it will be the same.
Because you can't use it to
On Thu, 25 Jan 2018 15:01:39 +0100, Nicolas Dichtel wrote:
> The goal is to let the user follow an interface that moves to another
> netns.
>
> CC: Jiri Benc
> CC: Christian Brauner
> Signed-off-by: Nicolas Dichtel
This is great, thanks, Nicolas!
Reviewed-by: Jiri Benc
On Thu, 25 Jan 2018 15:01:38 +0100, Nicolas Dichtel wrote:
> The user should be able to follow any interface that moves to another
> netns. There is no reason to hide physical interfaces.
>
> CC: Jiri Benc
> CC: Christian Brauner
> Signed-off-by: Nicolas Dichtel
Reviewed-by: Jiri Benc
On Thu, 25 Jan 2018 15:20:59 +0100, Nicolas Dichtel wrote:
> Hmm, I don't agree. For me, it would be the correct answer. If user has a
> socket
> in ns_a and targets a RTM_GETLINK in ns_b, the answer he gets should be like
> if
> it was done in ns_b.
But that information would be useless for the
On Wed, 24 Jan 2018 16:24:34 +0100, Nicolas Dichtel wrote:
> I wonder if it would be possible to do something in the netlink framework,
> like
> NETLINK_LISTEN_ALL_NSID.
> Having some ancillary data at the netlink socket level and a function like
> nlsock_net() (instead of sock_net()) to get the c
On Wed, 24 Jan 2018 11:53:11 +0100, Nicolas Dichtel wrote:
> Le 23/01/2018 à 18:08, Jiri Benc a écrit :
> > It would be much better if the whole (ifindex, netnsid) pair was
> > returned. I think it could be added.
> Sure. Do you plan to send a patch?
I can do that but it will
On Tue, 23 Jan 2018 17:37:11 +0100, Nicolas Dichtel wrote:
> When a virtual interface moves to another netns, the netlink RTM_DELLINK
> message
> contains the attribute IFLA_NEW_NETNSID, which identifies where the interface
> moves. The nsid may be allocated if needed.
The problem is that ifindex
(Christian, I'm adding back the netdev list, there's no reason not to
have the discussion in open.)
On Tue, 23 Jan 2018 12:42:19 +0100, Christian Brauner wrote:
> Thanks for the comments and discussion. Sorry, for not going through the
> list but I just have a quick question that doesn't deserve t
On Tue, 23 Jan 2018 11:26:58 +0100, Wolfgang Bumiller wrote:
> Even if you know the netnsid, do the mentioned watches work for
> nested/child namespaces if eg. a container creates new namespace before
> and/or after the watch was established and moves interfaces to these
> child namespaces, would y
On Mon, 22 Jan 2018 23:25:41 +0100, Christian Brauner wrote:
> This is not necessarily true in scenarios where I move a network device
> via RTM_NEWLINK + IFLA_NET_NS_PID into a network namespace I haven't
> created. Here is an example:
>
> nlmsghdr->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
> nlms
On Mon, 22 Jan 2018 22:23:54 +0100, Christian Brauner wrote:
> That is certainly a good idea and I'm happy to send a follow-up patch
> for that!
Note that I haven't looked into that and I don't know whether it is
easily possible. I'll appreciate if you could try that.
> But there's still value in
On Thu, 18 Jan 2018 21:55:53 +0100, Christian Brauner wrote:
> A more concrete scenario is creating a network namespace, moving a
> device into it via RTM_SETLINK which also supports IFLA_NET_NS_{FD,PID}
> and then wanting to query the device. This would be very easy to do if
> one could reuse the
On Mon, 22 Jan 2018 18:46:53 +0200, Serhey Popovych wrote:
> + if (tb[IFLA_GRE_COLLECT_METADATA]) {
> + print_bool(PRINT_ANY, "collect_metadata", "external", true);
> + return;
> + }
Nacked-by: Jiri Benc
Don't ever use "
On Thu, 18 Jan 2018 21:21:24 +0100, Christian Brauner wrote:
> In such scenarios setting a netns id property is
> not really wanted
Why? I think that's what you should do if you want to avoid setns. Just
use netnsid. I don't see any problem with that and you didn't provide
any explanation.
Jiri
On Thu, 18 Jan 2018 02:12:34 +0100, grzegorz.ha...@gmail.com wrote:
> This patch allows to enable hardware timestamping on macvlan intefaces and
> find out capabilities of the lower device.
>
> Signed-off-by: Grzegorz Halat
NACK. This does not work.
For start, how do you deal with fwd_priv? Wh
Looks much better.
On Wed, 17 Jan 2018 09:32:51 -0800, William Tu wrote:
> + OVS_ERSPAN_OPT_IDX, /* be32 index */
Why don't you convert this to u32 while passing to/from user space?
> + [OVS_ERSPAN_OPT_IDX]= { .len = sizeof(u32) },
sizeof(__be32) but see above.
Thanks,
Jiri
supporting only one field. Thus, this
> patch reverts it and later patch will redo it using nested attr.
>
> Signed-off-by: William Tu
> Cc: Jiri Benc
> Cc: Pravin Shelar
Acked-by: Jiri Benc
On Fri, 12 Jan 2018 09:50:35 -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
> (Looks like you missed the last update I mentioned)
I did not miss it. The proposed behavior is inconsistent and has no
clear pattern (I used the word "magic" for that). I guess examples will
help more. See below.
> Here
On Fri, 12 Jan 2018 09:34:13 +0100, Jiri Benc wrote:
> I don't think this works currently. When someone (does not have to be
> you, it can be a management software running in background) sets the
> MTU to the current value, the magic behavior is lost without any way to
> resto
On Thu, 11 Jan 2018 08:59:58 -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
> I guess the logic would be as simple as - if mtu_adj for a slave is
> set to 0, then it's
> following master otherwise not. By setting different mtu for a slave, you will
> set this mtu_adj a positive number which would mea
On Thu, 11 Jan 2018 08:34:14 -0800, William Tu wrote:
> I'd also prefer reverting ceaa001a170e since it's more clean but I
> also hope to have this feature in 4.15.
> How long does reverting take? Am I only able to submit the new patch
> after the reverting is merged? Or I can submit revert and thi
On Wed, 10 Jan 2018 18:09:50 -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
> I still prefer the approach I had mentioned that uses 'mtu_adj'. In
> that approach you can leave those slaves which have changed their mtu
> to be lower than masters' but if master's mtu changes to larger value
> all other
On Wed, 10 Jan 2018 22:35:14 +0100, Jiri Benc wrote:
> The existing field must continue to work in the same way as before. It must
> be accepted and *returned* by the kernel. You may add an additional field
> but the existing behavior must be 100% preserved, both uABI and uAPI wise.
An
On Tue, 9 Jan 2018 17:51:22 -0800, William Tu wrote:
> - [OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS] = { .len = sizeof(u32) },
> + [OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTSV1] = { .len = sizeof(u32) },
> + [OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS] = { .len = OVS_ATTR_NESTED,
> +
On Tue, 9 Jan 2018 17:51:22 -0800, William Tu wrote:
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -363,7 +373,8 @@ enum ovs_tunnel_key_attr {
> OVS_TUNNEL_KEY_ATTR_IPV6_SRC, /* struct in6_addr src IPv6
> address. */
> OVS_TUNNEL_KEY_
37 ("openvswitch: add processing of L3 packets")
> Signed-off-by: Eric Garver
Thanks!
Reviewed-by: Jiri Benc
On Wed, 20 Dec 2017 10:39:32 -0500, Eric Garver wrote:
> + if (is_flow_key_valid(key) && key->eth.vlan.tci && key->eth.cvlan.tci)
Maybe (key->eth.vlan.tci & htons(VLAN_TAG_PRESENT)) for consistency
with the rest of the code? But it's just nitpicking.
The real problem here is when a double tag
On Tue, 19 Dec 2017 13:57:53 -0500, Eric Garver wrote:
> --- a/net/openvswitch/flow.c
> +++ b/net/openvswitch/flow.c
> @@ -559,8 +559,9 @@ static int parse_nsh(struct sk_buff *skb, struct
> sw_flow_key *key)
> * of a correct length, otherwise the same as skb->network_header.
> * For
On Mon, 6 Nov 2017 15:04:54 +, Colin King wrote:
> The size for IFLA_IF_NETNSID is missing from the size calculation
> because the proceeding semicolon was not removed. Fix this by removing
> the semicolon.
Acked-by: Jiri Benc
Thanks for spotting this! Looking at my initial co
1 - 100 of 1272 matches
Mail list logo
