Re: [PATCH v2] net: core: SIOCADDMULTI/SIOCDELMULTI distinguish between uc and mc

>This doesn't seem appropriate at all. If anything UC addresses >should be blocked and the Intel driver change reverted. We have >a well defined way to add secondary UC addresses and the MC interfaces >are not it. As I understand by ‘well defined way’ you mean macvlan feature. But macvlan is mo

[PATCH v2] net: core: SIOCADDMULTI/SIOCDELMULTI distinguish between uc and mc

s API. (2f41f3358672 i40e/i40evf: fix unicast mac address add) This patch adds check whether passed mac addr is uc or mc and adds this mac addr to the corresponding list. Add 'global' variant for adding/removing uc addresses similarly to mc. Signed-off-by: Denys Zagorui --- include/linux/netd

[RFC][PATCH] net: core: SIOCADDMULTI/SIOCDELMULTI distinguish between uc and mc

s API. (2f41f3358672 i40e/i40evf: fix unicast mac address add) This patch adds check whether passed mac addr is uc or mc and adds this mac addr to the corresponding list. Add 'global' variant for adding/removing uc addresses similarly to mc. Signed-off-by: Denys Zagorui --- include/linux/netd

Re: 4.19.4 nf_conntrack_count kernel panic

On 2018-11-26 21:46, Sami Farin wrote: 4.18.20 works OK, but unfortunately 4.18 series is EOL. I have Ryzen 1600X, 32 GB RAM, Fedora 28, gcc-8.2.1-5, nosmt=force, igb module for Intel I211, using XFS filesystems only. To reproduce, I only do this: connect to VPN using a tunnel (e.g. tun0), sta

4.15.13 kernel panic, ip_rcv_finish, nf_xfrm_me_harder warnings continue to fill dmesg

