* [PATCH iproute2 0/3] Improve tunnel local/remote endpoint params and gre link attribute handling
From: Serhey Popovych @ 2017-12-13 19:35 UTC (permalink / raw)
To: netdev
In this series following problems addressed:
1) Size of IFLA_GRE_LINK attribute is 32 bits long in , not 8 bit.
2) Use get_addr() instead of get_prefix() to parse local/remote
tunnel endpoints as IPADDR, not PREFIX as per ip-link(8).
3) No need to check if local/remote endpoints are zero (e.g. INADDR_ANY):
it is fully legal value, accepted by the kernel.
See individual patch description message for details.
Thanks,
Serhii
Serhey Popovych (3):
ip/tunnel: Unify setup and accept zero address for local/remote
endpoints
ip/tunnel: Use get_addr() instead of get_prefix() for local/remote
endpoints
ip: gre: fix IFLA_GRE_LINK attribute sizing
ip/ip6tunnel.c | 8 ++------
ip/iptunnel.c | 10 ++--------
ip/link_gre.c | 8 +++-----
ip/link_gre6.c | 8 ++------
ip/link_ip6tnl.c | 12 ++++--------
ip/link_iptnl.c | 10 ++--------
ip/link_vti.c | 14 ++------------
ip/link_vti6.c | 26 ++++++++------------------
8 files changed, 25 insertions(+), 71 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH iproute2 1/3] ip/tunnel: Unify setup and accept zero address for local/remote endpoints
From: Serhey Popovych @ 2017-12-13 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513193762-1580-1-git-send-email-serhe.popovych@gmail.com>
It is fully legal to submit zero (INADDR_ANY/IN6ADDR_ANY_INIT)
value for local and/or remote endpoints for all tunnel drivers:
no need additionally check this in userspace.
Note that all tunnel specific code already can pass zero address
to the kernel.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/iptunnel.c | 10 ++--------
ip/link_gre.c | 6 ++----
ip/link_iptnl.c | 10 ++--------
ip/link_vti.c | 14 ++------------
ip/link_vti6.c | 26 ++++++++------------------
5 files changed, 16 insertions(+), 50 deletions(-)
diff --git a/ip/iptunnel.c b/ip/iptunnel.c
index 208a1f0..ce610f8 100644
--- a/ip/iptunnel.c
+++ b/ip/iptunnel.c
@@ -127,16 +127,10 @@ static int parse_args(int argc, char **argv, int cmd, struct ip_tunnel_parm *p)
p->iph.frag_off = htons(IP_DF);
} else if (strcmp(*argv, "remote") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- p->iph.daddr = get_addr32(*argv);
- else
- p->iph.daddr = htonl(INADDR_ANY);
+ p->iph.daddr = get_addr32(*argv);
} else if (strcmp(*argv, "local") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- p->iph.saddr = get_addr32(*argv);
- else
- p->iph.saddr = htonl(INADDR_ANY);
+ p->iph.saddr = get_addr32(*argv);
} else if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
medium = *argv;
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 43cb1af..6f82fb4 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -251,12 +251,10 @@ get_failed:
pmtudisc = 1;
} else if (!matches(*argv, "remote")) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- daddr = get_addr32(*argv);
+ daddr = get_addr32(*argv);
} else if (!matches(*argv, "local")) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- saddr = get_addr32(*argv);
+ saddr = get_addr32(*argv);
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index 4940b8b..521d6ba 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -195,16 +195,10 @@ get_failed:
while (argc > 0) {
if (strcmp(*argv, "remote") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- raddr = get_addr32(*argv);
- else
- raddr = 0;
+ raddr = get_addr32(*argv);
} else if (strcmp(*argv, "local") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- laddr = get_addr32(*argv);
- else
- laddr = 0;
+ laddr = get_addr32(*argv);
} else if (matches(*argv, "dev") == 0) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_vti.c b/ip/link_vti.c
index 07ac94e..05aefa3 100644
--- a/ip/link_vti.c
+++ b/ip/link_vti.c
@@ -167,20 +167,10 @@ get_failed:
okey = uval;
} else if (!matches(*argv, "remote")) {
NEXT_ARG();
- if (!strcmp(*argv, "any")) {
- fprintf(stderr, "invalid value for \"remote\": \"%s\"\n", *argv);
- exit(-1);
- } else {
- daddr = get_addr32(*argv);
- }
+ daddr = get_addr32(*argv);
} else if (!matches(*argv, "local")) {
NEXT_ARG();
- if (!strcmp(*argv, "any")) {
- fprintf(stderr, "invalid value for \"local\": \"%s\"\n", *argv);
- exit(-1);
- } else {
- saddr = get_addr32(*argv);
- }
+ saddr = get_addr32(*argv);
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_vti6.c b/ip/link_vti6.c
index 6d08bfe..f665520 100644
--- a/ip/link_vti6.c
+++ b/ip/link_vti6.c
@@ -161,27 +161,17 @@ get_failed:
}
okey = uval;
} else if (!matches(*argv, "remote")) {
- NEXT_ARG();
- if (!strcmp(*argv, "any")) {
- fprintf(stderr, "invalid value for \"remote\": \"%s\"\n", *argv);
- exit(-1);
- } else {
- inet_prefix addr;
+ inet_prefix addr;
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&daddr, addr.data, addr.bytelen);
- }
- } else if (!matches(*argv, "local")) {
NEXT_ARG();
- if (!strcmp(*argv, "any")) {
- fprintf(stderr, "invalid value for \"local\": \"%s\"\n", *argv);
- exit(-1);
- } else {
- inet_prefix addr;
+ get_prefix(&addr, *argv, AF_INET6);
+ memcpy(&daddr, addr.data, addr.bytelen);
+ } else if (!matches(*argv, "local")) {
+ inet_prefix addr;
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&saddr, addr.data, addr.bytelen);
- }
+ NEXT_ARG();
+ get_prefix(&addr, *argv, AF_INET6);
+ memcpy(&saddr, addr.data, addr.bytelen);
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 2/3] ip/tunnel: Use get_addr() instead of get_prefix() for local/remote endpoints
From: Serhey Popovych @ 2017-12-13 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513193762-1580-1-git-send-email-serhe.popovych@gmail.com>
Manual page ip-link(8) states that both local and remote accept
IPADDR not PREFIX. Use get_addr() instead of get_prefix() to
parse local/remote endpoint address correctly.
Force corresponding address family instead of using preferred_family
to catch weired cases as shown below.
Before this patch it is possible to create tunnel with commands:
ip li add dev ip6gre2 type ip6gre local fe80::1/64 remote fe80::2/64
ip -4 li add dev ip6gre2 type ip6gre local 10.0.0.1/24 remote 10.0.0.2/24
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/ip6tunnel.c | 8 ++------
ip/link_gre6.c | 8 ++------
ip/link_ip6tnl.c | 12 ++++--------
ip/link_vti6.c | 8 ++++----
4 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/ip/ip6tunnel.c b/ip/ip6tunnel.c
index 4563e1e..b8db49c 100644
--- a/ip/ip6tunnel.c
+++ b/ip/ip6tunnel.c
@@ -170,17 +170,13 @@ static int parse_args(int argc, char **argv, int cmd, struct ip6_tnl_parm2 *p)
inet_prefix raddr;
NEXT_ARG();
- get_prefix(&raddr, *argv, preferred_family);
- if (raddr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
+ get_addr(&raddr, *argv, AF_INET6);
memcpy(&p->raddr, &raddr.data, sizeof(p->raddr));
} else if (strcmp(*argv, "local") == 0) {
inet_prefix laddr;
NEXT_ARG();
- get_prefix(&laddr, *argv, preferred_family);
- if (laddr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
+ get_addr(&laddr, *argv, AF_INET6);
memcpy(&p->laddr, &laddr.data, sizeof(p->laddr));
} else if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
diff --git a/ip/link_gre6.c b/ip/link_gre6.c
index 0a82eae..c22fded 100644
--- a/ip/link_gre6.c
+++ b/ip/link_gre6.c
@@ -257,17 +257,13 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
+ get_addr(&addr, *argv, AF_INET6);
memcpy(&raddr, &addr.data, sizeof(raddr));
} else if (!matches(*argv, "local")) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
+ get_addr(&addr, *argv, AF_INET6);
memcpy(&laddr, &addr.data, sizeof(laddr));
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
diff --git a/ip/link_ip6tnl.c b/ip/link_ip6tnl.c
index 43287ab..4ab337f 100644
--- a/ip/link_ip6tnl.c
+++ b/ip/link_ip6tnl.c
@@ -184,18 +184,14 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
- memcpy(&raddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&raddr, addr.data, sizeof(raddr));
} else if (strcmp(*argv, "local") == 0) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
- memcpy(&laddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&laddr, addr.data, sizeof(laddr));
} else if (matches(*argv, "dev") == 0) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_vti6.c b/ip/link_vti6.c
index f665520..84824a5 100644
--- a/ip/link_vti6.c
+++ b/ip/link_vti6.c
@@ -164,14 +164,14 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&daddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&daddr, addr.data, sizeof(daddr));
} else if (!matches(*argv, "local")) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&saddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&saddr, addr.data, sizeof(saddr));
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 3/3] ip: gre: fix IFLA_GRE_LINK attribute sizing
From: Serhey Popovych @ 2017-12-13 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513193762-1580-1-git-send-email-serhe.popovych@gmail.com>
Attribute IFLA_GRE_LINK is 32 bit long, not 8 bit.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/link_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 6f82fb4..09f1e44 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -155,7 +155,7 @@ get_failed:
tos = rta_getattr_u8(greinfo[IFLA_GRE_TOS]);
if (greinfo[IFLA_GRE_LINK])
- link = rta_getattr_u8(greinfo[IFLA_GRE_LINK]);
+ link = rta_getattr_u32(greinfo[IFLA_GRE_LINK]);
if (greinfo[IFLA_GRE_ENCAP_TYPE])
encaptype = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_TYPE]);
--
1.7.10.4
^ permalink raw reply related
* Re: x86 boot broken on -rc1?
From: Björn Töpel @ 2017-12-13 19:37 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: LKML, netdev@vger.kernel.org
In-Reply-To: <20171201163954.2e356787@cakuba.netronome.com>
2017-12-02 1:39 GMT+01:00 Jakub Kicinski <jakub.kicinski@netronome.com>:
> Hi!
>
> I'm hitting these after DaveM pulled rc1 into net-next on my Xeon
> E5-2630 v4 box. It also happens on linux-next. Did anyone else
> experience it? (.config attached)
>
> [ 5.003771] WARNING: CPU: 14 PID: 1 at ../arch/x86/events/intel/uncore.c:936 uncore_pci_probe+0x285/0x2b0
> [ 5.007544] Modules linked in:
> [ 5.007544] CPU: 14 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.007544] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.007544] task: 000000009e842725 task.stack: 000000008a63fd2d
> [ 5.007544] RIP: 0010:uncore_pci_probe+0x285/0x2b0
> [ 5.007544] RSP: 0000:ffffad8580163d10 EFLAGS: 00010286
> [ 5.007544] RAX: ffff98576cc3df30 RBX: ffffffffb08037e0 RCX: ffffffffb0c1a120
> [ 5.007544] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb0c1a960
> [ 5.007544] RBP: ffff985b6c00ac00 R08: fffffffffffffffe R09: 00000000000fffff
> [ 5.007544] R10: ffff98576f1b6018 R11: 0000000000000022 R12: ffff985b6c641000
> [ 5.007544] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000001
> [ 5.007544] FS: 0000000000000000(0000) GS:ffff98576fb80000(0000) knlGS:0000000000000000
> [ 5.007544] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.007544] CR2: 0000000000000000 CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.007544] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.007544] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.007544] Call Trace:
> [ 5.007544] local_pci_probe+0x3d/0x90
> [ 5.007544] ? pci_match_device+0xd9/0x100
> [ 5.007544] pci_device_probe+0x122/0x180
> [ 5.007544] driver_probe_device+0x246/0x330
> [ 5.007544] ? set_debug_rodata+0x11/0x11
> [ 5.007544] __driver_attach+0x8a/0x90
> [ 5.007544] ? driver_probe_device+0x330/0x330
> [ 5.007544] bus_for_each_dev+0x5c/0x90
> [ 5.007544] bus_add_driver+0x196/0x220
> [ 5.007544] driver_register+0x57/0xc0
> [ 5.007544] intel_uncore_init+0x1e3/0x249
> [ 5.007544] ? uncore_type_init+0x193/0x193
> [ 5.007544] ? set_debug_rodata+0x11/0x11
> [ 5.007544] do_one_initcall+0x4b/0x190
> [ 5.007544] kernel_init_freeable+0x16e/0x1f5
> [ 5.007544] ? rest_init+0xd0/0xd0
> [ 5.007544] kernel_init+0xa/0x100
> [ 5.007544] ret_from_fork+0x1f/0x30
> [ 5.007544] Code: 48 8b 52 08 48 85 d2 74 0d 89 44 24 04 48 89 df ff d2 8b 44 24 04 48 89 df 89 44 24 04 e8 54 0a 1c 00 8b 44 24 0
> [ 5.007544] ---[ end trace 4dc4c3d5f5afcd2f ]---
> [ 5.244504] bdx_uncore: probe of 0000:ff:08.2 failed with error -22
> [ 5.251604] bdx_uncore: probe of 0000:ff:0b.1 failed with error -22
> [ 5.258711] bdx_uncore: probe of 0000:ff:10.1 failed with error -22
> [ 5.265819] bdx_uncore: probe of 0000:ff:14.0 failed with error -22
> [ 5.272919] bdx_uncore: probe of 0000:ff:14.1 failed with error -22
> [ 5.280019] bdx_uncore: probe of 0000:ff:15.0 failed with error -22
> [ 5.287112] bdx_uncore: probe of 0000:ff:15.1 failed with error -22
> [ 5.294376] WARNING: CPU: 1 PID: 15 at ../arch/x86/events/intel/uncore.c:1065 uncore_change_type_ctx.isra.5+0xe6/0xf0
> [ 5.298362] Modules linked in:
> [ 5.298362] CPU: 1 PID: 15 Comm: cpuhp/1 Tainted: G W 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.298362] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.298362] task: 00000000ae78bc8f task.stack: 00000000f79660c1
> [ 5.298362] RIP: 0010:uncore_change_type_ctx.isra.5+0xe6/0xf0
> [ 5.298362] RSP: 0000:ffffad85833b3db8 EFLAGS: 00010213
> [ 5.298362] RAX: 0000000000000000 RBX: ffff9857669b0200 RCX: 0000000000000001
> [ 5.298362] RDX: ffff985b6f000000 RSI: ffff985b66580400 RDI: ffffffffb0c1ae8c
> [ 5.298362] RBP: ffff985b66580400 R08: ffffffffb0c1ae8c R09: 0000000000000001
> [ 5.298362] R10: 0000000000000000 R11: 00000000003d0900 R12: 0000000000000000
> [ 5.298362] R13: ffffffffffffffff R14: 0000000000000001 R15: 0000000000000008
> [ 5.298362] FS: 0000000000000000(0000) GS:ffff985b6f000000(0000) knlGS:0000000000000000
> [ 5.298362] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.298362] CR2: 0000000000000000 CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.298362] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.298362] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.298362] Call Trace:
> [ 5.298362] uncore_event_cpu_online+0x283/0x340
> [ 5.298362] ? uncore_event_cpu_offline+0x180/0x180
> [ 5.298362] cpuhp_invoke_callback+0x8c/0x620
> [ 5.298362] ? __schedule+0x1ad/0x6c0
> [ 5.298362] ? sort_range+0x20/0x20
> [ 5.298362] cpuhp_thread_fun+0xbc/0x140
> [ 5.298362] smpboot_thread_fn+0x114/0x1d0
> [ 5.298362] kthread+0x111/0x130
> [ 5.298362] ? kthread_create_on_node+0x40/0x40
> [ 5.298362] ret_from_fork+0x1f/0x30
> [ 5.298362] Code: 2a 44 89 73 10 41 83 c4 01 48 81 c5 40 01 00 00 45 3b 20 7c cf 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f f
> [ 5.298362] ---[ end trace 4dc4c3d5f5afcd30 ]---
> [ 5.504808] Scanning for low memory corruption every 60 seconds
> [ 5.512347] Initialise system trusted keyrings
> [ 5.517470] workingset: timestamp_bits=40 max_order=23 bucket_order=0
> [ 5.524840] BUG: unable to handle kernel paging request at 0000000023314bf4
> [ 5.528761] IP: __kmalloc_track_caller+0xa8/0x210
> [ 5.528761] PGD 185c0a067 P4D 185c0a067 PUD 185c0c067 PMD 0
> [ 5.528761] Oops: 0000 [#1] PREEMPT SMP
> [ 5.528761] Modules linked in:
> [ 5.528761] CPU: 14 PID: 1 Comm: swapper/0 Tainted: G W 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.528761] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.528761] task: 000000009e842725 task.stack: 000000008a63fd2d
> [ 5.528761] RIP: 0010:__kmalloc_track_caller+0xa8/0x210
> [ 5.528761] RSP: 0000:ffffad8580163d58 EFLAGS: 00010286
> [ 5.528761] RAX: 0000000000000000 RBX: ffffffffffffffff RCX: 000000000012ce0e
> [ 5.528761] RDX: 000000000012cd0e RSI: 000000000012cd0e RDI: 000000000001dde0
> [ 5.528761] RBP: ffff985700000001 R08: ffff98576f407c00 R09: ffffffffb071edbf
> [ 5.528761] R10: ffffd54de1995600 R11: ffff985b6655915f R12: 0000000000000004
> [ 5.528761] R13: 00000000014000c0 R14: ffffffffb026c239 R15: ffff98576f407c00
> [ 5.528761] FS: 0000000000000000(0000) GS:ffff98576fb80000(0000) knlGS:0000000000000000
> [ 5.528761] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.528761] CR2: ffffffffffffffff CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.528761] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.528761] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.528761] Call Trace:
> [ 5.528761] kstrdup+0x2d/0x60
> [ 5.528761] __kernfs_new_node+0x29/0x130
> [ 5.528761] kernfs_new_node+0x24/0x50
> [ 5.528761] kernfs_create_link+0x29/0x90
> [ 5.528761] sysfs_do_create_link_sd.isra.0+0x5d/0xc0
> [ 5.528761] sysfs_slab_add+0x1f5/0x270
> [ 5.528761] ? set_debug_rodata+0x11/0x11
> [ 5.528761] slab_sysfs_init+0x8b/0xfa
> [ 5.528761] ? kmem_cache_init+0xf9/0xf9
> [ 5.528761] do_one_initcall+0x4b/0x190
> [ 5.528761] kernel_init_freeable+0x16e/0x1f5
> [ 5.528761] ? rest_init+0xd0/0xd0
> [ 5.528761] kernel_init+0xa/0x100
> [ 5.528761] ret_from_fork+0x1f/0x30
> [ 5.528761] Code: 49 63 47 20 49 8b 3f 48 8d 8a 00 01 00 00 48 8b 5c 05 00 48 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 ab 48 85 db 7
> [ 5.528761] RIP: __kmalloc_track_caller+0xa8/0x210 RSP: ffffad8580163d58
> [ 5.528761] CR2: ffffffffffffffff
> [ 5.528761] ---[ end trace 4dc4c3d5f5afcd31 ]---
> [ 5.773089] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [ 5.773089]
> [ 5.777076] Kernel Offset: 0x2f000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 5.777076] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
Yes, I'm getting that as well (v4.15-rc2-772-gcdc0974f10cf).
Did you bisect it? I haven't got around yet.
Björn
^ permalink raw reply
* [PATCH net] sock: free skb in skb_complete_tx_timestamp on error
From: Willem de Bruijn @ 2017-12-13 19:41 UTC (permalink / raw)
To: netdev; +Cc: richardcochran, davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
skb_complete_tx_timestamp must ingest the skb it is passed. Call
kfree_skb if the skb cannot be enqueued.
Fixes: b245be1f4db1 ("net-timestamp: no-payload only sysctl")
Fixes: 9ac25fc06375 ("net: fix socket refcounting in skb_complete_tx_timestamp()")
Reported-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/core/skbuff.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6b0ff396fa9d..a592ca025fc4 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4293,7 +4293,7 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
struct sock *sk = skb->sk;
if (!skb_may_tx_timestamp(sk, false))
- return;
+ goto err;
/* Take a reference to prevent skb_orphan() from freeing the socket,
* but only if the socket refcount is not zero.
@@ -4302,7 +4302,11 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
*skb_hwtstamps(skb) = *hwtstamps;
__skb_complete_tx_timestamp(skb, sk, SCM_TSTAMP_SND, false);
sock_put(sk);
+ return;
}
+
+err:
+ kfree_skb(skb);
}
EXPORT_SYMBOL_GPL(skb_complete_tx_timestamp);
--
2.15.1.504.g5279b80103-goog
^ permalink raw reply related
* Re: thunderx sgmii interface hang
From: Andrew Lunn @ 2017-12-13 19:43 UTC (permalink / raw)
To: Tim Harvey; +Cc: netdev, Sunil Goutham
In-Reply-To: <CAJ+vNU3UwuTrDqoDZNavEqSG_gs3=bpWRzmsp-ao3fsYvMoY2g@mail.gmail.com>
> The nic appears to work fine (pings, TCP etc) up until a performance
> test is attempted.
> When an iperf bandwidth test is attempted the nic ends up in a state
> where truncated-ip packets are being sent out (per a tcpdump from
> another board):
Hi Tim
Are pause frames supported? Have you tried turning them off?
Can you reproduce the issue with UDP? Or is it TCP only?
Andrew
^ permalink raw reply
* Re: [PATCH v2 0/3] r8169: extend PCI core and switch to device-managed functions in probe
From: David Miller @ 2017-12-13 19:52 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, bhelgaas, netdev, linux-pci
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 12 Dec 2017 07:34:26 +0100
> Probe error path and remove callback can be significantly simplified
> by using device-managed functions. To be able to do this in the r8169
> driver we need a device-managed version of pci_set_mwi first.
>
> v2:
> Change patch 1 based on Björn's review comments and add his Acked-by.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
From: David Miller @ 2017-12-13 19:53 UTC (permalink / raw)
To: baijiaju1990; +Cc: jes, jes, netdev, linux-kernel
In-Reply-To: <1513068592-23632-1-git-send-email-baijiaju1990@163.com>
From: Jia-Ju Bai <baijiaju1990@163.com>
Date: Tue, 12 Dec 2017 16:49:52 +0800
> The driver may sleep under a spinlock.
> The function call path is:
> rr_close (acquire the spinlock)
> free_irq --> may sleep
>
> To fix it, free_irq is moved to the place without holding the spinlock.
>
> This bug is found by my static analysis tool(DSAC) and checked by my code review.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Applied.
^ permalink raw reply
* [patch iproute2] tc: fix json array closing
From: Jiri Pirko @ 2017-12-13 19:56 UTC (permalink / raw)
To: netdev; +Cc: stephen
From: Jiri Pirko <jiri@mellanox.com>
Fixes: 2704bd625583 ("tc: jsonify actions core")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
tc/m_action.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tc/m_action.c b/tc/m_action.c
index 13f942b..8185819 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -378,7 +378,7 @@ tc_print_action(FILE *f, const struct rtattr *arg, unsigned short tot_acts)
}
}
- close_json_object();
+ close_json_array(PRINT_JSON, NULL);
return 0;
}
--
2.9.5
^ permalink raw reply related
* Re: x86 boot broken on -rc1?
From: Jakub Kicinski @ 2017-12-13 19:58 UTC (permalink / raw)
To: Björn Töpel; +Cc: LKML, netdev@vger.kernel.org
In-Reply-To: <CAJ+HfNicp5rKpUmx9_Y8FZDd73Ob9uquG0P7sY1nGDCY8p0NNw@mail.gmail.com>
On Wed, 13 Dec 2017 20:37:02 +0100, Björn Töpel wrote:
> 2017-12-02 1:39 GMT+01:00 Jakub Kicinski:
> > [ 5.777076] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
>
> Yes, I'm getting that as well (v4.15-rc2-772-gcdc0974f10cf).
>
> Did you bisect it? I haven't got around yet.
Yup, it's fixed but I'm not sure who far it trickled down the various
trees:
947134d9b00f ("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages calculation")
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: allow XAUI phy interface mode
From: David Miller @ 2017-12-13 19:59 UTC (permalink / raw)
To: rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stefan-XLVq0VzYD2Y,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/
In-Reply-To: <E1eOgsk-0001AU-5z-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
From: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Date: Tue, 12 Dec 2017 09:29:46 +0000
> XGMII is a 32-bit bus plus two clock signals per direction. XAUI is
> four serial lanes per direction. The 88e6190 supports XAUI but not
> XGMII as it doesn't have enough pins. The same is true of 88e6176.
>
> Match on PHY_INTERFACE_MODE_XAUI for the XAUI port type, but keep
> accepting XGMII for backwards compatibility.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: vf610-zii-dev: use XAUI for DSA link ports
From: David Miller @ 2017-12-13 19:59 UTC (permalink / raw)
To: rmk+kernel
Cc: andrew, f.fainelli, devicetree, linux-arm-kernel, mark.rutland,
netdev, robh+dt, kernel, shawnguo, stefan, vivien.didelot
In-Reply-To: <E1eOgsp-0001Ab-9x@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 09:29:51 +0000
> Use XAUI rather than XGMII for DSA link ports, as this is the interface
> mode that the switches actually use. XAUI is the 4 lane bus with clock
> per direction, whereas XGMII is a 32 bit bus with clock.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> This must be applied along with patch 1 to avoid breakage.
Applied.
^ permalink raw reply
* Re: [PATCH net] net: phy: fix resume handling
From: David Miller @ 2017-12-13 20:00 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1eOi48-0002N2-QC@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 10:45:36 +0000
> When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes
> to other registers, or reset the registers to power-on defaults.
> Micrel PHYs do this for their interrupt registers.
>
> The current structure of phylib tries to enable interrupts before
> resuming (and releasing) the BMCR_PDOWN bit. This fails, causing
> Micrel PHYs to stop working after a suspend/resume sequence if they
> are using interrupts.
>
> Fix this by ensuring that the PHY driver resume methods do not take
> the phydev->lock mutex themselves, but the callers of phy_resume()
> take that lock. This then allows us to move the call to phy_resume()
> before we enable interrupts in phy_start().
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH] of_mdio / mdiobus: ensure mdio devices have fwnode correctly populated
From: David Miller @ 2017-12-13 20:02 UTC (permalink / raw)
To: rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <E1eOi7f-0002Rs-K7-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
From: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Date: Tue, 12 Dec 2017 10:49:15 +0000
> Ensure that all mdio devices populate the struct device fwnode pointer
> as well as the of_node pointer to allow drivers that wish to use
> fwnode APIs to work.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] net: phy: marvell10g: remove XGMII as an option for 88x3310
From: David Miller @ 2017-12-13 20:05 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1eOk3i-00010j-0V@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 12:53:18 +0000
> Remove XGMII as an option for the 88x3310 PHY driver, as the PHY doesn't
> support XGMII's 32-bit data lanes. It supports USXGMII, which is not
> XGMII, but a single-lane serdes interface - see
> https://developer.cisco.com/site/usgmii-usxgmii/
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH][next] net: phy: meson-gxl: make function meson_gxl_read_status static
From: David Miller @ 2017-12-13 20:05 UTC (permalink / raw)
To: colin.king
Cc: andrew, f.fainelli, carlo, khilman, netdev, linux-arm-kernel,
linux-amlogic, kernel-janitors, linux-kernel
In-Reply-To: <20171212130311.17185-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 12 Dec 2017 13:03:11 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> The function meson_gxl_read_status is local to the source and does
> not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol 'meson_gxl_read_status' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH] reuseport: compute the ehash only if needed
From: David Miller @ 2017-12-13 20:08 UTC (permalink / raw)
To: pabeni; +Cc: netdev, kraig, edumazet
In-Reply-To: <af8a2d2c27b6f91ca7a7c65ac375ce2ba7aa4764.1513084090.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Tue, 12 Dec 2017 14:09:28 +0100
> When a reuseport socket group is using a BPF filter to distribute
> the packets among the sockets, we don't need to compute any hash
> value, but the current reuseport_select_sock() requires the
> caller to compute such hash in advance.
>
> This patch reworks reuseport_select_sock() to compute the hash value
> only if needed - missing or failing BPF filter. Since different
> hash functions have different argument types - ipv4 addresses vs ipv6
> ones - to avoid over-complicate the interface, reuseport_select_sock()
> is now a macro.
>
> Additionally, the sk_reuseport test is move inside reuseport_select_sock,
> to avoid some code duplication.
>
> Overall this gives small but measurable performance improvement
> under UDP flood while using SO_REUSEPORT + BPF.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
I don't doubt that this improves the case where the hash is elided, but
I suspect it makes things slower othewise.
You're doing two function calls for an operation that used to require
just one in the bottom of the call chain.
You're also putting something onto the stack that the compiler can't
possibly optimize into purely using cpu registers to hold.
^ permalink raw reply
* Re: [PATCH net-next v2] ip6_vti: adjust vti mtu according to mtu of output device
From: David Miller @ 2017-12-13 20:09 UTC (permalink / raw)
To: alexey.kodanev; +Cc: netdev, steffen.klassert, pvorel, shannon.nelson
In-Reply-To: <1513086812-24896-1-git-send-email-alexey.kodanev@oracle.com>
From: Alexey Kodanev <alexey.kodanev@oracle.com>
Date: Tue, 12 Dec 2017 16:53:32 +0300
> + if (tdev) {
> + dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len,
> + IPV6_MIN_MTU);
> + }
Please don't use curly braces for a single-statement basic block.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: bridge: use rhashtable for fdbs
From: David Miller @ 2017-12-13 20:10 UTC (permalink / raw)
To: nikolay; +Cc: netdev, bridge, roopa, stephen, srn
In-Reply-To: <1513087370-4791-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Tue, 12 Dec 2017 16:02:50 +0200
> Before this patch the bridge used a fixed 256 element hash table which
> was fine for small use cases (in my tests it starts to degrade
> above 1000 entries), but it wasn't enough for medium or large
> scale deployments. Modern setups have thousands of participants in a
> single bridge, even only enabling vlans and adding a few thousand vlan
> entries will cause a few thousand fdbs to be automatically inserted per
> participating port. So we need to scale the fdb table considerably to
> cope with modern workloads, and this patch converts it to use a
> rhashtable for its operations thus improving the bridge scalability.
> Tests show the following results (10 runs each), at up to 1000 entries
> rhashtable is ~3% slower, at 2000 rhashtable is 30% faster, at 3000 it
> is 2 times faster and at 30000 it is 50 times faster.
> Obviously this happens because of the properties of the two constructs
> and is expected, rhashtable keeps pretty much a constant time even with
> 10000000 entries (tested), while the fixed hash table struggles
> considerably even above 10000.
> As a side effect this also reduces the net_bridge struct size from 3248
> bytes to 1344 bytes. Also note that the key struct is 8 bytes.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> After this I'll post patches for the per-port fdb limit option. Later we
> can get rid of hash_lock altogether though that requires much more
> careful changes.
Nice work Nikolay, applied, thanks!
^ permalink raw reply
* Re: [PATCH net] sock: free skb in skb_complete_tx_timestamp on error
From: Eric Dumazet @ 2017-12-13 20:10 UTC (permalink / raw)
To: Willem de Bruijn, netdev; +Cc: richardcochran, davem, Willem de Bruijn
In-Reply-To: <20171213194106.128322-1-willemdebruijn.kernel@gmail.com>
On Wed, 2017-12-13 at 14:41 -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> skb_complete_tx_timestamp must ingest the skb it is passed. Call
> kfree_skb if the skb cannot be enqueued.
>
> Fixes: b245be1f4db1 ("net-timestamp: no-payload only sysctl")
> Fixes: 9ac25fc06375 ("net: fix socket refcounting in skb_complete_tx_timestamp()")
> Reported-by: Richard Cochran <richardcochran@gmail.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH 1/3] net: phy: add support to detect 100BASE-T1 capability
From: Andrew Lunn @ 2017-12-13 20:11 UTC (permalink / raw)
To: Lucas Stach; +Cc: Florian Fainelli, netdev, kernel, patchwork-lst
In-Reply-To: <20171213173751.12722-1-l.stach@pengutronix.de>
On Wed, Dec 13, 2017 at 06:37:49PM +0100, Lucas Stach wrote:
> 100BASE-T1 is the automotive ethernet standard 802.3bw-2015. Currently
> we don't detect any valid modes for PHYs, which only support this
> standard. Add support to detect the common 100Mbit full-duplex mode.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/net/phy/phy_device.c | 2 ++
> include/uapi/linux/mii.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 67f25ac29025..8ef48b38d97b 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1607,6 +1607,8 @@ int genphy_config_init(struct phy_device *phydev)
> if (val < 0)
> return val;
>
> + if (val & ESTATUS_100T1_FULL)
> + features |= SUPPORTED_100baseT_Full;
Hi Lucas
Why did you decide to do this, and not add a SUPPORTED_100baseT1?
Could a device support both 100-BASE-T and 100-BASE-T1? If at some
point we need to differentiate between them, it is going to be
hard. Especially since this is part of the kernel ABI.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: sk_pacing_shift_update() helper
From: David Miller @ 2017-12-13 20:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: nbd, netdev, johannes.berg, toke, kir
In-Reply-To: <1513089259.25033.51.camel@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Dec 2017 06:34:19 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In commit 3a9b76fd0db9 ("tcp: allow drivers to tweak TSQ logic")
> I gave a code sample to set sk->sk_pacing_shift that was not complete.
>
> Better add a helper that can be used by drivers without worries,
> and maybe amended in the future.
>
> A wifi driver might use it from its ndo_start_xmit()
>
> Following call would setup TCP to allow up to ~8ms of queued data per
> flow.
>
> sk_pacing_shift_update(skb->sk, 7);
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] net: avoid skb_warn_bad_offload on IS_ERR
From: David Miller @ 2017-12-13 20:14 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, edumazet, willemb
In-Reply-To: <20171212163904.209480-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Tue, 12 Dec 2017 11:39:04 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> skb_warn_bad_offload warns when packets enter the GSO stack that
> require skb_checksum_help or vice versa. Do not warn on arbitrary
> bad packets. Packet sockets can craft many. Syzkaller was able to
> demonstrate another one with eth_type games.
>
> In particular, suppress the warning when segmentation returns an
> error, which is for reasons other than checksum offload.
>
> See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
> called on skb requiring segmentation") for context on this warning.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks Willem.
^ permalink raw reply
* Re: [PATCH iproute2] Show 'external' link mode in output
From: Stephen Hemminger @ 2017-12-13 20:15 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: netdev, phild
In-Reply-To: <20171212202319.GA7066@ipom.com>
On Tue, 12 Dec 2017 12:23:19 -0800
Phil Dibowitz <phil@ipom.com> wrote:
> Recently `external` support was added to the tunnel drivers, but there is no way
> to introspect this from userspace. This adds support for that.
>
> Now `ip -details link` shows it:
>
> ```
> 7: tunl60@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group
> default qlen 1
> link/tunnel6 :: brd :: promiscuity 0
> ip6tnl external any remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000) addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> ```
>
> Signed-off-by: Phil Dibowitz <phil@ipom.com>
Applied, thanks.
^ 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