* Re: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control
From: David Miller @ 2018-11-17 3:42 UTC (permalink / raw)
To: madalin.bucur
Cc: netdev, roy.pledge, linux-kernel, leoyang.li, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1542126591-5114-3-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Tue, 13 Nov 2018 18:29:51 +0200
> + for_each_cpu(cpu, cpus) {
> + portal = qman_get_affine_portal(cpu);
> + res = qman_portal_set_iperiod(portal, period);
> + if (res)
> + return res;
> + res = qman_dqrr_set_ithresh(portal, thresh);
> + if (res)
> + return res;
Nope, you can't do it like this.
If any intermediate change fails, you have to unwind all of the
changes made up until that point.
Which means you'll have to store the previous setting somewhere
and reinstall those saved values in the error path.
^ permalink raw reply
* Re: [PATCH] net/decnet: add missing indentation
From: David Miller @ 2018-11-17 3:43 UTC (permalink / raw)
To: colin.king; +Cc: linux-decnet-user, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20181113141817.6189-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 13 Nov 2018 14:18:17 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a missing indentation before the declaration of port. Add
> it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 0/4] bpf: allow zero-initialising hash map seed
From: Song Liu @ 2018-11-16 17:33 UTC (permalink / raw)
To: Lorenz Bauer
Cc: Alexei Starovoitov, Daniel Borkmann, netdev@vger.kernel.org,
linux-api@vger.kernel.org
In-Reply-To: <20181116114111.31177-1-lmb@cloudflare.com>
> On Nov 16, 2018, at 3:41 AM, Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> Allow forcing the seed of a hash table to zero, for deterministic
> execution during benchmarking and testing.
>
> Changes from v2:
> * Change ordering of BPF_F_ZERO_SEED in linux/bpf.h
>
> Comments adressed from v1:
> * Add comment to discourage production use to linux/bpf.h
> * Require CAP_SYS_ADMIN
>
> Lorenz Bauer (4):
> bpf: allow zero-initializing hash map seed
> bpf: move BPF_F_QUERY_EFFECTIVE after map flags
> tools: sync linux/bpf.h
> tools: add selftest for BPF_F_ZERO_SEED
>
> include/uapi/linux/bpf.h | 9 ++--
> kernel/bpf/hashtab.c | 13 ++++-
> tools/include/uapi/linux/bpf.h | 13 +++--
> tools/testing/selftests/bpf/test_maps.c | 68 +++++++++++++++++++++----
> 4 files changed, 84 insertions(+), 19 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] net: lantiq: Fix returned value in case of error in 'xrx200_probe()'
From: David Miller @ 2018-11-17 3:47 UTC (permalink / raw)
To: christophe.jaillet; +Cc: hauke, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20181113174224.7884-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Tue, 13 Nov 2018 18:42:24 +0100
> Return 'err' in the error handling path instead of 0.
> Return explicitly 0 in the normal path, instead of 'err', which is known
> to be 0 at this point.
>
> Fixes: fe1a56420cf2 ("net: lantiq: Add Lantiq / Intel VRX200 Ethernet driver")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied.
^ permalink raw reply
* Re: [PATCH v3 0/4] bpf: allow zero-initialising hash map seed
From: Song Liu @ 2018-11-16 17:34 UTC (permalink / raw)
To: Lorenz Bauer
Cc: ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org,
linux-api@vger.kernel.org
In-Reply-To: <20181116114111.31177-1-lmb@cloudflare.com>
> On Nov 16, 2018, at 3:41 AM, Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> Allow forcing the seed of a hash table to zero, for deterministic
> execution during benchmarking and testing.
>
> Changes from v2:
> * Change ordering of BPF_F_ZERO_SEED in linux/bpf.h
>
> Comments adressed from v1:
> * Add comment to discourage production use to linux/bpf.h
> * Require CAP_SYS_ADMIN
>
> Lorenz Bauer (4):
> bpf: allow zero-initializing hash map seed
> bpf: move BPF_F_QUERY_EFFECTIVE after map flags
> tools: sync linux/bpf.h
> tools: add selftest for BPF_F_ZERO_SEED
>
> include/uapi/linux/bpf.h | 9 ++--
> kernel/bpf/hashtab.c | 13 ++++-
> tools/include/uapi/linux/bpf.h | 13 +++--
> tools/testing/selftests/bpf/test_maps.c | 68 +++++++++++++++++++++----
> 4 files changed, 84 insertions(+), 19 deletions(-)
>
> --
> 2.17.1
>
For the series:
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH v2] net: phy: mdio-gpio: fix access that may sleep
From: David Miller @ 2018-11-17 3:52 UTC (permalink / raw)
To: ms; +Cc: netdev, linux-kernel, andrew, f.fainelli
In-Reply-To: <20181114063703.13379-1-ms@dev.tdt.de>
From: Martin Schiller <ms@dev.tdt.de>
Date: Wed, 14 Nov 2018 07:37:03 +0100
> @@ -162,6 +162,11 @@ static int mdio_gpio_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + if (gpiod_cansleep(bitbang->mdc) || gpiod_cansleep(bitbang->mdio)
> + || gpiod_cansleep(bitbang->mdo))
Please fix the formatting here, operators like "||" and "&&" never begin
a line, they must always finish a line.
^ permalink raw reply
* Re: [PATCH v4] net: phy: mdio-gpio: Fix working over slow can_sleep GPIOs
From: David Miller @ 2018-11-17 4:25 UTC (permalink / raw)
To: ms; +Cc: andrew, sergei.shtylyov, f.fainelli, netdev, linux-kernel
In-Reply-To: <20181114115449.28332-1-ms@dev.tdt.de>
From: Martin Schiller <ms@dev.tdt.de>
Date: Wed, 14 Nov 2018 12:54:49 +0100
> This commit re-enables support for slow GPIO pins. It was initially
> introduced by commit 2d6c9091ab76 ("net: mdio-gpio: support access that
> may sleep") and got lost by commit 7e5fbd1e0700 ("net: mdio-gpio:
> Convert to use gpiod functions where possible").
>
> Also add a warning about slow GPIO pins like it is done in i2c-gpio.
>
> Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: clean up STATE_TRACE
From: David Miller @ 2018-11-17 4:28 UTC (permalink / raw)
To: laoar.shao; +Cc: edumazet, netdev, linux-kernel
In-Reply-To: <1542205577-21925-1-git-send-email-laoar.shao@gmail.com>
From: Yafang Shao <laoar.shao@gmail.com>
Date: Wed, 14 Nov 2018 22:26:17 +0800
> Currently we can use bpf or tcp tracepoint to conveniently trace the tcp
> state transition at the run time.
> So we don't need to do this stuff at the compile time anymore.
>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH V3 2/7] net: lorawan: Add LoRaWAN socket module
From: David Miller @ 2018-11-17 4:32 UTC (permalink / raw)
To: starnight
Cc: afaerber, netdev, linux-arm-kernel, linux-kernel, marcel,
dollar.chen, ken.yu, linux-wpan, stefan
In-Reply-To: <20181114160126.4445-3-starnight@g.ncu.edu.tw>
From: Jian-Hong Pan <starnight@g.ncu.edu.tw>
Date: Thu, 15 Nov 2018 00:01:23 +0800
> +#define lrw_get_mac_cb(skb) ((struct lrw_mac_cb *)skb->cb)
Please make this a static inline function. If the identifier is all lowercase
programmers expect it to be real code not a CPP macro.
> +#define LORAWAN_MODULE_NAME "lorawan"
> +
> +#define LRW_DBG_STR(fmt) LORAWAN_MODULE_NAME": "fmt
> +#define lrw_info(fmt, ...) (pr_info(LRW_DBG_STR(fmt), ##__VA_ARGS__))
> +#define lrw_dbg(fmt, ...) (pr_debug(LRW_DBG_STR(fmt), ##__VA_ARGS__))
Just define "pr_fmt()" appropriately and you don't need to play these kinds
of games.
Set pr_fmt() and call pr_info() and pr_debug() directly.
^ permalink raw reply
* Re: [PATCH V3 4/7] net: maclorawan: Add maclorawan module declaration
From: David Miller @ 2018-11-17 4:32 UTC (permalink / raw)
To: starnight
Cc: afaerber, netdev, linux-arm-kernel, linux-kernel, marcel,
dollar.chen, ken.yu, linux-wpan, stefan
In-Reply-To: <20181114160126.4445-5-starnight@g.ncu.edu.tw>
From: Jian-Hong Pan <starnight@g.ncu.edu.tw>
Date: Thu, 15 Nov 2018 00:01:25 +0800
> + * @rx1_window: RX1 window opening time in mini-seconds
> + * @rx2_window: RX2 window opening time in mini-seconds
What is a "mini-second"?
^ permalink raw reply
* Linux kernel hangs if using RV1108 with MSZ8863 switch with two ports connected
From: Otavio Salvador @ 2018-11-16 18:28 UTC (permalink / raw)
To: netdev, andrew, Heiko Stuebner, david.choi, Andy Yan
Hi,
I have a custom design based on Rockchip RV1108 that uses an MSZ8863
switch running kernel 4.19.
The dts part is as follows:
&gmac {
pinctrl-names = "default";
pinctrl-0 = <&rmii_pins>;
snps,reset-gpio = <&gpio1 RK_PC1 GPIO_ACTIVE_LOW>;
snps,reset-active-low;
clock_in_out = "output";
status = "okay";
};
RV1108 GMAC is connected to KSZ8863 port 3 and after kernel boots, I
can put an Ethernet cable from my router to the uplink port of
KSZ8863, which makes the RV1108 board and a Linux PC connected to the
other KSZ8863 port to both get IP addresses.
So in this usecase the setup is working fine.
However, if the RV1108 board boots with both Ethernet cables to the
KSZ8863 switch connected, then the kernel silently hangs.
Any suggestions as to what I should do in order to avoid the kernel to
hang with the two Ethernet cables connected?
The system boots fine without any Ethernet cable connected or with
only one Ethernet cable connected.
Here is the log of the system booting with no Ethernet cable connected:
http://dark-code.bulix.org/9kfff9-506410
It is only when both cables are connected that the kernel silently hangs.
Also, with the vendor 3.10 kernel such hang does not happen.
Thanks
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* Re: [PATCH v2 net-next 06/21] net: usb: aqc111: Introduce link management
From: Andrew Lunn @ 2018-11-16 18:33 UTC (permalink / raw)
To: Igor Russkikh
Cc: Florian Fainelli, David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <86b4d1bc-b0e5-5a64-0176-aba0c7fad037@aquantia.com>
> Production dongles will always have firmware fully controlling all the phy.
> Thus, I think in next series we'll just cut off all the direct phy
> access code.
O.K, but that is also a shame. The PHY i have has all sorts of nice
things, MACSEC, temperature sensors, PTP, cable tests logic,
etc. Without having a proper PHY driver which can access the
registers, a lot of that is going to be very hard to use.
Andrew
^ permalink raw reply
* Re: [PATCH][bpf-next] bpf: fix null pointer dereference on pointer offload
From: Alexei Starovoitov @ 2018-11-17 4:49 UTC (permalink / raw)
To: Colin King
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20181113092926.27081-1-colin.king@canonical.com>
On Tue, Nov 13, 2018 at 09:29:26AM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Pointer offload is being null checked however the following statement
> dereferences the potentially null pointer offload when assigning
> offload->dev_state. Fix this by only assigning it if offload is not
> null.
>
> Detected by CoverityScan, CID#1475437 ("Dereference after null check")
>
> Fixes: 00db12c3d141 ("bpf: call verifier_prep from its callback in struct bpf_offload_dev")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, Thanks
^ permalink raw reply
* Re: [PATCH net-next 6/8] net: eth: altera: tse: add support for ptp and timestamping
From: Richard Cochran @ 2018-11-16 18:37 UTC (permalink / raw)
To: Dalon Westergreen; +Cc: netdev, dinguyen, thor.thayer
In-Reply-To: <582af4ec1617d6da37150f0e1963104d974f2742.camel@gmail.com>
On Fri, Nov 16, 2018 at 06:48:15AM -0800, Dalon Westergreen wrote:
> For naming, how about intel_fpga_tod ?
Fine by me.
Thanks,
Richard
^ permalink raw reply
* Re: [BUG] xfrm: unable to handle kernel NULL pointer dereference
From: Lennert Buytenhek @ 2018-11-16 18:48 UTC (permalink / raw)
To: steffen.klassert, herbert
Cc: Jean-Philippe Menil, davem, netdev, kuznet, yoshfuji
In-Reply-To: <ccf5c987-fe17-0465-0f4a-fdac984c25ab@gmail.com>
On Sat, Nov 10, 2018 at 08:34:34PM +0100, Jean-Philippe Menil wrote:
> we're seeing unexpected crashes from kernel 4.15 to 4.18.17, using
> IPsec VTI interfaces, on several vpn hosts, since upgrade from 4.4.
I looked into this with Jean-Philippe, and it appears to be crashing
on a NULL pointer dereference in the inlined xfrm_policy_check() call
in vti_rcv_cb(), and specifically on the skb_dst(skb) dereference in
__xfrm_policy_check2():
return (!net->xfrm.policy_count[dir] && !skb->sp) ||
(skb_dst(skb)->flags & DST_NOPOLICY) || <=====
__xfrm_policy_check(sk, ndir, skb, family);
Commit 9e1437937807 ("xfrm: Fix NULL pointer dereference when
skb_dst_force clears the dst_entry.") fixes a very similar problem on
the output and forward paths, but our issue seems to be triggering on
the input path.
This hack patch seems to make the crashes go away, and the printk added
triggers with approximately the same regularity as the crashes used
to occur, so the fix from 9e1437937807 probably needs to be extended
to the input path somewhat like this.
Thanks!
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 352abca2605f..c666e29441b4 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -381,6 +381,12 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
XFRM_SKB_CB(skb)->seq.input.hi = seq_hi;
skb_dst_force(skb);
+ if (!skb_dst(skb)) {
+ if (net_ratelimit())
+ printk(KERN_CRIT "OH CRAP\n");
+ goto drop;
+ }
+
dev_hold(skb->dev);
if (crypto_done)
> Attached, the offended oops against 4.18.
>
> Output of decodedecode:
>
> [ 37.134864] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00
> 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe <f6> 40
> 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20
> All code
> ========
> 0: 8b 44 24 70 mov 0x70(%rsp),%eax
> 4: 0f c8 bswap %eax
> 6: 89 87 b4 00 00 00 mov %eax,0xb4(%rdi)
> c: 48 8b 86 20 05 00 00 mov 0x520(%rsi),%rax
> 13: 8b 80 f8 14 00 00 mov 0x14f8(%rax),%eax
> 19: 85 c0 test %eax,%eax
> 1b: 75 05 jne 0x22
> 1d: 48 85 d2 test %rdx,%rdx
> 20: 74 0e je 0x30
> 22: 48 8b 43 58 mov 0x58(%rbx),%rax
> 26: 48 83 e0 fe and $0xfffffffffffffffe,%rax
> 2a:* f6 40 38 04 testb $0x4,0x38(%rax) <-- trapping
> instruction
> 2e: 74 7d je 0xad
> 30: 44 89 b3 b4 00 00 00 mov %r14d,0xb4(%rbx)
> 37: 49 8b 44 24 20 mov 0x20(%r12),%rax
> 3c: 48 rex.W
> 3d: 39 .byte 0x39
> 3e: 86 20 xchg %ah,(%rax)
>
> Code starting with the faulting instruction
> ===========================================
> 0: f6 40 38 04 testb $0x4,0x38(%rax)
> 4: 74 7d je 0x83
> 6: 44 89 b3 b4 00 00 00 mov %r14d,0xb4(%rbx)
> d: 49 8b 44 24 20 mov 0x20(%r12),%rax
> 12: 48 rex.W
> 13: 39 .byte 0x39
> 14: 86 20 xchg %ah,(%rax)
>
>
> if my understanding is correct, we fail here:
>
> /build/linux-hwe-edge-yHKLQJ/linux-hwe-edge-4.18.0/include/net/xfrm.h:
> 1169 return (!net->xfrm.policy_count[dir] && !skb->sp) ||
> 0x0000000000000b19 <+185>: testb $0x4,0x38(%rax)
> 0x0000000000000b1d <+189>: je 0xb9c <vti_rcv_cb+316>
>
> (gdb) list *0x0000000000000b19
> 0xb19 is in vti_rcv_cb
> (/build/linux-hwe-edge-yHKLQJ/linux-hwe-edge-4.18.0/include/net/xfrm.h:1169).
> 1164 int ndir = dir | (reverse ? XFRM_POLICY_MASK + 1 : 0);
> 1165
> 1166 if (sk && sk->sk_policy[XFRM_POLICY_IN])
> 1167 return __xfrm_policy_check(sk, ndir, skb, family);
> 1168
> 1169 return (!net->xfrm.policy_count[dir] && !skb->sp) ||
> 1170 (skb_dst(skb)->flags & DST_NOPOLICY) ||
> 1171 __xfrm_policy_check(sk, ndir, skb, family);
> 1172 }
> 1173
>
> I really have hard time to understand why skb seem to be freed twice.
>
> I'm not able to repeat the bug in lab, but it happened regulary in prod,
> seem to depend of the workload.
>
> Any help will be appreciated.
>
> Let me know if you need further informations.
>
> Regards,
>
> Jean-Philippe
> [ 31.154360] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> [ 31.162233] PGD 0 P4D 0
> [ 31.164786] Oops: 0000 [#1] SMP PTI
> [ 31.168291] CPU: 5 PID: 42 Comm: ksoftirqd/5 Not tainted 4.18.0-11-generic #12~18.04.1-Ubuntu
> [ 31.176854] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016
> [ 31.184980] RIP: 0010:vti_rcv_cb+0xb9/0x1a0 [ip_vti]
> [ 31.189962] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe <f6> 40 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20
> [ 31.208916] RSP: 0018:ffffbc61832e3920 EFLAGS: 00010246
> [ 31.214160] RAX: 0000000000000000 RBX: ffff9a3504964a00 RCX: 0000000000000002
> [ 31.221328] RDX: ffff9a351add4080 RSI: ffff9a351aa08000 RDI: ffff9a3504964a00
> [ 31.228485] RBP: ffffbc61832e3940 R08: 0000000000000004 R09: ffffffffc0aa612b
> [ 31.235643] R10: 0008f09b99881884 R11: 1884bd4e2d6b1fac R12: ffff9a3507b31900
> [ 31.242803] R13: ffff9a3507b31000 R14: 0000000000000000 R15: ffff9a3504964a00
> [ 31.249964] FS: 0000000000000000(0000) GS:ffff9a35bfd40000(0000) knlGS:0000000000000000
> [ 31.258077] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 31.263848] CR2: 0000000000000038 CR3: 000000041a40a003 CR4: 00000000003606e0
> [ 31.271004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 31.278163] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 31.285320] Call Trace:
> [ 31.287789] xfrm4_rcv_cb+0x4a/0x70
> [ 31.291297] xfrm_input+0x58f/0x8f0
> [ 31.294807] vti_input+0xaa/0x110 [ip_vti]
> [ 31.298926] vti_rcv+0x33/0x3c [ip_vti]
> [ 31.302783] xfrm4_esp_rcv+0x39/0x50
> [ 31.306375] ip_local_deliver_finish+0x62/0x200
> [ 31.310923] ip_local_deliver+0xdf/0xf0
> [ 31.314775] ? ip_rcv_finish+0x420/0x420
> [ 31.318718] ip_rcv_finish+0x126/0x420
> [ 31.322486] ip_rcv+0x28f/0x360
> [ 31.325655] ? inet_del_offload+0x40/0x40
> [ 31.329686] __netif_receive_skb_core+0x48c/0xb70
> [ 31.334413] ? kmem_cache_alloc+0xb4/0x1d0
> [ 31.338532] ? __build_skb+0x2b/0xf0
> [ 31.342128] __netif_receive_skb+0x18/0x60
> [ 31.346244] ? __netif_receive_skb+0x18/0x60
> [ 31.350536] netif_receive_skb_internal+0x45/0xe0
> [ 31.355263] napi_gro_receive+0xc5/0xf0
> [ 31.359141] mlx5e_handle_rx_cqe+0x1b2/0x5d0 [mlx5_core]
> [ 31.364476] ? skb_release_all+0x24/0x30
> [ 31.368430] mlx5e_poll_rx_cq+0xd3/0x990 [mlx5_core]
> [ 31.373432] mlx5e_napi_poll+0x9b/0xc60 [mlx5_core]
> [ 31.378333] ? __switch_to_asm+0x34/0x70
> [ 31.382270] ? __switch_to_asm+0x40/0x70
> [ 31.386214] ? __switch_to_asm+0x34/0x70
> [ 31.391056] ? __switch_to_asm+0x40/0x70
> [ 31.395905] ? __switch_to_asm+0x34/0x70
> [ 31.400743] net_rx_action+0x140/0x3a0
> [ 31.405379] ? __switch_to+0xad/0x500
> [ 31.409887] __do_softirq+0xe4/0x2bb
> [ 31.414448] run_ksoftirqd+0x2b/0x40
> [ 31.418862] smpboot_thread_fn+0xfc/0x170
> [ 31.423700] kthread+0x121/0x140
> [ 31.427701] ? sort_range+0x30/0x30
> [ 31.432040] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 31.437816] ret_from_fork+0x35/0x40
> [ 31.442219] Modules linked in: esp6 authenc echainiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo ip_vti ip_tunnel ip6_vti ip6_tunnel tunnel6 8021q garp mrp stp llc bonding ipt_REJECT nf_reject_ipv4 nfnetlink_log n
> fnetlink xt_NFLOG xt_hl xt_limit xt_nat xt_TCPMSS xt_HL xt_comment xt_tcpudp xt_multiport xt_conntrack iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_connmark xt_mark iptable_mangle xt_CT nf_conntrack xt_addrtype iptable_raw bpfilter ipmi_ssif gpio_
> ich intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf input_leds joydev mei_me intel_pch_thermal ioatdma mei lpc_ich ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mac_hid sch_fq_codel
> [ 31.519488] ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0 multipath linear mlx5_ib ib_uverbs ib
> _core raid1 hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ast pcbc ttm drm_kms_helper aesni_intel syscopyarea aes_x86_64 sysfillrect mxm_wmi crypto_simd sysimgblt cryptd glue_helper fb_sys_fops mlx5_core ixgbe igb mpt3sas drm ahci tls libahci i2c_algo_bit m
> lxfw raid_class dca devlink mdio scsi_transport_sas wmi
> [ 31.578877] CR2: 0000000000000038
> [ 31.583249] ---[ end trace c4bada38847a0075 ]---
> [ 31.737166] RIP: 0010:vti_rcv_cb+0xb9/0x1a0 [ip_vti]
> [ 31.737167] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe <f6> 40 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20
> [ 31.737209] RSP: 0018:ffffbc61832e3920 EFLAGS: 00010246
> [ 31.737212] RAX: 0000000000000000 RBX: ffff9a3504964a00 RCX: 0000000000000002
> [ 31.737213] RDX: ffff9a351add4080 RSI: ffff9a351aa08000 RDI: ffff9a3504964a00
> [ 31.737216] RBP: ffffbc61832e3940 R08: 0000000000000004 R09: ffffffffc0aa612b
> [ 31.737219] R10: 0008f09b99881884 R11: 1884bd4e2d6b1fac R12: ffff9a3507b31900
> [ 31.737220] R13: ffff9a3507b31000 R14: 0000000000000000 R15: ffff9a3504964a00
> [ 31.737222] FS: 0000000000000000(0000) GS:ffff9a35bfd40000(0000) knlGS:0000000000000000
> [ 31.737224] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 31.737225] CR2: 0000000000000038 CR3: 000000041a40a003 CR4: 00000000003606e0
> [ 31.737227] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 31.737228] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 31.737230] Kernel panic - not syncing: Fatal exception in interrupt
> [ 31.737264] Kernel Offset: 0x3c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 36.558279] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
> [ 36.566769] ------------[ cut here ]------------
> [ 36.572306] sched: Unexpected reschedule of offline CPU#3!
> [ 36.578714] WARNING: CPU: 5 PID: 42 at /build/linux-hwe-edge-yHKLQJ/linux-hwe-edge-4.18.0/arch/x86/kernel/smp.c:128 native_smp_send_resched
> ule+0x3a/0x40
> [ 36.594262] Modules linked in: esp6 authenc echainiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp
> esp4 ah4 af_key xfrm_algo ip_vti ip_tunnel ip6_vti ip6_tunnel tunnel6 8021q garp mrp stp llc bonding ipt_REJECT nf_reject_ipv4 nfnetlink_log n
> fnetlink xt_NFLOG xt_hl xt_limit xt_nat xt_TCPMSS xt_HL xt_comment xt_tcpudp xt_multiport xt_conntrack iptable_filter iptable_nat nf_conntrack
> _ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_connmark xt_mark iptable_mangle xt_CT nf_conntrack xt_addrtype iptable_raw bpfilter ipmi_ssif gpio_
> ich intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf input_leds joydev m
> ei_me intel_pch_thermal ioatdma mei lpc_ich ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mac_hid sch_fq_codel
> [ 36.673307] ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compres
> s raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0 multipath linear mlx5_ib ib_uverbs ib
> _core raid1 hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ast pcbc ttm drm_kms_helper aesni_intel syscopyarea aes_x
> 86_64 sysfillrect mxm_wmi crypto_simd sysimgblt cryptd glue_helper fb_sys_fops mlx5_core ixgbe igb mpt3sas drm ahci tls libahci i2c_algo_bit m
> lxfw raid_class dca devlink mdio scsi_transport_sas wmi
> [ 36.733827] CPU: 5 PID: 42 Comm: ksoftirqd/5 Tainted: G D 4.18.0-11-generic #12~18.04.1-Ubuntu
> [ 36.745027] Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0b 11/21/2016
> [ 36.754392] RIP: 0010:native_smp_send_reschedule+0x3a/0x40
> [ 36.761143] Code: c6 62 01 73 17 48 8b 05 24 d2 17 01 be fd 00 00 00 48 8b 40 30 e8 96 96 ba 00 5d c3 89 fe 48 c7 c7 90 2a cd 85 e8 26 4a 0
> 3 00 <0f> 0b 5d c3 66 90 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 20 65 48
> [ 36.782546] RSP: 0018:ffff9a35bfd43b68 EFLAGS: 00010082
> [ 36.789019] RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000006
> [ 36.797379] RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffff9a35bfd564b0
> [ 36.805721] RBP: ffff9a35bfd43b68 R08: 00000000000004b7 R09: 0000000000cdcdcd
> [ 36.814046] R10: 0000000000000324 R11: 00000000ffffffff R12: ffff9a35bfce2c40
> [ 36.822350] R13: ffff9a3598e35c00 R14: 0000000000000008 R15: 0000000000000003
> [ 36.830637] FS: 0000000000000000(0000) GS:ffff9a35bfd40000(0000) knlGS:0000000000000000
> [ 36.839869] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 36.846742] CR2: 0000000000000038 CR3: 000000041a40a003 CR4: 00000000003606e0
> [ 36.855009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 36.863275] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 36.871510] Call Trace:
> [ 36.875048] <IRQ>
> [ 36.878136] resched_curr+0x5d/0xc0
> [ 36.882689] check_preempt_wakeup+0x130/0x240
> [ 36.888116] check_preempt_curr+0x2d/0x90
> [ 36.893184] ttwu_do_wakeup+0x1e/0x140
> [ 36.897984] ttwu_do_activate+0x77/0x80
> [ 36.902857] try_to_wake_up+0x1d6/0x450
> [ 36.907726] ? __netif_receive_skb_core+0x48c/0xb70
> [ 36.913625] default_wake_function+0x12/0x20
> [ 36.918914] __wake_up_common+0x73/0x130
> [ 36.923851] __wake_up_locked+0x16/0x20
> [ 36.928706] ep_poll_callback+0xcb/0x2b0
> [ 36.933634] __wake_up_common+0x73/0x130
> [ 36.938549] __wake_up_common_lock+0x80/0xc0
> [ 36.943787] ? tick_sched_do_timer+0x60/0x60
> [ 36.949011] __wake_up+0x13/0x20
> [ 36.953190] wake_up_klogd_work_func+0x40/0x60
> [ 36.958560] irq_work_run_list+0x52/0x80
> [ 36.963388] irq_work_tick+0x3b/0x50
> [ 36.967841] update_process_times+0x42/0x60
> [ 36.972883] tick_sched_handle+0x25/0x70
> [ 36.977644] tick_sched_timer+0x3c/0x80
> [ 36.982285] __hrtimer_run_queues+0x10f/0x280
> [ 36.987429] hrtimer_interrupt+0xe7/0x240
> [ 36.992202] ? rcu_irq_exit+0x1d/0x20
> [ 36.996602] smp_apic_timer_interrupt+0x6f/0x130
> [ 37.001929] apic_timer_interrupt+0xf/0x20
> [ 37.006712] </IRQ>
> [ 37.009476] RIP: 0010:panic+0x1fe/0x244
> [ 37.013951] Code: eb a6 83 3d 37 05 8f 01 00 74 05 e8 d0 73 02 00 48 c7 c6 20 f1 57 86 48 c7 c7 c8 cd cd 85 e8 f0 78 06 00 fb 66 0f 1f 44 0
> 0 00 <31> db e8 2f c6 0d 00 4c 39 eb 7c 1d 41 83 f4 01 48 8b 05 df 04 8f
> [ 37.034119] RSP: 0018:ffffbc61832e3668 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> [ 37.042324] RAX: 0000000000000046 RBX: 0000000000000000 RCX: 0000000000000006
> [ 37.050086] RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff9a35bfd564b0
> [ 37.057835] RBP: ffffbc61832e36e0 R08: 00000000000004b5 R09: 0000000000cdcdcd
> [ 37.065570] R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000
> [ 37.006712] </IRQ>
> [ 37.009476] RIP: 0010:panic+0x1fe/0x244
> [ 37.013951] Code: eb a6 83 3d 37 05 8f 01 00 74 05 e8 d0 73 02 00 48 c7 c6 20 f1 57 86 48 c7 c7 c8 cd cd 85 e8 f0 78 06 00 fb 66 0f 1f 44 00 00 <31> db e8 2f c6 0d 00 4c 39 eb 7c 1d 41 83 f4 01 48 8b 05 df 04 8f
> [ 37.034119] RSP: 0018:ffffbc61832e3668 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> [ 37.042324] RAX: 0000000000000046 RBX: 0000000000000000 RCX: 0000000000000006
> [ 37.050086] RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff9a35bfd564b0
> [ 37.057835] RBP: ffffbc61832e36e0 R08: 00000000000004b5 R09: 0000000000cdcdcd
> [ 37.065570] R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000
> [ 37.073287] R13: 0000000000000000 R14: 0000000000000009 R15: 0000000000000000
> [ 37.080999] ? panic+0x1f7/0x244
> [ 37.084812] oops_end+0xce/0xe0
> [ 37.088531] no_context+0x17c/0x400
> [ 37.092585] ? skcipher_walk_first+0x4c/0x110
> [ 37.097500] __bad_area_nosemaphore+0x115/0x1d0
> [ 37.102591] ? cbc_decrypt+0xb1/0xe0 [aesni_intel]
> [ 37.107926] bad_area_nosemaphore+0x14/0x20
> [ 37.112654] __do_page_fault+0xd4/0x4d0
> [ 37.117030] do_page_fault+0x2d/0xf0
> [ 37.121143] ? skb_copy_bits+0x61/0x260
> [ 37.125511] page_fault+0x1e/0x30
> [ 37.129362] RIP: 0010:vti_rcv_cb+0xb9/0x1a0 [ip_vti]
> [ 37.134864] Code: 8b 44 24 70 0f c8 89 87 b4 00 00 00 48 8b 86 20 05 00 00 8b 80 f8 14 00 00 85 c0 75 05 48 85 d2 74 0e 48 8b 43 58 48 83 e0 fe <f6> 40 38 04 74 7d 44 89 b3 b4 00 00 00 49 8b 44 24 20 48 39 86 20
> [ 37.154892] RSP: 0018:ffffbc61832e3920 EFLAGS: 00010246
> [ 37.160711] RAX: 0000000000000000 RBX: ffff9a3504964a00 RCX: 0000000000000002
> [ 37.168451] RDX: ffff9a351add4080 RSI: ffff9a351aa08000 RDI: ffff9a3504964a00
> [ 37.176196] RBP: ffffbc61832e3940 R08: 0000000000000004 R09: ffffffffc0aa612b
> [ 37.183950] R10: 0008f09b99881884 R11: 1884bd4e2d6b1fac R12: ffff9a3507b31900
> [ 37.191716] R13: ffff9a3507b31000 R14: 0000000000000000 R15: ffff9a3504964a00
> [ 37.199481] ? esp_input_done2+0x6b/0x320 [esp4]
> [ 37.204740] xfrm4_rcv_cb+0x4a/0x70
> [ 37.208873] xfrm_input+0x58f/0x8f0
> [ 37.212996] vti_input+0xaa/0x110 [ip_vti]
> [ 37.217735] vti_rcv+0x33/0x3c [ip_vti]
> [ 37.222209] xfrm4_esp_rcv+0x39/0x50
> [ 37.226424] ip_local_deliver_finish+0x62/0x200
> [ 37.231599] ip_local_deliver+0xdf/0xf0
> [ 37.236072] ? ip_rcv_finish+0x420/0x420
> [ 37.240635] ip_rcv_finish+0x126/0x420
> [ 37.245025] ip_rcv+0x28f/0x360
> [ 37.248801] ? inet_del_offload+0x40/0x40
> [ 37.253457] __netif_receive_skb_core+0x48c/0xb70
> [ 37.258807] ? kmem_cache_alloc+0xb4/0x1d0
> [ 37.263541] ? __build_skb+0x2b/0xf0
> [ 37.267749] __netif_receive_skb+0x18/0x60
> [ 37.272483] ? __netif_receive_skb+0x18/0x60
> [ 37.277391] netif_receive_skb_internal+0x45/0xe0
> [ 37.282732] napi_gro_receive+0xc5/0xf0
> [ 37.287232] mlx5e_handle_rx_cqe+0x1b2/0x5d0 [mlx5_core]
> [ 37.293170] ? skb_release_all+0x24/0x30
> [ 37.297708] mlx5e_poll_rx_cq+0xd3/0x990 [mlx5_core]
> [ 37.303281] mlx5e_napi_poll+0x9b/0xc60 [mlx5_core]
> [ 37.308752] ? __switch_to_asm+0x34/0x70
> [ 37.313266] ? __switch_to_asm+0x40/0x70
> [ 37.317768] ? __switch_to_asm+0x34/0x70
> [ 37.322259] ? __switch_to_asm+0x40/0x70
> [ 37.326742] ? __switch_to_asm+0x34/0x70
> [ 37.331214] net_rx_action+0x140/0x3a0
> [ 37.335519] ? __switch_to+0xad/0x500
> [ 37.339728] __do_softirq+0xe4/0x2bb
> [ 37.343852] run_ksoftirqd+0x2b/0x40
> [ 37.347971] smpboot_thread_fn+0xfc/0x170
> [ 37.352522] kthread+0x121/0x140
> [ 37.356282] ? sort_range+0x30/0x30
> [ 37.360303] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 37.365895] ret_from_fork+0x35/0x40
> [ 37.370010] ---[ end trace c4bada38847a0076 ]---
^ permalink raw reply related
* Re: [PATCH bpf] bpf: fix off-by-one error in adjust_subprog_starts
From: Alexei Starovoitov @ 2018-11-17 5:15 UTC (permalink / raw)
To: Edward Cree; +Cc: ast, daniel, netdev, linux-kernel, syzkaller-bugs
In-Reply-To: <bce0322a-6392-3fd4-a6fb-562160c26198@solarflare.com>
On Fri, Nov 16, 2018 at 12:00:07PM +0000, Edward Cree wrote:
> When patching in a new sequence for the first insn of a subprog, the start
> of that subprog does not change (it's the first insn of the sequence), so
> adjust_subprog_starts should check start <= off (rather than < off).
> Also added a test to test_verifier.c (it's essentially the syz reproducer).
>
> Fixes: cc8b0b92a169 ("bpf: introduce function calls (function boundaries)")
> Reported-by: syzbot+4fc427c7af994b0948be@syzkaller.appspotmail.com
> Signed-off-by: Edward Cree <ecree@solarflare.com>
thanks for quick analysis and fix.
Applied, Thanks
^ permalink raw reply
* Re: [PATCH bpf] bpf: allocate local storage buffers using GFP_ATOMIC
From: Alexei Starovoitov @ 2018-11-17 5:20 UTC (permalink / raw)
To: Roman Gushchin; +Cc: netdev, linux-kernel, kernel-team, Roman Gushchin, daniel
In-Reply-To: <20181114180034.25558-1-guro@fb.com>
On Wed, Nov 14, 2018 at 10:00:34AM -0800, Roman Gushchin wrote:
> Naresh reported an issue with the non-atomic memory allocation of
> cgroup local storage buffers:
>
> [ 73.047526] BUG: sleeping function called from invalid context at
> /srv/oe/build/tmp-rpb-glibc/work-shared/intel-corei7-64/kernel-source/mm/slab.h:421
> [ 73.060915] in_atomic(): 1, irqs_disabled(): 0, pid: 3157, name: test_cgroup_sto
> [ 73.068342] INFO: lockdep is turned off.
> [ 73.072293] CPU: 2 PID: 3157 Comm: test_cgroup_sto Not tainted
> 4.20.0-rc2-next-20181113 #1
> [ 73.080548] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 73.088018] Call Trace:
> [ 73.090463] dump_stack+0x70/0xa5
> [ 73.093783] ___might_sleep+0x152/0x240
> [ 73.097619] __might_sleep+0x4a/0x80
> [ 73.101191] __kmalloc_node+0x1cf/0x2f0
> [ 73.105031] ? cgroup_storage_update_elem+0x46/0x90
> [ 73.109909] cgroup_storage_update_elem+0x46/0x90
>
> cgroup_storage_update_elem() (as well as other update map update
> callbacks) is called with disabled preemption, so GFP_ATOMIC
> allocation should be used: e.g. alloc_htab_elem() in hashtab.c.
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
applied to bpf tree, thanks
^ permalink raw reply
* Re: [BUG] xfrm: unable to handle kernel NULL pointer dereference
From: Steffen Klassert @ 2018-11-16 19:12 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: herbert, Jean-Philippe Menil, davem, netdev, kuznet, yoshfuji
In-Reply-To: <20181116184800.GY16768@wantstofly.org>
On Fri, Nov 16, 2018 at 08:48:00PM +0200, Lennert Buytenhek wrote:
> On Sat, Nov 10, 2018 at 08:34:34PM +0100, Jean-Philippe Menil wrote:
>
> > we're seeing unexpected crashes from kernel 4.15 to 4.18.17, using
> > IPsec VTI interfaces, on several vpn hosts, since upgrade from 4.4.
>
> I looked into this with Jean-Philippe, and it appears to be crashing
> on a NULL pointer dereference in the inlined xfrm_policy_check() call
> in vti_rcv_cb(), and specifically on the skb_dst(skb) dereference in
> __xfrm_policy_check2():
>
> return (!net->xfrm.policy_count[dir] && !skb->sp) ||
> (skb_dst(skb)->flags & DST_NOPOLICY) || <=====
> __xfrm_policy_check(sk, ndir, skb, family);
>
> Commit 9e1437937807 ("xfrm: Fix NULL pointer dereference when
> skb_dst_force clears the dst_entry.") fixes a very similar problem on
> the output and forward paths, but our issue seems to be triggering on
> the input path.
Yes, this is the same problem. skb_dst_force() does not
really force a refcount anymore, it might clear the dst
pointer instead (maybe this function should be renamed).
Want to submit a fix? If not I'll go to fix that.
Thanks!
^ permalink raw reply
* [PATCH net-next] add part of TCP counts explanations in snmp_counters.rst
From: yupeng @ 2018-11-16 19:17 UTC (permalink / raw)
To: netdev, xiyou.wangcong, rdunlap
Add explanations of some generic TCP counters, fast open
related counters and TCP abort related counters and several
examples.
Signed-off-by: yupeng <yupeng0921@gmail.com>
---
Documentation/networking/snmp_counter.rst | 525 +++++++++++++++++++++-
1 file changed, 524 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/snmp_counter.rst b/Documentation/networking/snmp_counter.rst
index e0d588fcb67f..a5b8dc0c7c4a 100644
--- a/Documentation/networking/snmp_counter.rst
+++ b/Documentation/networking/snmp_counter.rst
@@ -40,7 +40,7 @@ multicast packets, and would always be updated together with
IpExtOutOctets.
* IpExtInOctets and IpExtOutOctets
-They are linux kernel extensions, no RFC definitions. Please note,
+They are Linux kernel extensions, no RFC definitions. Please note,
RFC1213 indeed defines ifInOctets and ifOutOctets, but they
are different things. The ifInOctets and ifOutOctets include the MAC
layer header size but IpExtInOctets and IpExtOutOctets don't, they
@@ -174,6 +174,163 @@ IcmpMsgOutType[N]. If the errors occur in both step (2) and step (4),
IcmpInMsgs should be less than the sum of IcmpMsgOutType[N] plus
IcmpInErrors.
+General TCP counters
+==================
+* TcpInSegs
+Defined in `RFC1213 tcpInSegs`_
+
+.. _RFC1213 tcpInSegs: https://tools.ietf.org/html/rfc1213#page-48
+
+The number of packets received by the TCP layer. As mentioned in
+RFC1213, it includes the packets received in error, such as checksum
+error, invalid TCP header and so on. Only one error won't be included:
+if the layer 2 destination address is not the NIC's layer 2
+address. It might happen if the packet is a multicast or broadcast
+packet, or the NIC is in promiscuous mode. In these situations, the
+packets would be delivered to the TCP layer, but the TCP layer will discard
+these packets before increasing TcpInSegs. The TcpInSegs counter
+isn't aware of GRO. So if two packets are merged by GRO, the TcpInSegs
+counter would only increase 1.
+
+* TcpOutSegs
+Defined in `RFC1213 tcpOutSegs`_
+
+.. _RFC1213 tcpOutSegs: https://tools.ietf.org/html/rfc1213#page-48
+
+The number of packets sent by the TCP layer. As mentioned in RFC1213,
+it excludes the retransmitted packets. But it includes the SYN, ACK
+and RST packets. Doesn't like TcpInSegs, the TcpOutSegs is aware of
+GSO, so if a packet would be split to 2 by GSO, TcpOutSegs will
+increase 2.
+
+* TcpActiveOpens
+Defined in `RFC1213 tcpActiveOpens`_
+
+.. _RFC1213 tcpActiveOpens: https://tools.ietf.org/html/rfc1213#page-47
+
+It means the TCP layer sends a SYN, and come into the SYN-SENT
+state. Every time TcpActiveOpens increases 1, TcpOutSegs should always
+increase 1.
+
+* TcpPassiveOpens
+Defined in `RFC1213 tcpPassiveOpens`_
+
+.. _RFC1213 tcpPassiveOpens: https://tools.ietf.org/html/rfc1213#page-47
+
+It means the TCP layer receives a SYN, replies a SYN+ACK, come into
+the SYN-RCVD state.
+
+TCP Fast Open
+============
+When kernel receives a TCP packet, it has two paths to handler the
+packet, one is fast path, another is slow path. The comment in kernel
+code provides a good explanation of them, I pasted them below::
+
+ It is split into a fast path and a slow path. The fast path is
+ disabled when:
+
+ - A zero window was announced from us
+ - zero window probing
+ is only handled properly on the slow path.
+ - Out of order segments arrived.
+ - Urgent data is expected.
+ - There is no buffer space left
+ - Unexpected TCP flags/window values/header lengths are received
+ (detected by checking the TCP header against pred_flags)
+ - Data is sent in both directions. The fast path only supports pure senders
+ or pure receivers (this means either the sequence number or the ack
+ value must stay constant)
+ - Unexpected TCP option.
+
+Kernel will try to use fast path unless any of the above conditions
+are satisfied. If the packets are out of order, kernel will handle
+them in slow path, which means the performance might be not very
+good. Kernel would also come into slow path if the "Delayed ack" is
+used, because when using "Delayed ack", the data is sent in both
+directions. When the TCP window scale option is not used, kernel will
+try to enable fast path immediately when the connection comes into the
+established state, but if the TCP window scale option is used, kernel
+will disable the fast path at first, and try to enable it after kernel
+receives packets.
+
+* TcpExtTCPPureAcks and TcpExtTCPHPAcks
+If a packet set ACK flag and has no data, it is a pure ACK packet, if
+kernel handles it in the fast path, TcpExtTCPHPAcks will increase 1,
+if kernel handles it in the slow path, TcpExtTCPPureAcks will
+increase 1.
+
+* TcpExtTCPHPHits
+If a TCP packet has data (which means it is not a pure ACK packet),
+and this packet is handled in the fast path, TcpExtTCPHPHits will
+increase 1.
+
+
+TCP abort
+========
+
+
+* TcpExtTCPAbortOnData
+It means TCP layer has data in flight, but need to close the
+connection. So TCP layer sends a RST to the other side, indicate the
+connection is not closed very graceful. An easy way to increase this
+counter is using the SO_LINGER option. Please refer to the SO_LINGER
+section of the `socket man page`_:
+
+.. _socket man page: http://man7.org/linux/man-pages/man7/socket.7.html
+
+By default, when an application closes a connection, the close function
+will return immediately and kernel will try to send the in-flight data
+async. If you use the SO_LINGER option, set l_onoff to 1, and l_linger
+to a positive number, the close function won't return immediately, but
+wait for the in-flight data are acked by the other side, the max wait
+time is l_linger seconds. If set l_onoff to 1 and set l_linger to 0,
+when the application closes a connection, kernel will send a RST
+immediately and increase the TcpExtTCPAbortOnData counter.
+
+* TcpExtTCPAbortOnClose
+This counter means the application has unread data in the TCP layer when
+the application wants to close the TCP connection. In such a situation,
+kernel will send a RST to the other side of the TCP connection.
+
+* TcpExtTCPAbortOnMemory
+When an application closes a TCP connection, kernel still need to track
+the connection, let it complete the TCP disconnect process. E.g. an
+app calls the close method of a socket, kernel sends fin to the other
+side of the connection, then the app has no relationship with the
+socket any more, but kernel need to keep the socket, this socket
+becomes an orphan socket, kernel waits for the reply of the other side,
+and would come to the TIME_WAIT state finally. When kernel has no
+enough memory to keep the orphan socket, kernel would send an RST to
+the other side, and delete the socket, in such situation, kernel will
+increase 1 to the TcpExtTCPAbortOnMemory. Two conditions would trigger
+TcpExtTCPAbortOnMemory:
+
+1. the memory used by the TCP protocol is higher than the third value of
+the tcp_mem. Please refer the tcp_mem section in the `TCP man page`_:
+
+.. _TCP man page: http://man7.org/linux/man-pages/man7/tcp.7.html
+
+2. the orphan socket count is higher than net.ipv4.tcp_max_orphans
+
+
+* TcpExtTCPAbortOnTimeout
+This counter will increase when any of the TCP timers expire. In such
+situation, kernel won't send RST, just give up the connection.
+
+* TcpExtTCPAbortOnLinger
+When a TCP connection comes into FIN_WAIT_2 state, instead of waiting
+for the fin packet from the other side, kernel could send a RST and
+delete the socket immediately. This is not the default behavior of
+Linux kernel TCP stack. By configuring the TCP_LINGER2 socket option,
+you could let kernel follow this behavior.
+
+* TcpExtTCPAbortFailed
+The kernel TCP layer will send RST if the `RFC2525 2.17 section`_ is
+satisfied. If an internal error occurs during this process,
+TcpExtTCPAbortFailed will be increased.
+
+.. _RFC2525 2.17 section: https://tools.ietf.org/html/rfc2525#page-50
+
examples
=======
@@ -220,3 +377,369 @@ and its corresponding Echo Reply packet are constructed by:
* 48 bytes data (default value of the ping command)
So the IpExtInOctets and IpExtOutOctets are 20+16+48=84.
+
+tcp 3-way handshake
+------------------
+On server side, we run::
+
+ nstatuser@nstat-b:~$ nc -lknv 0.0.0.0 9000
+ Listening on [0.0.0.0] (family 0, port 9000)
+
+On client side, we run::
+
+ nstatuser@nstat-a:~$ nc -nv 192.168.122.251 9000
+ Connection to 192.168.122.251 9000 port [tcp/*] succeeded!
+
+The server listened on tcp 9000 port, the client connected to it, they
+completed the 3-way handshake.
+
+On server side, we can find below nstat output::
+
+ nstatuser@nstat-b:~$ nstat | grep -i tcp
+ TcpPassiveOpens 1 0.0
+ TcpInSegs 2 0.0
+ TcpOutSegs 1 0.0
+ TcpExtTCPPureAcks 1 0.0
+
+On client side, we can find below nstat output::
+
+ nstatuser@nstat-a:~$ nstat | grep -i tcp
+ TcpActiveOpens 1 0.0
+ TcpInSegs 1 0.0
+ TcpOutSegs 2 0.0
+
+When the server received the first SYN, it replied a SYN+ACK, and came into
+SYN-RCVD state, so TcpPassiveOpens increased 1. The server received
+SYN, sent SYN+ACK, received ACK, so server sent 1 packet, received 2
+packets, TcpInSegs increased 2, TcpOutSegs increased 1. The last ACK
+of the 3-way handshake is a pure ACK without data, so
+TcpExtTCPPureAcks increased 1.
+
+When the client sent SYN, the client came into the SYN-SENT state, so
+TcpActiveOpens increased 1, the client sent SYN, received SYN+ACK, sent
+ACK, so client sent 2 packets, received 1 packet, TcpInSegs increased
+1, TcpOutSegs increased 2.
+
+TCP normal traffic
+-----------------
+Run nc on server::
+
+ nstatuser@nstat-b:~$ nc -lkv 0.0.0.0 9000
+ Listening on [0.0.0.0] (family 0, port 9000)
+
+Run nc on client::
+
+ nstatuser@nstat-a:~$ nc -v nstat-b 9000
+ Connection to nstat-b 9000 port [tcp/*] succeeded!
+
+Input a string in the nc client ('hello' in our example)::
+
+ nstatuser@nstat-a:~$ nc -v nstat-b 9000
+ Connection to nstat-b 9000 port [tcp/*] succeeded!
+ hello
+
+The client side nstat output::
+
+ nstatuser@nstat-a:~$ nstat
+ #kernel
+ IpInReceives 1 0.0
+ IpInDelivers 1 0.0
+ IpOutRequests 1 0.0
+ TcpInSegs 1 0.0
+ TcpOutSegs 1 0.0
+ TcpExtTCPPureAcks 1 0.0
+ TcpExtTCPOrigDataSent 1 0.0
+ IpExtInOctets 52 0.0
+ IpExtOutOctets 58 0.0
+ IpExtInNoECTPkts 1 0.0
+
+The server side nstat output::
+
+ nstatuser@nstat-b:~$ nstat
+ #kernel
+ IpInReceives 1 0.0
+ IpInDelivers 1 0.0
+ IpOutRequests 1 0.0
+ TcpInSegs 1 0.0
+ TcpOutSegs 1 0.0
+ IpExtInOctets 58 0.0
+ IpExtOutOctets 52 0.0
+ IpExtInNoECTPkts 1 0.0
+
+Input a string in nc client side again ('world' in our exmaple)::
+
+ nstatuser@nstat-a:~$ nc -v nstat-b 9000
+ Connection to nstat-b 9000 port [tcp/*] succeeded!
+ hello
+ world
+
+Client side nstat output::
+
+ nstatuser@nstat-a:~$ nstat
+ #kernel
+ IpInReceives 1 0.0
+ IpInDelivers 1 0.0
+ IpOutRequests 1 0.0
+ TcpInSegs 1 0.0
+ TcpOutSegs 1 0.0
+ TcpExtTCPHPAcks 1 0.0
+ TcpExtTCPOrigDataSent 1 0.0
+ IpExtInOctets 52 0.0
+ IpExtOutOctets 58 0.0
+ IpExtInNoECTPkts 1 0.0
+
+
+Server side nstat output::
+
+ nstatuser@nstat-b:~$ nstat
+ #kernel
+ IpInReceives 1 0.0
+ IpInDelivers 1 0.0
+ IpOutRequests 1 0.0
+ TcpInSegs 1 0.0
+ TcpOutSegs 1 0.0
+ TcpExtTCPHPHits 1 0.0
+ IpExtInOctets 58 0.0
+ IpExtOutOctets 52 0.0
+ IpExtInNoECTPkts 1 0.0
+
+Compare the first client-side nstat and the second client-side nstat,
+we could find one difference: the first one had a 'TcpExtTCPPureAcks',
+but the second one had a 'TcpExtTCPHPAcks'. The first server-side
+nstat and the second server-side nstat had a difference too: the
+second server-side nstat had a TcpExtTCPHPHits, but the first
+server-side nstat didn't have it. The network traffic patterns were
+exactly the same: the client sent a packet to the server, the server
+replied an ACK. But kernel handled them in different ways. When the
+TCP window scale option is not used, kernel will try to enable fast
+path immediately when the connection comes into the established state,
+but if the TCP window scale option is used, kernel will disable the
+fast path at first, and try to enable it after kerenl receives
+packets. We could use the 'ss' command to verify whether the window
+scale option is used. e.g. run below command on either server or
+client::
+
+ nstatuser@nstat-a:~$ ss -o state established -i '( dport = :9000 or sport = :9000 )
+ Netid Recv-Q Send-Q Local Address:Port Peer Address:Port
+ tcp 0 0 192.168.122.250:40654 192.168.122.251:9000
+ ts sack cubic wscale:7,7 rto:204 rtt:0.98/0.49 mss:1448 pmtu:1500 rcvmss:536 advmss:1448 cwnd:10 bytes_acked:1 segs_out:2 segs_in:1 send 118.2Mbps lastsnd:46572 lastrcv:46572 lastack:46572 pacing_rate 236.4Mbps rcv_space:29200 rcv_ssthresh:29200 minrtt:0.98
+
+The 'wscale:7,7' means both server and client set the window scale
+option to 7. Now we could explain the nstat output in our test:
+
+In the first nstat output of client side, the client sent a packet, server
+reply an ACK, when kernel handled this ACK, the fast path was not
+enabled, so the ACK was counted into 'TcpExtTCPPureAcks'.
+
+In the second nstat output of client side, the client sent a packet again,
+and received another ACK from the server, in this time, the fast path is
+enabled, and the ACK was qualified for fast path, so it was handled by
+the fast path, so this ACK was counted into TcpExtTCPHPAcks.
+
+In the first nstat output of server side, fast path was not enabled,
+so there was no 'TcpExtTCPHPHits'.
+
+In the second nstat output of server side, the fast path was enabled,
+and the packet received from client qualified for fast path, so it
+was counted into 'TcpExtTCPHPHits'.
+
+TcpExtTCPAbortOnClose
+--------------------
+On the server side, we run below python script::
+
+ import socket
+ import time
+
+ port = 9000
+
+ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+ s.bind(('0.0.0.0', port))
+ s.listen(1)
+ sock, addr = s.accept()
+ while True:
+ time.sleep(9999999)
+
+This python script listen on 9000 port, but doesn't read anything from
+the connection.
+
+On the client side, we send the string "hello" by nc::
+
+ nstatuser@nstat-a:~$ echo "hello" | nc nstat-b 9000
+
+Then, we come back to the server side, the server has received the "hello"
+packet, and the TCP layer has acked this packet, but the application didn't
+read it yet. We type Ctrl-C to terminate the server script. Then we
+could find TcpExtTCPAbortOnClose increased 1 on the server side::
+
+ nstatuser@nstat-b:~$ nstat | grep -i abort
+ TcpExtTCPAbortOnClose 1 0.0
+
+If we run tcpdump on the server side, we could find the server sent a
+RST after we type Ctrl-C.
+
+TcpExtTCPAbortOnMemory and TcpExtTCPAbortOnTimeout
+-----------------------------------------------
+Below is an example which let the orphan socket count be higher than
+net.ipv4.tcp_max_orphans.
+Change tcp_max_orphans to a smaller value on client::
+
+ sudo bash -c "echo 10 > /proc/sys/net/ipv4/tcp_max_orphans"
+
+Client code (create 64 connection to server)::
+
+ nstatuser@nstat-a:~$ cat client_orphan.py
+ import socket
+ import time
+
+ server = 'nstat-b' # server address
+ port = 9000
+
+ count = 64
+
+ connection_list = []
+
+ for i in range(64):
+ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+ s.connect((server, port))
+ connection_list.append(s)
+ print("connection_count: %d" % len(connection_list))
+
+ while True:
+ time.sleep(99999)
+
+Server code (accept 64 connection from client)::
+
+ nstatuser@nstat-b:~$ cat server_orphan.py
+ import socket
+ import time
+
+ port = 9000
+ count = 64
+
+ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+ s.bind(('0.0.0.0', port))
+ s.listen(count)
+ connection_list = []
+ while True:
+ sock, addr = s.accept()
+ connection_list.append((sock, addr))
+ print("connection_count: %d" % len(connection_list))
+
+Run the python scripts on server and client.
+
+On server::
+
+ python3 server_orphan.py
+
+On client::
+
+ python3 client_orphan.py
+
+Run iptables on server::
+
+ sudo iptables -A INPUT -i ens3 -p tcp --destination-port 9000 -j DROP
+
+Type Ctrl-C on client, stop client_orphan.py.
+
+Check TcpExtTCPAbortOnMemory on client::
+
+ nstatuser@nstat-a:~$ nstat | grep -i abort
+ TcpExtTCPAbortOnMemory 54 0.0
+
+Check orphane socket count on client::
+
+ nstatuser@nstat-a:~$ ss -s
+ Total: 131 (kernel 0)
+ TCP: 14 (estab 1, closed 0, orphaned 10, synrecv 0, timewait 0/0), ports 0
+
+ Transport Total IP IPv6
+ * 0 - -
+ RAW 1 0 1
+ UDP 1 1 0
+ TCP 14 13 1
+ INET 16 14 2
+ FRAG 0 0 0
+
+The explanation of the test: after run server_orphan.py and
+client_orphan.py, we set up 64 connections between server and
+client. Run the iptables command, the server will drop all packets from
+the client, type Ctrl-C on client_orphan.py, the system of the client
+would try to close these connections, and before they are closed
+gracefully, these connections became orphan sockets. As the iptables
+of the server blocked packets from the client, the server won't receive fin
+from the client, so all connection on clients would be stuck on FIN_WAIT_1
+stage, so they will keep as orphan sockets until timeout. We have echo
+10 to /proc/sys/net/ipv4/tcp_max_orphans, so the client system would
+only keep 10 orphan sockets, for all other orphan sockets, the client
+system sent RST for them and delete them. We have 64 connections, so
+the 'ss -s' command shows the system has 10 orphan sockets, and the
+value of TcpExtTCPAbortOnMemory was 54.
+
+An additional explanation about orphan socket count: You could find the
+exactly orphan socket count by the 'ss -s' command, but when kernel
+decide whither increases TcpExtTCPAbortOnMemory and sends RST, kernel
+doesn't always check the exactly orphan socket count. For increasing
+performance, kernel checks an approximate count firstly, if the
+approximate count is more than tcp_max_orphans, kernel checks the
+exact count again. So if the approximate count is less than
+tcp_max_orphans, but exactly count is more than tcp_max_orphans, you
+would find TcpExtTCPAbortOnMemory is not increased at all. If
+tcp_max_orphans is large enough, it won't occur, but if you decrease
+tcp_max_orphans to a small value like our test, you might find this
+issue. So in our test, the client set up 64 connections although the
+tcp_max_orphans is 10. If the client only set up 11 connections, we
+can't find the change of TcpExtTCPAbortOnMemory.
+
+Continue the previous test, we wait for several minutes. Because of the
+iptables on the server blocked the traffic, the server wouldn't receive
+fin, and all the client's orphan sockets would timeout on the
+FIN_WAIT_1 state finally. So we wait for a few minutes, we could find
+10 timeout on the client::
+
+ nstatuser@nstat-a:~$ nstat | grep -i abort
+ TcpExtTCPAbortOnTimeout 10 0.0
+
+TcpExtTCPAbortOnLinger
+---------------------
+The server side code::
+
+ nstatuser@nstat-b:~$ cat server_linger.py
+ import socket
+ import time
+
+ port = 9000
+
+ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+ s.bind(('0.0.0.0', port))
+ s.listen(1)
+ sock, addr = s.accept()
+ while True:
+ time.sleep(9999999)
+
+The client side code::
+
+ nstatuser@nstat-a:~$ cat client_linger.py
+ import socket
+ import struct
+
+ server = 'nstat-b' # server address
+ port = 9000
+
+ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+ s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 10))
+ s.setsockopt(socket.SOL_TCP, socket.TCP_LINGER2, struct.pack('i', -1))
+ s.connect((server, port))
+ s.close()
+
+Run server_linger.py on server::
+
+ nstatuser@nstat-b:~$ python3 server_linger.py
+
+Run client_linger.py on client::
+
+ nstatuser@nstat-a:~$ python3 client_linger.py
+
+After run client_linger.py, check the output of nstat::
+
+ nstatuser@nstat-a:~$ nstat | grep -i abort
+ TcpExtTCPAbortOnLinger 1 0.0
--
2.17.1
^ permalink raw reply related
* Re: [Patch net] net: invert the check of detecting hardware RX checksum fault
From: Cong Wang @ 2018-11-16 20:06 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linux Kernel Network Developers, Tom Herbert, Eric Dumazet
In-Reply-To: <20181116045019.kmvo36uk3o6bahxu@gondor.apana.org.au>
On Thu, Nov 15, 2018 at 8:50 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Nov 15, 2018 at 06:23:38PM -0800, Cong Wang wrote:
> >
> > > Normally if the hardware's partial checksum is valid then we just
> > > trust it and send the packet along. However, if the partial
> > > checksum is invalid we don't trust it and we will compute the
> > > whole checksum manually which is what ends up in sum.
> >
> > Not sure if I understand partial checksum here, but it is the
> > CHECKSUM_COMPLETE case which I am trying to fix, not
> > CHECKSUM_PARTIAL.
>
> What I meant by partial checksum is the checksum produced by the
> hardware on RX. In the kernel we call that CHECKSUM_COMPLETE.
> CHECKSUM_PARTIAL is the absence of the substantial part of the
> checksum which is something we use in the kernel primarily for TX.
>
> Yes the names are confusing :)
Yeah, understood. The hardware provides skb->csum in this case, but
we keep adjusting it each time when we change skb->data.
>
> > So, in other word, a checksum *match* is the intended to detect
> > this HW RX checksum fault?
>
> Correct. Or more likely it's probably a bug in either the driver
> or if there are overlaying code such as VLAN then in that code.
>
> Basically if the RX checksum is buggy, it's much more likely to
> cause a valid packet to be rejected than to cause an invalid packet
> to be accepted, because we still verify that checksum against the
> pseudoheader. So we only attempt to catch buggy hardware/drivers
> by doing a second manual verification for the case where the packet
> is flagged as invalid.
Hmm, now I see how it works. Actually it uses the differences between
these two check's as the difference between hardware checksum with
skb_checksum().
I will send a patch to add a comment there to avoid confusion.
>
> > Sure, my case is nearly same with Pawel's, except I have no vlan:
> > https://marc.info/?l=linux-netdev&m=154086647601721&w=2
>
> Can you please provide your backtrace?
I already did:
https://marc.info/?l=linux-netdev&m=154092211305599&w=2
Note, the offending commit has been backported to 4.14, which
is why I saw this warning. I have no idea why it is backported
from the beginning, it is just an optimization, doesn't fix any bug,
IMHO.
Also, it is much harder for me to reproduce it than Pawel who
saw the warning every second. Sometimes I need 1 hour to trigger
it, sometimes other people here needs 10+ hours to trigger it.
Let me see if I can add vlan on my side to make it more reproducible,
it seems hard as our switch doesn't use vlan either.
We have warnings with conntrack involved too, I can provide it too
if you are interested.
I tend to revert it for -stable, at least that is what I plan to do
on my side unless there is a fix coming soon.
Thanks.
^ permalink raw reply
* Re: [PATCH] [PATCH net-next] tun: fix multiqueue rx
From: Michael S. Tsirkin @ 2018-11-16 20:10 UTC (permalink / raw)
To: Matthew Cover
Cc: davem, jasowang, brouer, edumazet, sd, netdev, matthew.cover
In-Reply-To: <20181116070015.1759-1-matthew.cover@stackpath.com>
On Fri, Nov 16, 2018 at 12:00:15AM -0700, Matthew Cover wrote:
> When writing packets to a descriptor associated with a combined queue, the
> packets should end up on that queue.
>
> Before this change all packets written to any descriptor associated with a
> tap interface end up on rx-0, even when the descriptor is associated with a
> different queue.
>
> The rx traffic can be generated by either of the following.
> 1. a simple tap program which spins up multiple queues and writes packets
> to each of the file descriptors
> 2. tx from a qemu vm with a tap multiqueue netdev
>
> The queue for rx traffic can be observed by either of the following (done
> on the hypervisor in the qemu case).
> 1. a simple netmap program which opens and reads from per-queue
> descriptors
> 2. configuring RPS and doing per-cpu captures with rxtxcpu
>
> Alternatively, if you printk() the return value of skb_get_rx_queue() just
> before each instance of netif_receive_skb() in tun.c, you will get 65535
> for every skb.
>
> Calling skb_record_rx_queue() to set the rx queue to the queue_index fixes
> the association between descriptor and rx queue.
>
> Signed-off-by: Matthew Cover <matthew.cover@stackpath.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
stable material?
> ---
> drivers/net/tun.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index a65779c6d72f..ce8620f3ea5e 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1536,6 +1536,7 @@ static void tun_rx_batched(struct tun_struct *tun, struct tun_file *tfile,
>
> if (!rx_batched || (!more && skb_queue_empty(queue))) {
> local_bh_disable();
> + skb_record_rx_queue(skb, tfile->queue_index);
> netif_receive_skb(skb);
> local_bh_enable();
> return;
> @@ -1555,8 +1556,11 @@ static void tun_rx_batched(struct tun_struct *tun, struct tun_file *tfile,
> struct sk_buff *nskb;
>
> local_bh_disable();
> - while ((nskb = __skb_dequeue(&process_queue)))
> + while ((nskb = __skb_dequeue(&process_queue))) {
> + skb_record_rx_queue(nskb, tfile->queue_index);
> netif_receive_skb(nskb);
> + }
> + skb_record_rx_queue(skb, tfile->queue_index);
> netif_receive_skb(skb);
> local_bh_enable();
> }
> @@ -2452,6 +2456,7 @@ static int tun_xdp_one(struct tun_struct *tun,
> !tfile->detached)
> rxhash = __skb_get_hash_symmetric(skb);
>
> + skb_record_rx_queue(skb, tfile->queue_index);
> netif_receive_skb(skb);
>
> stats = get_cpu_ptr(tun->pcpu_stats);
> --
> 2.15.2 (Apple Git-101.1)
^ permalink raw reply
* Re: [Patch net] net: invert the check of detecting hardware RX checksum fault
From: Cong Wang @ 2018-11-16 20:10 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Dumazet, Linux Kernel Network Developers, Tom Herbert,
Eric Dumazet, Saeed Mahameed
In-Reply-To: <20181116045900.lqztm7r5gk246act@gondor.apana.org.au>
On Thu, Nov 15, 2018 at 8:59 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Nov 15, 2018 at 08:52:23PM -0800, Eric Dumazet wrote:
> >
> > It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the
> > case non zero trailer bytes were added by a buggy switch (or host)
>
> We should probably change netdev_rx_csum_fault to print out at
> least one complete packet plus the hardware-generated checksum.
>
> That would make debugging these rare hardware faults much easier.
I have a patch as a starter:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=7fe50ac83f4319c18ed7c634d85cad16bd0bf509
Let me know if you want to add more information there.
Dumping the hex of an skb data?
Thanks.
^ permalink raw reply
* RE: [PATCH iproute2-next v3] rdma: Document IB device renaming option
From: Ruhl, Michael J @ 2018-11-16 20:10 UTC (permalink / raw)
To: Leon Romanovsky, David Ahern
Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <20181104191122.11979-1-leon@kernel.org>
>-----Original Message-----
>From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-
>owner@vger.kernel.org] On Behalf Of Leon Romanovsky
>Sent: Sunday, November 4, 2018 2:11 PM
>To: David Ahern <dsahern@gmail.com>
>Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
><netdev@vger.kernel.org>; RDMA mailing list <linux-rdma@vger.kernel.org>;
>Stephen Hemminger <stephen@networkplumber.org>
>Subject: [PATCH iproute2-next v3] rdma: Document IB device renaming
>option
>
>From: Leon Romanovsky <leonro@mellanox.com>
Hi Leon,
After looking at this and Steve Wise's changes for the ADDLINK/DELLINK,
it occurred to me that the driver that handed the name to ib_register_device()
might be interested in knowing that this name change occurred.
Are there plans to include a some kind of notify mechanism so drivers can
find out when things like this occur?
Is this something that should be done?
Thanks,
Mike
>[leonro@server /]$ lspci |grep -i Ether
>00:08.0 Ethernet controller: Red Hat, Inc. Virtio network device
>00:09.0 Ethernet controller: Mellanox Technologies MT27700 Family
>[ConnectX-4]
>[leonro@server /]$ sudo rdma dev
>1: mlx5_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455
>sys_image_guid 5254:00c0:fe12:3455
>[leonro@server /]$ sudo rdma dev set mlx5_0 name hfi1_0
>[leonro@server /]$ sudo rdma dev
>1: hfi1_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455
>sys_image_guid 5254:00c0:fe12:3455
>
>Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
>---
>Changelog:
>v2->v3:
> * Dropped "to be named" words from example section of man
>---
> man/man8/rdma-dev.8 | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
>diff --git a/man/man8/rdma-dev.8 b/man/man8/rdma-dev.8
>index 461681b6..7c275180 100644
>--- a/man/man8/rdma-dev.8
>+++ b/man/man8/rdma-dev.8
>@@ -1,6 +1,6 @@
> .TH RDMA\-DEV 8 "06 Jul 2017" "iproute2" "Linux"
> .SH NAME
>-rdmak-dev \- RDMA device configuration
>+rdma-dev \- RDMA device configuration
> .SH SYNOPSIS
> .sp
> .ad l
>@@ -22,10 +22,18 @@ rdmak-dev \- RDMA device configuration
> .B rdma dev show
> .RI "[ " DEV " ]"
>
>+.ti -8
>+.B rdma dev set
>+.RI "[ " DEV " ]"
>+.BR name
>+.BR NEWNAME
>+
> .ti -8
> .B rdma dev help
>
> .SH "DESCRIPTION"
>+.SS rdma dev set - rename rdma device
>+
> .SS rdma dev show - display rdma device attributes
>
> .PP
>@@ -45,6 +53,11 @@ rdma dev show mlx5_3
> Shows the state of specified RDMA device.
> .RE
> .PP
>+rdma dev set mlx5_3 name rdma_0
>+.RS 4
>+Renames the mlx5_3 device to rdma_0.
>+.RE
>+.PP
>
> .SH SEE ALSO
> .BR rdma (8),
>--
>2.19.1
^ permalink raw reply
* [PATCH] MAINTAINERS: Add entry for CAKE qdisc
From: Toke Høiland-Jørgensen @ 2018-11-16 20:13 UTC (permalink / raw)
To: netdev; +Cc: Toke Høiland-Jørgensen, cake
We would like the existing community to be kept in the loop for any new
developments on CAKE; and I certainly plan to keep maintaining it. Reflect
this in MAINTAINERS.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3bd775ba51ce..96be48879a7b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3276,6 +3276,12 @@ F: include/uapi/linux/caif/
F: include/net/caif/
F: net/caif/
+CAKE QDISC
+M: Toke Høiland-Jørgensen <toke@toke.dk>
+L: cake@lists.bufferbloat.net (moderated for non-subscribers)
+S: Maintained
+F: net/sched/sch_cake.c
+
CALGARY x86-64 IOMMU
M: Muli Ben-Yehuda <mulix@mulix.org>
M: Jon Mason <jdmason@kudzu.us>
--
2.19.1
^ permalink raw reply related
* Re: [Patch net] net: invert the check of detecting hardware RX checksum fault
From: Cong Wang @ 2018-11-16 20:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Herbert Xu, Linux Kernel Network Developers, Tom Herbert,
Eric Dumazet, Saeed Mahameed
In-Reply-To: <a263d63e-f043-755b-d4a4-82fdc01bf23a@gmail.com>
On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the
> case non zero trailer bytes were added by a buggy switch (or host)
>
> Saeed can comment/confirm, but the theory is that the NIC does header analysis and
> computes a checksum only on the bytes of the IP frame, not including the tail bytes
> that were added by a switch.
This theory seems can't explain why Pawel saw this warning so often,
which is beyond the probability of a buggy switch. I don't know.
>
> You could use trafgen to cook such a frame and confirm the theory.
>
> Something like :
I will try it.
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