Apr 11 18:01:34[99194.935520] general protection fault: [#1] SMP Apr 11 18:01:34[99194.935998] Modules linked in: pppoe pppox ppp_generic slhc ip_set_hash_net xt_nat xt_string xt_connmark xt_TCPMSS xt_mark xt_CT xt_set xt_tcpudp ip_set_bitmap_port ip_set nfnetlink iptable_raw iptable_filter

ipv6: stable request

12d94a804946af291e24b80fc53ec86264765781 ipv6: fix NULL dereference in ip6_route_dev_notify() This BUG touches 4.1 4.4 4.9.

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-03-02 19:43, Guillaume Nault wrote: On Thu, Mar 01, 2018 at 10:07:05PM +0200, Denys Fedoryshchenko wrote: On 2018-03-01 22:01, Guillaume Nault wrote: > diff --git a/drivers/net/ppp/ppp_generic.c > b/drivers/net/ppp/ppp_generic.c > index 255a5def56e9..2acf4b0eabd1 100644 > -

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-03-01 22:01, Guillaume Nault wrote: On Tue, Feb 27, 2018 at 07:56:27PM +0100, Guillaume Nault wrote: On Tue, Feb 27, 2018 at 12:58:55PM +0200, Denys Fedoryshchenko wrote: > On 2018-02-23 12:07, Guillaume Nault wrote: > > On Fri, Feb 23, 2018 at 11:41:43AM +0200, Denys Fedor

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-23 12:07, Guillaume Nault wrote: On Fri, Feb 23, 2018 at 11:41:43AM +0200, Denys Fedoryshchenko wrote: On 2018-02-23 11:38, Guillaume Nault wrote: > On Thu, Feb 22, 2018 at 08:51:19PM +0200, Denys Fedoryshchenko wrote: > > I'm using accel-ppp that has unit-cache optio

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-23 12:07, Guillaume Nault wrote: On Fri, Feb 23, 2018 at 11:41:43AM +0200, Denys Fedoryshchenko wrote: On 2018-02-23 11:38, Guillaume Nault wrote: > On Thu, Feb 22, 2018 at 08:51:19PM +0200, Denys Fedoryshchenko wrote: > > I'm using accel-ppp that has unit-cache optio

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-23 12:07, Guillaume Nault wrote: On Fri, Feb 23, 2018 at 11:41:43AM +0200, Denys Fedoryshchenko wrote: On 2018-02-23 11:38, Guillaume Nault wrote: > On Thu, Feb 22, 2018 at 08:51:19PM +0200, Denys Fedoryshchenko wrote: > > I'm using accel-ppp that has unit-cache optio

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-23 11:38, Guillaume Nault wrote: On Thu, Feb 22, 2018 at 08:51:19PM +0200, Denys Fedoryshchenko wrote: I'm using accel-ppp that has unit-cache option, i guess for "reusing" ppp interfaces (because creating a lot of interfaces on BRAS with 8k users quite expensiv

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-22 20:30, Guillaume Nault wrote: On Wed, Feb 21, 2018 at 12:04:30PM -0800, Cong Wang wrote: On Thu, Feb 15, 2018 at 11:31 AM, Guillaume Nault wrote: > On Thu, Feb 15, 2018 at 06:01:16PM +0200, Denys Fedoryshchenko wrote: >> On 2018-02-15 17:55, Guillaume Nault wrote: &g

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-21 20:55, Guillaume Nault wrote: On Wed, Feb 21, 2018 at 12:26:51PM +0200, Denys Fedoryshchenko wrote: It seems even rebuilding seemingly stable version triggering crashes too (but different ones) Different ones? The trace following your message looks very similar to your first

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

It seems even rebuilding seemingly stable version triggering crashes too (but different ones) Maybe it is coincidence, and bug reproducer appeared in network same time i decided to upgrade kernel, as it happened with xt_MSS(and that bug existed for years). Deleted quoting, i added more debug op

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-16 20:48, Guillaume Nault wrote: On Fri, Feb 16, 2018 at 01:13:18PM +0200, Denys Fedoryshchenko wrote: On 2018-02-15 21:42, Guillaume Nault wrote: > On Thu, Feb 15, 2018 at 09:34:42PM +0200, Denys Fedoryshchenko wrote: > > On 2018-02-15 21:31, Guillaume Nault wrote: > >

a lot of WARNING, nf_xfrm_me_harder in 4.15.x

Is there any bug with that or it is just some sort of spam? Cause i am troubleshooting at same time "hard to catch" bug in ppp/pppoe Workload: pppoe bras I am going to try last stable 4.14.x after 1-2 days as well, but probably i noticed this message appeared there as well, under some condition

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-16 20:48, Guillaume Nault wrote: On Fri, Feb 16, 2018 at 01:13:18PM +0200, Denys Fedoryshchenko wrote: On 2018-02-15 21:42, Guillaume Nault wrote: > On Thu, Feb 15, 2018 at 09:34:42PM +0200, Denys Fedoryshchenko wrote: > > On 2018-02-15 21:31, Guillaume Nault wrote: > >

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-15 21:42, Guillaume Nault wrote: On Thu, Feb 15, 2018 at 09:34:42PM +0200, Denys Fedoryshchenko wrote: On 2018-02-15 21:31, Guillaume Nault wrote: > On Thu, Feb 15, 2018 at 06:01:16PM +0200, Denys Fedoryshchenko wrote: > > On 2018-02-15 17:55, Guillaume Nault wrote: > >

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-15 21:31, Guillaume Nault wrote: On Thu, Feb 15, 2018 at 06:01:16PM +0200, Denys Fedoryshchenko wrote: On 2018-02-15 17:55, Guillaume Nault wrote: > On Thu, Feb 15, 2018 at 12:19:52PM +0200, Denys Fedoryshchenko wrote: > > Here we go: > > >

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-15 17:55, Guillaume Nault wrote: On Thu, Feb 15, 2018 at 12:19:52PM +0200, Denys Fedoryshchenko wrote: Here we go: [24558.921549] == [24558.922167] BUG: KASAN: use-after-free in ppp_ioctl+0xa6a/0x1522 [ppp_generic

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-14 19:25, Guillaume Nault wrote: On Wed, Feb 14, 2018 at 06:49:19PM +0200, Denys Fedoryshchenko wrote: On 2018-02-14 18:47, Guillaume Nault wrote: > On Wed, Feb 14, 2018 at 06:29:34PM +0200, Denys Fedoryshchenko wrote: > > On 2018-02-14 18:07, Guillaume Nault wrote: > >

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-14 18:47, Guillaume Nault wrote: On Wed, Feb 14, 2018 at 06:29:34PM +0200, Denys Fedoryshchenko wrote: On 2018-02-14 18:07, Guillaume Nault wrote: > On Wed, Feb 14, 2018 at 03:17:23PM +0200, Denys Fedoryshchenko wrote: > > Hi, > > > > Upgraded kernel to 4.15.3, s

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-14 18:07, Guillaume Nault wrote: On Wed, Feb 14, 2018 at 03:17:23PM +0200, Denys Fedoryshchenko wrote: Hi, Upgraded kernel to 4.15.3, still it crashes after while (several hours, cannot do bisect, as it is production server). dev ppp # gdb ppp_generic.o GNU gdb (Gentoo 7.12.1

ppp/pppoe, still panic 4.15.3 in ppp_push

Hi, Upgraded kernel to 4.15.3, still it crashes after while (several hours, cannot do bisect, as it is production server). dev ppp # gdb ppp_generic.o GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1 <> Reading symbols from ppp_generic.o...done. (gdb) list *ppp_push+0x73 0x681 is in ppp_push (drivers/ne

[PATCH v2] net: make getname() functions return length rather than use int* parameter

Userspace API is not changed. textdata bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: Denys Vlasenko CC: David S. Miller CC: linux-ker...@vger.kernel.org CC: netdev@vger.

Re: [PATCH] net: make getname() functions return length rather than use int* parameter

On 02/12/2018 06:47 PM, David Miller wrote: From: Denys Vlasenko Date: Mon, 12 Feb 2018 15:15:18 +0100 Before: All these functions either return a negative error indicator, or store length of sockaddr into "int *socklen" parameter and return zero on success. "int *sockle

[PATCH] net: make getname() functions return length rather than use int* parameter

Userspace API is not changed. textdata bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: Denys Vlasenko CC: David S. Miller CC: linux-ker...@vger.kernel.org CC: netdev@vger.

4.15.2 kernel panic, nat, ppp bug?

Hello, Got this and then server rebooted with panic (second message). Workload: pppoe BRAS, lost of shapers, ppp interfaces Please let me know if i need to provide more information Feb 12 06:00:58 [13750.606169] WARNING: CPU: 6 PID: 0 at ./include/net/dst.h:256 nf_xfrm_me_harder+0x52/0xd9 [nf

Re: e1000e hardware unit hangs

On 2018-01-24 20:31, Ben Greear wrote: On 01/24/2018 08:34 AM, Neftin, Sasha wrote: On 1/24/2018 18:11, Alexander Duyck wrote: On Tue, Jan 23, 2018 at 3:46 PM, Ben Greear wrote: Hello, Anyone have any more suggestions for making e1000e work better? This is from a 4.9.65+ kernel, with thes

Re: Fw: [Bug 197099] New: Kernel panic in interrupt [l2tp_ppp]

On 2017-10-07 15:09, SviMik wrote: Unfortunately, netconsole has managed to send a kernel panic trace only once, and it's not related to this bug. Looks like something crashes really hard to make netconsole unusable. In some cases i had luck with pstore, when netconsole failed me (especially ne

Question about "prevent dst uses after free" and WARNING in nf_xfrm_me_harder / refcnt / 4.13.3

Hi, I'm running now 4.13.3, is this patch required for 4.13 as well? (it doesnt apply cleanly, as in 4.13 tcp_prequeue use skb_dst_force_safe, so i just renamed it there to skb_dst_force ) This is what i get on PPPoE BRAS on this kernel, patch applied (no idea if its related to patch, but just

Re: [PATCH] bgmac: Remove all offloading features, including GRO.

On 2017-09-16 03:18, Eric Dumazet wrote: On Fri, 2017-09-15 at 17:10 -0700, ros...@gmail.com wrote: Ok fair enough. Will only disable GRO in the driver. Well, do not even try. NETIF_F_SOFT_FEATURES is set by core networking stack in register_netdevice(), ( commit 212b573f5552c60265da721ff9ce3

Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)

On 2017-09-13 20:20, Eric Dumazet wrote: On Wed, 2017-09-13 at 20:12 +0300, Denys Fedoryshchenko wrote: For my case, as load increased now, i am hitting same issue (i tried to play with quantum / bursts as well, didnt helped): tc -s -d class show dev eth3.777 classid 1:111;sleep 5;tc -s -d

Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)

On 2017-09-13 19:55, Eric Dumazet wrote: On Wed, 2017-09-13 at 09:42 -0700, Eric Dumazet wrote: On Wed, 2017-09-13 at 19:27 +0300, Denys Fedoryshchenko wrote: > On 2017-09-13 19:16, Eric Dumazet wrote: > > On Wed, 2017-09-13 at 18:34 +0300, Denys Fedoryshchenko wrote: > >> W

Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)

On 2017-09-13 19:16, Eric Dumazet wrote: On Wed, 2017-09-13 at 18:34 +0300, Denys Fedoryshchenko wrote: Well, probably i am answering my own question, removing estimator from classes seems drastically improve situation. It seems estimator has some issues that cause shaper to behave incorrectly

Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)

