Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#63855 - Kernel panics with 5.3

Attached to Project: Arch Linux
Opened by persson (persson) - Friday, 20 September 2019, 10:06 GMT
Task Type Bug Report
Category Kernel
Status Unconfirmed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No



Getting kernel panics with 5.3.0-arch1 when trying to use wireguard (sending traffic via a wg interface) or disabling IPv6 via sysctl (ie sysctl -w net.ipv6.conf.all.disable_ipv6=1). These are the operation that reliably trigger the panic. I get other random panics too, mostly when using the network, but I can't reliably reproduce them; it's almost certainly network-related however.

Attached sample kernel panic logs.
This task depends upon

Comment by mike (mbalajew) - Saturday, 21 September 2019, 03:05 GMT
these are related, I think:
Comment by persson (persson) - Sunday, 22 September 2019, 16:58 GMT
Still present with 5.3.1, now I can reliably trigger the panics by using IPv6 (eg ping -6 Attached a sample panic log.
Booting with ipv6.disable=1 seems to fix the problems, but of course it's just a workaround.
   bug.txt (7.3 KiB)
Comment by loqs (loqs) - Sunday, 22 September 2019, 17:37 GMT
@persson does applying the patch from stop the panics?
Comment by mike (mbalajew) - Monday, 23 September 2019, 00:51 GMT
@persson, strangely enough, using IPv6 (eg ping -6 does not trigger any panics for me (running vanilla 5.3.1). For me, so far, the only reliably way to trigger a panic is by running wireguard with IPv6
Comment by persson (persson) - Monday, 23 September 2019, 16:16 GMT
@loqs, the patched kernel seems indeed to fix the issue, thanks! I've been using IPv6 for some hours now without panics. Wireguard works as well. When can be expect to see the patch included in the official arch kernel?
Comment by persson (persson) - Monday, 23 September 2019, 16:37 GMT
Instructions for others who want to patch the kernel: basically, follow with the following changes:

- install flex and bison if you don't have them already
- the source tree is different, you have to enter $HOME/build/linux/trunk
- put the patch file into that directory and rename it to end in .patch (eg ipv6.patch)
- edit PKGBUILD to add "ipv6.patch" to the source array, eg

config # the main kernel config file
60-linux.hook # pacman hook for depmod
90-linux.hook # pacman hook for initramfs regeneration
linux.preset # standard config files for mkinitcpio ramdisk
ipv6.patch # test patch for kernel

- edit PKGBUILD to change the base name, eg pkgbase=linux-custom (or whatever you want, as long as it's not "linux")
- run updpkgsums
- import the trusted PGP keys listed in the PKGBUILD (eg gpg --recv-keys 8218F88849AAC522E94CF470A5E9288C4FA415FA)
- run makepkg -s (takes a LONG time). Make sure you see the messages indicating that the patch has been applied, otherwise you'll be building a standard kernel. Example:
-> Applying patch ipv6.patch...
patching file drivers/net/vrf.c
patching file include/net/ip6_route.h
patching file net/ipv6/fib6_rules.c
patching file net/ipv6/ip6_fib.c
patching file net/ipv6/route.c
patching file net/l3mdev/l3mdev.c

- install the kernel and headers packages as explained in the article, eg pacman -U linux-custom-headers-5.3.1.arch1-1-x86_64.pkg.tar.xz linux-custom-5.3.1.arch1-1-x86_64.pkg.tar.xz
- run grub-mkconfig -o /boot/grub/grub.cfg and make sure that your linux-custom kernel is detected and added to grub.cfg. Inspect the generated grub.cfg if needed.
- reboot, uname -a should show thhat you're running the custom kernel (example output: Linux lapt1 5.3.1-arch1-1-custom #2 SMP PREEMPT Mon Sep 23 18:00:03 CEST 2019 x86_64 GNU/Linux)
Comment by loqs (loqs) - Monday, 23 September 2019, 17:04 GMT
@persson the patch is just to locate the cause then upstream will need to correct the issue and then the fix will be included in the arch package. contains another test patch to locate the cause.
Comment by persson (persson) - Monday, 23 September 2019, 17:27 GMT
@loqs yeah, seems to be fine with the latest patch as well. Let me try to revert only and see.
Comment by persson (persson) - Monday, 23 September 2019, 18:06 GMT
Yes, reverting just that one fixes it for me as well.
Comment by loqs (loqs) - Monday, 23 September 2019, 18:34 GMT
Thank you for identifying the cause. Can you please report the issue either to [1] under Component: IPV6 Product: Networking or the mailing list
General information to include in the report is detailed in [2] if you use the mailing list please CC Wei Wang who authored the causal commit.

I had not read as zx2c4 is investigating there may be no need to open a separate upstream report.