Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next_bit

From: Andreas Hartmann
Date: Mon Apr 22 2019 - 14:52:11 EST

Next message: Deepak Singh Rawat: "Re: [PATCH 6/9] drm/vmwgfx: Implement an infrastructure for write-coherent resources"
Previous message: Oscar Gomez Fuente: "[PATCH] staging: ion: solve warning symbol was not declared"
In reply to: Florian Westphal: "Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next_bit"
Next in thread: Florian Westphal: "Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next_bit"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 22.04.19 at 19:27 Florian Westphal wrote:
> Andreas Hartmann <andihartmann@xxxxxxxxxxxxxxx> wrote:
>> Since 4.19.17, I'm facing problems during streaming of videos I've never seen before. This means:
>>
>> - video from internet stutters although enough data flow can be seen in bmon.
>> - gpu is locked:
>> radeon 0000:0a:00.0: ring 0 stalled for more than 14084msec
>> radeon 0000:0a:00.0: GPU lockup (current fence id 0x0000000000053ed7 last fence id 0x0000000000053f0f on ring 0)
>> - The connection of videos streamed locally by the machine for a TV suddenly breaks (upnp - serviio as server).
>>
>> After very long time of testing, I detected, that removing the complete patch series for 4.19.17 regarding netfilter: nf_conncount makes the problem disappear.
>>
>> Please remove / fix this patchset!
>
> The state in 4.19.y is same as in mainline.

I don't use mainline.

> Could you at least tell us how you're using nf_conncount (nf/iptables
> rules)?

The host is a Ryzen 7 1700 CPU, containing 4 kvm VMs, one ethernet interface, 2 bridges (2 different networks). One VM works as a bridge between both networks.
The iptables rules are the following:

# Generated by iptables-save v1.6.2 on Mon Apr 22 20:19:30 2019
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [4423:248703]
-A INPUT -s 127.0.0.1/32 -d 239.255.255.250/32 -i lo -p udp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -d 255.255.255.255/32 -p udp -j ACCEPT
-A INPUT -d 224.0.0.1/32 -j ACCEPT
-A INPUT -s 127.0.0.1/32 -d 127.0.0.2/32 -i lo -j ACCEPT
-A INPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.22.0/24 -j ACCEPT
-A INPUT -j LOG --log-prefix "In Input gesperrt: "
-A INPUT -s 169.254.2.1/32 -d 169.254.2.2/32 -i br1 -p tcp -m tcp --sport 80 -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 224.0.0.22/32 -o lo -p igmp -j ACCEPT
-A OUTPUT -d 192.168.6.173/32 -o br1 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -s 169.254.2.2/32 -d 239.255.255.250/32 -o br1 -p udp -j DROP
-A OUTPUT -s 192.168.22.6/32 -d 224.0.0.251/32 -o br1 -p udp -j ACCEPT
-A OUTPUT -s 127.0.0.1/32 -d 239.255.255.250/32 -o lo -p udp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 255.255.255.255/32 -o br1 -p udp -m udp --dport 1900 -j ACCEPT
-A OUTPUT -s 127.0.0.1/32 -d 127.255.255.255/32 -o br1 -p udp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.0.0.250/32 -o br1 -p igmp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.255.255.250/32 -o br1 -p igmp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.255.255.250/32 -o br1 -p udp -m udp --dport 1900 -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.1.1.1/32 -o br1 -p udp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 239.1.1.1/32 -o br1 -p igmp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -d 224.0.0.251/32 -o br1 -p igmp -j ACCEPT
-A OUTPUT -s 192.168.22.6/32 -p tcp -m tcp --dport 1935 -j ACCEPT
-A OUTPUT -s 192.168.22.0/24 -d 192.168.3.0/24 -j ACCEPT
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.2/32 -o lo -j ACCEPT
-A OUTPUT -s 127.0.0.1/32 -d 127.0.0.1/32 -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -s 192.168.22.0/24 -d 192.168.22.0/24 -j ACCEPT
-A OUTPUT -j LOG --log-prefix "In Output gesperrt: "
-A OUTPUT -s 169.254.2.2/32 -d 169.254.2.1/32 -o br1 -p tcp -m tcp --dport 80 -j ACCEPT
COMMIT
# Completed on Mon Apr 22 20:19:30 2019

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
ether ......... txqueuelen 1000 (Ethernet)
RX packets 1376 bytes 139220 (135.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1512
inet 192.168.22.6 netmask 255.255.255.0 broadcast 192.168.22.255
ether ......... txqueuelen 1000 (Ethernet)
RX packets 1161816 bytes 2806028482 (2.6 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1427306 bytes 2032637199 (1.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1512
ether ......... txqueuelen 1000 (Ethernet)
RX packets 119990 bytes 110191277 (105.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 204094 bytes 234832004 (223.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 36 memory 0xfc8c0000-fc8e0000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 2474 bytes 16626724 (15.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2474 bytes 16626724 (15.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1512
ether ............ txqueuelen 1000 (Ethernet)
RX packets 1164109 bytes 3022066875 (2.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 984171 bytes 56305461 (53.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
ether ......... txqueuelen 1000 (Ethernet)
RX packets 1044034 bytes 66058845 (62.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1220061 bytes 3029057018 (2.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
ether .......... txqueuelen 1000 (Ethernet)
RX packets 1216429 bytes 3011285937 (2.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1038397 bytes 65034965 (62.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
ether ............ txqueuelen 1000 (Ethernet)
RX packets 19875 bytes 29951674 (28.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 23283 bytes 13365374 (12.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1512
ether ............ txqueuelen 1000 (Ethernet)
RX packets 363077 bytes 24587603 (23.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 823604 bytes 2081985009 (1.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

> Could you test with debugging (KASAN, CONFIG_PROVE_RCU etc). enabled?

I don't know what you're expecting here exactly - sorry. Testing is not that easy as I don't know how to force the error.
After removing the "netfilter: nf_conncount" patches, I didn't see the problem any more - same as before 4.19.17.

> I'm really surprised about this report, before the backport nf_conncount
> caused frequent kernel crashes, how does reverting even work...?

I never had any problem w/ iptables before - it's been working always just as it should!

Thanks!
Regards
Andreas

Next message: Deepak Singh Rawat: "Re: [PATCH 6/9] drm/vmwgfx: Implement an infrastructure for write-coherent resources"
Previous message: Oscar Gomez Fuente: "[PATCH] staging: ion: solve warning symbol was not declared"
In reply to: Florian Westphal: "Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next_bit"
Next in thread: Florian Westphal: "Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next_bit"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]