On 2017-09-13 18:51, Eric Dumazet wrote: On Wed, 2017-09-13 at 18:20 +0300, Denys Fedoryshchenko wrote: Hi, I noticed after increasing bandwidth over some amount HTB started to throttle classes it should not throttle. Also estimated rate in htb totally wrong, while byte counters is correct

Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)

bottleneck by CPU load measurements. On 2017-09-13 18:20, Denys Fedoryshchenko wrote: Hi, I noticed after increasing bandwidth over some amount HTB started to throttle classes it should not throttle. Also estimated rate in htb totally wrong, while byte counters is correct. Is there any overflow

HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)

Hi, I noticed after increasing bandwidth over some amount HTB started to throttle classes it should not throttle. Also estimated rate in htb totally wrong, while byte counters is correct. Is there any overflow or something? X520 card (but XL710 same) br1 8000.90e2ba86c38c n

Re: ipset losing entries on its own

On 2017-09-06 13:08, Akshat Kakkar wrote: I am having ipset 6.32 The hash type is hash:ip I am adding/deleting IP addresses to it dynamically using scripts. However, it has been observed that at times few IPs (3-4 out of 4000) are not found in the set though it was added. Also, logs show there

Re: nf_nat_pptp 4.12.3 kernel lockup/reboot

On 2017-08-25 08:21, Florian Westphal wrote: Denys Fedoryshchenko wrote: >>> I am trying to upgrade kernel 4.11.8 to 4.12.3 (it is a nat/router, handling >>> approx 2gbps of pppoe users traffic) and noticed that after while server >>> rebooting(i have set reboot on

Re: nf_nat_pptp 4.12.3 kernel lockup/reboot

On 2017-07-24 19:20, Florian Westphal wrote: Florian Westphal wrote: Denys Fedoryshchenko wrote: > Hi, > > I am trying to upgrade kernel 4.11.8 to 4.12.3 (it is a nat/router, handling > approx 2gbps of pppoe users traffic) and noticed that after while server > rebooting(i hav

Re: nf_nat_pptp 4.12.3 kernel lockup/reboot

On 2017-07-24 19:20, Florian Westphal wrote: Florian Westphal wrote: Denys Fedoryshchenko wrote: > Hi, > > I am trying to upgrade kernel 4.11.8 to 4.12.3 (it is a nat/router, handling > approx 2gbps of pppoe users traffic) and noticed that after while server > rebooting(i hav

Re: nf_nat_pptp 4.12.3 kernel lockup/reboot

On 2017-07-24 19:20, Florian Westphal wrote: Florian Westphal wrote: Denys Fedoryshchenko wrote: > Hi, > > I am trying to upgrade kernel 4.11.8 to 4.12.3 (it is a nat/router, handling > approx 2gbps of pppoe users traffic) and noticed that after while server > rebooting(i hav

nf_nat_pptp 4.12.3 kernel lockup/reboot

Hi, I am trying to upgrade kernel 4.11.8 to 4.12.3 (it is a nat/router, handling approx 2gbps of pppoe users traffic) and noticed that after while server rebooting(i have set reboot on panic and etc). I can't run serial console, and in pstore / netconsole there is nothing. Best i got is some v

bug in "PCI: Support INTx masking on ConnectX-4 with firmware x.14.1100+"?

+ /* Reading from resource space should be 32b aligned */ + fw_maj_min = ioread32be(fw_ver); + fw_sub_min = ioread32be(fw_ver + 1); + fw_major = fw_maj_min & 0x; + fw_minor = fw_maj_min >> 16; + fw_subminor = fw_sub_min & 0x; Maybe second read should be

Re: [PATCH v2] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

On 06/21/2017 09:24 PM, Marcelo Ricardo Leitner wrote: On Wed, Jun 21, 2017 at 07:03:27PM +0200, Denys Vlasenko wrote: This function compiles to 147 bytes of machine code. 13 callsites. I'm no expert on SCTP events, but quick reading of SCTP docs tells me that SCTP events are not happeni

[PATCH v2] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

igned-off-by: Denys Vlasenko CC: Vlad Yasevich CC: Neil Horman CC: David Miller CC: linux-s...@vger.kernel.org CC: netdev@vger.kernel.org CC: linux-ker...@vger.kernel.org --- Changed since v1: * reindented function argument list net/sctp/ulpevent.c | 2 +- 1 file changed, 1 insertion(+), 1 del

[PATCH] net/sctp/ulpevent.c: Deinline sctp_ulpevent_set_owner, save 1616 bytes

igned-off-by: Denys Vlasenko CC: Vlad Yasevich CC: Neil Horman CC: David Miller CC: linux-s...@vger.kernel.org CC: netdev@vger.kernel.org CC: linux-ker...@vger.kernel.org --- net/sctp/ulpevent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sctp/ulpevent.c b/net

[PATCH] liquidio: stop using huge static buffer, save 4096k in .data

Only compile-tested - I don't have the hardware. >From code inspection, octeon_pci_write_core_mem() appears to be safe wrt unaligned source. In any case, u8 fbuf[] was not guaranteed to be aligned anyway. Signed-off-by: Denys Vlasenko CC: Felix Manlunas CC: Prasad Kanneganti C

Re: [PATCH net] netfilter: xt_TCPMSS: add more sanity tests on tcph->doff

On 2017-04-08 23:24, Pablo Neira Ayuso wrote: On Mon, Apr 03, 2017 at 10:55:11AM -0700, Eric Dumazet wrote: From: Eric Dumazet Denys provided an awesome KASAN report pointing to an use after free in xt_TCPMSS I have provided three patches to fix this issue, either in xt_TCPMSS or in

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On 2017-04-03 15:09, Eric Dumazet wrote: On Mon, 2017-04-03 at 11:10 +0300, Denys Fedoryshchenko wrote: I modified patch a little as: if (th->doff * 4 < sizeof(_tcph)) { par->hotdrop = true; WARN_ON_ONCE(!tcpinfo->option); return false; } And it did triggered WARN once at

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On 2017-04-02 20:26, Eric Dumazet wrote: On Sun, 2017-04-02 at 10:14 -0700, Eric Dumazet wrote: Could that be that netfilter does not abort earlier if TCP header is completely wrong ? Yes, I wonder if this patch would be better, unless we replicate the th->doff sanity check in all netfilter

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On 2017-04-02 15:32, Eric Dumazet wrote: On Sun, 2017-04-02 at 15:25 +0300, Denys Fedoryshchenko wrote: > */ I will add also WARN_ON_ONCE(tcp_hdrlen >= 15 * 4) before, for curiosity, if this condition are triggered. Is it fine like that? Sure. It didnt triggered WARN_ON, and wit

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On 2017-04-02 15:19, Eric Dumazet wrote: On Sun, 2017-04-02 at 04:54 -0700, Eric Dumazet wrote: On Sun, 2017-04-02 at 13:45 +0200, Florian Westphal wrote: > Eric Dumazet wrote: > > - for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i += optlen(opt, i)) { > > + for (i = si

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On 2017-04-02 14:45, Florian Westphal wrote: Eric Dumazet wrote: - for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i += optlen(opt, i)) { + for (i = sizeof(struct tcphdr); i < tcp_hdrlen - TCPOLEN_MSS; i += optlen(opt, i)) { if (opt[i] == TCPOPT_MSS && opt[i+1]

KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

Repost, due being sleepy missed few important points. I am searching reasons of crashes for multiple conntrack enabled servers, usually they point to conntrack, but i suspect use after free might be somewhere else, so i tried to enable KASAN. And seems i got something after few hours, and it l

finally found nasty use-after-free bug? 4.10.8

I am searching reasons of crashes for multiple NAT servers, and tried to enable KASAN. It seems i got something, and it looks very possible related to all crashes, because on all that servers i have MSS. [25181.855611] == [25181.

Re: probably serious conntrack/netfilter panic, 4.8.14, timers and intel turbo

I am not sure if it is same issue, but panics still happen, but much less. Same server, nat. I will upgrade to latest 4.10.x build, because for this one i dont have files anymore (for symbols and etc). [864288.511464] Modules linked in: nf_conntrack_netlink nf_nat_pptp nf_nat_proto_gre xt_TCP

__nf_conntrack_find_get - NMI watchdog, 4.10.5

Hi, While applying/removing shapers on few thousands of ppp interfaces got pppoe server rebooted with this message: [51306.144984] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0] [51306.145319] Modules linked in: sch_sfq cls_fw act_police cls_u32 sch_ingress sch_htb pppoe p

4.9.4 panic, nf_conntrack_tuple_taken

Hi, Seems i'm quite "lucky" and hitting another bug. This time it is different server, but i believe i've seen this bug on few pppoe servers, but here it is happening once per 1-2 days. Out of tree patch applied, to optimize gc heuristics. I don't exclude (but very small chance) hardware issu

Re: 4.9 conntrack performance issues

On 2017-01-30 13:26, Guillaume Nault wrote: On Sun, Jan 15, 2017 at 01:05:58AM +0200, Denys Fedoryshchenko wrote: Hi! Sorry if i added someone wrongly to CC, please let me know, if i should remove. I just run successfully 4.9 on my nat several days ago, and seems panic issue disappeared

Re: 4.9 conntrack performance issues

On 2017-01-15 02:29, Florian Westphal wrote: Denys Fedoryshchenko wrote: On 2017-01-15 01:53, Florian Westphal wrote: >Denys Fedoryshchenko wrote: > >I suspect you might also have to change > >1011 } else if (expired_count) { >1012 gc_work->nex

Re: 4.9 conntrack performance issues

On 2017-01-15 01:53, Florian Westphal wrote: Denys Fedoryshchenko wrote: [ CC Nicolas since he also played with gc heuristics in the past ] Sorry if i added someone wrongly to CC, please let me know, if i should remove. I just run successfully 4.9 on my nat several days ago, and seems

4.9 conntrack performance issues

Hi! Sorry if i added someone wrongly to CC, please let me know, if i should remove. I just run successfully 4.9 on my nat several days ago, and seems panic issue disappeared. But i started to face another issue, it seems garbage collector is hogging one of CPU's. Here is my data: 2xE5-2640 v

Re: probably serious conntrack/netfilter panic, 4.8.14, timers and intel turbo

On 2017-01-11 19:22, Guillaume Nault wrote: Cc: netfilter-de...@vger.kernel.org, I'm afraid I'll need some help for this case. On Sat, Dec 17, 2016 at 09:48:13PM +0200, Denys Fedoryshchenko wrote: Hi, I posted recently several netfilter related crashes, didn't got any answer

Re: 4.9.2 panic, __skb_flow_dissect, gro?

Yes, it is in the list (ixgbe) On 2017-01-11 02:16, Ian Kumlien wrote: Added David Miller to CC since he said it was queued for stable, maybe he can comment On Wed, Jan 11, 2017 at 12:49 AM, Denys Fedoryshchenko wrote: It seems this patch solve issue. I hope it will go to stable asap

Re: 4.9.2 panic, __skb_flow_dissect, gro?

skb_header_pointer. On 2017-01-11 01:26, Denys Fedoryshchenko wrote: Hi, Got panic message on 4.9.2 with latest patches from stable-queue, probably it affects all 4.9 version Panic message: dmesg-erst-6374119981415661569:<6>[ 23.110324] ip_set: protocol 6 dmesg-erst-6374119981415661569:<1>[ 28

4.9.2 panic, __skb_flow_dissect, gro?

Hi, Got panic message on 4.9.2 with latest patches from stable-queue, probably it affects all 4.9 version Panic message: dmesg-erst-6374119981415661569:<6>[ 23.110324] ip_set: protocol 6 dmesg-erst-6374119981415661569:<1>[ 28.117455] BUG: unable to handle kernel NULL pointer dereference

probably serious conntrack/netfilter panic, 4.8.14, timers and intel turbo

Hi, I posted recently several netfilter related crashes, didn't got any answers, one of them started to happen quite often on loaded NAT (17Gbps), so after trying endless ways to make it stable, i found out that in backtrace i can often see timers, and this bug probably appearing on older rel

Kernel panic in netfilter 4.8.10 probably on conntrack -L

Hi! I have quite loaded NAT server (approx 17Gbps of traffic) where periodic "conntrack -L" might trigger once per day kernel panic. I am not definitely sure it is triggered exactly at running tool, or just by enabling events. Here is panic message: [221287.380762] general protection fault:

Re: SNAT --random & fully is not actually random for ips

On 2016-11-28 13:29, Pablo Neira Ayuso wrote: On Mon, Nov 28, 2016 at 01:12:07PM +0200, Denys Fedoryshchenko wrote: On 2016-11-28 13:06, Pablo Neira Ayuso wrote: >Why does your patch reverts NF_NAT_RANGE_PROTO_RANDOM_FULLY? Ops, sorry i just did mistake with files, actually it is in reve

Re: SNAT --random & fully is not actually random for ips

On 2016-11-28 13:06, Pablo Neira Ayuso wrote: On Mon, Nov 28, 2016 at 12:45:59PM +0200, Denys Fedoryshchenko wrote: Hello, I noticed that if i specify -j SNAT with options --random --random-fully still it keeps persistence for source IP. So you specify both? Actually truly random src ip

SNAT --random & fully is not actually random for ips

Hello, I noticed that if i specify -j SNAT with options --random --random-fully still it keeps persistence for source IP. Actually truly random src ip required in some scenarios like links balanced by IPs, but seems since 2012 at least it is not possible. But actually if i do something like:

Huge static buffer in liquidio

Hello, I would like to discuss this commit: commit d3d7e6c65f75de18ced10a98595a847f9f95f0ce Author: Raghu Vatsavayi Date: Tue Jun 21 22:53:07 2016 -0700 liquidio: Firmware image download This patch has firmware image related changes for: firmware release upon failure, support lat

Re: kernel panic TPROXY , vanilla 4.7.1

On 2016-08-17 19:04, Eric Dumazet wrote: On Wed, 2016-08-17 at 08:42 -0700, Eric Dumazet wrote: On Wed, 2016-08-17 at 17:31 +0300, Denys Fedoryshchenko wrote: > Hi! > > Tried to run squid on latest kernel, and hit a panic > Sometimes it just shows warning in dmesg (but doesnt w

kernel panic TPROXY , vanilla 4.7.1

Hi! Tried to run squid on latest kernel, and hit a panic Sometimes it just shows warning in dmesg (but doesnt work properly) [ 75.701666] IPv4: Attempt to release TCP socket in state 10 88102d430780 [ 83.866974] squid (2700) used greatest stack depth: 12912 bytes left [ 87.506644] IPv

Re: 4.6.3, pppoe + shaper workload, skb_panic / skb_push / ppp_start_xmit

On 2016-08-09 00:05, Guillaume Nault wrote: On Mon, Aug 08, 2016 at 02:25:00PM +0300, Denys Fedoryshchenko wrote: On 2016-08-01 23:59, Guillaume Nault wrote: > Do you still have the vmlinux file with debug symbols that generated > this panic? Sorry for delay, i didn't had same i

Re: 4.6.3, pppoe + shaper workload, skb_panic / skb_push / ppp_start_xmit

On 2016-08-01 23:59, Guillaume Nault wrote: Do you still have the vmlinux file with debug symbols that generated this panic? Sorry for delay, i didn't had same image on all servers and probably i found cause of panic, but still testing on several servers. If i remove SFQ qdisc from ppp shapers,

Re: 4.6.3, pppoe + shaper workload, skb_panic / skb_push / ppp_start_xmit

On 2016-08-01 23:59, Guillaume Nault wrote: On Thu, Jul 28, 2016 at 02:28:23PM +0300, Denys Fedoryshchenko wrote: [ 5449.904989] CPU: 1 PID: 6359 Comm: ip Not tainted 4.7.0-build-0109 #2 [ 5449.905255] Hardware name: Supermicro X10SLM+-LN4F/X10SLM+-LN4F, BIOS 3.0 04/24/2015 [ 5449.905712

Re: 4.6.3, pppoe + shaper workload, skb_panic / skb_push / ppp_start_xmit

how this corruption happened is going to be hard without a way to reproduce the problem. Denys, can you confirm you're using a vanilla kernel? Also I guess the ppp devices and tc settings are handled by accel-ppp. If so, can you share more info about your setup (accel-ppp.conf, radius attri

Re: kernel panic, __neigh_notify, 4.7.0-rc7, Workqueue: events_power_efficient neigh_periodic_work

On 2016-07-24 21:40, nuclear...@nuclearcat.com wrote: Different hardware, but same workload. Seems different bug, happened at least twice on this unit (both kernel panic messages here) As additional sidenote, that might be useful (found in commits, that proxy arp might induce this bug, such as i

[PATCH] e1000e: prevent division by zero if TIMINCA is zero

rem = do_div(temp, incvalue); This change makes kernel survive this, and users report that NIC does work after this change. Since on real hardware incvalue is never zero, this should not affect real hardware use case. Signed-off-by: Denys Vlasenko CC: Jeff Kirsher CC: "Ruinskiy

Re: [PATCH 1/3] e1000e: e1000e_cyclecounter_read(): incvalue is 32 bits, not 64

On 04/19/2016 10:57 PM, Jeff Kirsher wrote: > On Tue, 2016-04-19 at 14:34 +0200, Denys Vlasenko wrote: >> "incvalue" variable holds a result of "er32(TIMINCA) & >> E1000_TIMINCA_INCVALUE_MASK" >> and used in "do_div(temp, incvalue)" as a divi

[PATCH 2/3] e1000e: e1000e_cyclecounter_read(): fix er32(SYSTIML) overflow check

f. "systimel_1 < systimel_2" is false, we think it's an overflow, we read "systimeh = er32(SYSTIMH)" which meanwhile had incremented, and use "(systimeh << 32) + systimel_2" value which is 2^32 too large. Signed-off-by: Denys Vlasenko CC: Jeff Kirsher CC:

[PATCH 1/3] e1000e: e1000e_cyclecounter_read(): incvalue is 32 bits, not 64

"incvalue" variable holds a result of "er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK" and used in "do_div(temp, incvalue)" as a divisor. Thus, "u64 incvalue" declaration is probably a mistake. Even though it seems to be a harmless one, let's fix it.

[PATCH 3/3] e1000e: e1000e_cyclecounter_read(): do overflow check only if needed

increments. We do two reads, er32(SYSTIML) and er32(SYSTIMH), in this order. Even if one increment happens between them, the overflow into SYSTIMH is impossible, and we can avoid doing another er32(SYSTIML) read and overflow check. Signed-off-by: Denys Vlasenko CC: Jeff Kirsher CC: Jesse

[PATCH] drivers/net/ethernet/jme.c: Deinline jme_reset_mac_processor, save 2816 bytes

This function compiles to 895 bytes of machine code. Clearly, this isn't a time-critical function. For one, it has a number of udelay(1) calls. Signed-off-by: Denys Vlasenko CC: David S. Miller CC: linux-ker...@vger.kernel.org CC: netdev@vger.kernel.org --- drivers/net/ethernet/jme.

[PATCH] net: force inlining of netif_tx_start/stop_queue, sock_hold, __sock_put

atch fixes this via s/inline/__always_inline/. Code size decrease after the patch is ~2.5k: text data bss dec hex filename 56719876 56364551 36196352 149280779 8e5d80b vmlinux_before 56717440 56364551 36196352 149278343 8e5ce87 vmlinux Signed-off-by: Denys Vlasenko C

Re: kernel panic in 4.2.3, rb_erase in sch_fq

at least one more person with similar conntrack crashes on latest kernels. On 2015-11-04 06:46, Eric Dumazet wrote: On Wed, 2015-11-04 at 06:25 +0200, Denys Fedoryshchenko wrote: On 2015-11-04 00:06, Cong Wang wrote: > On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko > wrote:

4.3.0, neighbour: arp_cache: neighbor table overflow! and panic

Hi I have several pppoe servers running under older kernels, and upgraded two of them to 4.3.0 After that, one of them randomly rebooting and stacktrace always different. Also i noticed message appearing, that didnt exist before on older kernels, appearing on both now: "neighbour: arp_cache:

Re: kernel panic in 4.2.3, rb_erase in sch_fq

On 2015-11-04 06:58, Eric Dumazet wrote: On Tue, 2015-11-03 at 20:46 -0800, Eric Dumazet wrote: On Wed, 2015-11-04 at 06:25 +0200, Denys Fedoryshchenko wrote: > On 2015-11-04 00:06, Cong Wang wrote: > > On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko > > wrote: > >>

Re: HTB, HFSC, PIE, FIFO stuck on 2.4Gbit on default values

On 2015-11-04 06:28, Eric Dumazet wrote: On Wed, 2015-11-04 at 06:12 +0200, Denys Fedoryshchenko wrote: Just enabling gro or gso (or together) is fine there. Thanks for advice. Seems only tso causing problems. Also i guess if i keep tso disabled, it will solve my MTU issues (i had once issue

Re: kernel panic in 4.2.3, rb_erase in sch_fq

On 2015-11-04 00:06, Cong Wang wrote: On Mon, Nov 2, 2015 at 6:11 AM, Denys Fedoryshchenko wrote: Hi! Actually seems i was getting this panic for a while (once per week) on loaded pppoe server, but just now was able to get full panic message. After checking commit logs on sch_fq.c i didnt

Re: HTB, HFSC, PIE, FIFO stuck on 2.4Gbit on default values

On 2015-11-03 23:23, Eric Dumazet wrote: On Tue, 2015-11-03 at 22:24 +0200, Denys Fedoryshchenko wrote: I wont argue on that, you are right. Ok, then it is a bit offtopic in current case, different setup, but i know this one has easy to reproduce issues with offloading. but this is bug

Re: HTB, HFSC, PIE, FIFO stuck on 2.4Gbit on default values

On 2015-11-03 21:49, Eric Dumazet wrote: Well, I am telling you. Say no to people advising to turn off GRO/TSO. If you were the guy adviding others to do so, it is time to see the light. Lets fix the bugs if any, instead of spreading disinformation. I am so tired of telling these very simple

Re: HTB, HFSC, PIE, FIFO stuck on 2.4Gbit on default values

On 2015-11-03 21:11, Eric Dumazet wrote: On Tue, 2015-11-03 at 19:33 +0200, Denys Fedoryshchenko wrote: Hi Recently i was testing shaping over single 10G cards, for speeds up to 3-4Gbps, and noticed interesting effect. Shaping scheme: Incoming bandwidth comes to switch port, with access vlan

HTB, HFSC, PIE, FIFO stuck on 2.4Gbit on default values

Hi Recently i was testing shaping over single 10G cards, for speeds up to 3-4Gbps, and noticed interesting effect. Shaping scheme: Incoming bandwidth comes to switch port, with access vlan 100 Outgoing bandwidth leaves switch port with access vlan 200 Linux with Intel X710 connected to trunk p

Re: kernel panic in 4.2.3, rb_erase in sch_fq

On 2015-11-02 18:12, Eric Dumazet wrote: On Mon, 2015-11-02 at 17:58 +0200, Denys Fedoryshchenko wrote: On 2015-11-02 17:24, Eric Dumazet wrote: > On Mon, 2015-11-02 at 16:11 +0200, Denys Fedoryshchenko wrote: >> Hi! >> >> Actually seems i was getting this panic for a whi

Re: kernel panic in 4.2.3, rb_erase in sch_fq

On 2015-11-02 17:24, Eric Dumazet wrote: On Mon, 2015-11-02 at 16:11 +0200, Denys Fedoryshchenko wrote: Hi! Actually seems i was getting this panic for a while (once per week) on loaded pppoe server, but just now was able to get full panic message. After checking commit logs on sch_fq.c i

  1   2   3   >