Re: Overlapping AllowedIPs Configuration

2019-05-12 Thread Aleksa Sarai 
On 2019-05-11, Henning Reich  wrote:
> No, I think its correct behaviour.
> If you have overlapping networks  the more specific route is preferred.
> 10.10.10.0/24 overrule 10.10.0.0/16.
> If the subnets are the same, the last one is the more specific (because
> most recent one) and should be used.

But none of the AllowedIPs is "more specific" -- they're all /32.

In addition, the preferred one is the last one in the config file
(presumably because it gets configured last) even if you use more
specific route earlier in the config.

> And in germany, we say (literal translation): You're allowed to shoot
> yourself in the knee. (to be self-defeating) :-)

In English we say "shooting yourself in the foot" (hence a "foot-gun").
But I'd argue that you should avoid designing foot-guns when possible.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[PATCH 2/2] [zinc] add accelerated poly1305 from openssl/cryptograms

2019-05-12 Thread Shawn Landden 
Unfortunately I am not seeing a speed up with this patch,
but it does decrease CPU usage.

Again, this will not work until ppc has its own version of the
may_use_simd() function that allows simd in the softirq context
that WireGuard runs in.

Signed-off-by: Shawn Landden 
---
 src/crypto/Kbuild.include |   10 +-
 src/crypto/zinc/chacha20/chacha20-ppc.pl  |3 +
 .../zinc/{chacha20 => perlasm}/ppc-xlate.pl   |0
 src/crypto/zinc/poly1305/poly1305-arm-glue.c  |   65 -
 src/crypto/zinc/poly1305/poly1305-ppc-glue.c  |   94 +
 src/crypto/zinc/poly1305/poly1305-ppc.pl  | 1989 +
 src/crypto/zinc/poly1305/poly1305-ppcfp.pl|  749 +++
 src/crypto/zinc/poly1305/poly1305.c   |   69 +
 8 files changed, 2910 insertions(+), 69 deletions(-)
 rename src/crypto/zinc/{chacha20 => perlasm}/ppc-xlate.pl (100%)
 create mode 100644 src/crypto/zinc/poly1305/poly1305-ppc-glue.c
 create mode 100644 src/crypto/zinc/poly1305/poly1305-ppc.pl
 create mode 100755 src/crypto/zinc/poly1305/poly1305-ppcfp.pl

diff --git a/src/crypto/Kbuild.include b/src/crypto/Kbuild.include
index 4e05181..ea18ce5 100644
--- a/src/crypto/Kbuild.include
+++ b/src/crypto/Kbuild.include
@@ -34,30 +34,32 @@ zinc-$(CONFIG_ZINC_ARCH_X86_64) += 
poly1305/poly1305-x86_64.o
 zinc-$(CONFIG_ZINC_ARCH_ARM) += poly1305/poly1305-arm.o
 zinc-$(CONFIG_ZINC_ARCH_ARM64) += poly1305/poly1305-arm64.o
 zinc-$(CONFIG_ZINC_ARCH_MIPS) += poly1305/poly1305-mips.o
 AFLAGS_poly1305-mips.o += -O2 # This is required to fill the branch delay slots
 zinc-$(CONFIG_ZINC_ARCH_MIPS64) += poly1305/poly1305-mips64.o
+zinc-$(CONFIG_ZINC_ARCH_PPC32) += poly1305/poly1305-ppc.o 
poly1305/poly1305-ppcfp.o
+zinc-$(CONFIG_ZINC_ARCH_PPC64) += poly1305/poly1305-ppc.o 
poly1305/poly1305-ppcfp.o
 
 zinc-y += chacha20poly1305.o
 
 zinc-y += blake2s/blake2s.o
 zinc-$(CONFIG_ZINC_ARCH_X86_64) += blake2s/blake2s-x86_64.o
 
 zinc-y += curve25519/curve25519.o
 zinc-$(CONFIG_ZINC_ARCH_ARM) += curve25519/curve25519-arm.o
 
 quiet_cmd_perlasm = PERLASM $@
-  cmd_perlasm = $(PERL) $< $(perlflags-y) > $@
+  cmd_perlasm = $(PERL) $(perlflags-y) $< $(perlargs-y) > $@
 $(obj)/%.S: $(src)/%.pl FORCE
$(call if_changed,perlasm)
 kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src))
 targets := $(patsubst $(kbuild-dir)/%.pl,%.S,$(wildcard $(patsubst 
%.o,$(kbuild-dir)/crypto/zinc/%.pl,$(zinc-y) $(zinc-m) $(zinc-
 
-perlflags-$(CONFIG_ZINC_ARCH_PPC32) += linux32
+perlargs-$(CONFIG_ZINC_ARCH_PPC32) += linux32
 ifeq ($(CONFIG_ZINC_ARCH_PPC64),y)
-perlflags-$(CONFIG_CPU_BIG_ENDIAN) += linux64
-perlflags-$(CONFIG_CPU_LITTLE_ENDIAN) += linux64le
+perlargs-$(CONFIG_CPU_BIG_ENDIAN) += linux64
+perlargs-$(CONFIG_CPU_LITTLE_ENDIAN) += linux64le
 endif
 
 # Old kernels don't set this, which causes trouble.
 .SECONDARY:
 
diff --git a/src/crypto/zinc/chacha20/chacha20-ppc.pl 
b/src/crypto/zinc/chacha20/chacha20-ppc.pl
index 07468c8..fa8f6bc 100644
--- a/src/crypto/zinc/chacha20/chacha20-ppc.pl
+++ b/src/crypto/zinc/chacha20/chacha20-ppc.pl
@@ -4,10 +4,12 @@
 # This code is taken from the OpenSSL project but the author, Andy Polyakov,
 # has relicensed it under the licenses specified in the SPDX header above.
 # The original headers, including the original license headers, are
 # included below for completeness.
 #
+# Changes: search in more places for ppc-xlate.pl
+#
 # Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved.
 #
 # Licensed under the Apache License 2.0 (the "License").  You may not use
 # this file except in compliance with the License.  You can obtain a copy
 # in the file LICENSE in the source distribution or at
@@ -71,10 +73,11 @@ if ($flavour =~ /64/) {
 
 $LITTLE_ENDIAN = ($flavour=~/le$/) ? 1 : 0;
 
 $0 =~ m/(.*[\/\\])[^\/\\]+$/; $dir=$1;
 ( $xlate="${dir}ppc-xlate.pl" and -f $xlate ) or
+( $xlate="${dir}../perlasm/ppc-xlate.pl" and -f $xlate) or
 ( $xlate="${dir}../../perlasm/ppc-xlate.pl" and -f $xlate) or
 die "can't locate ppc-xlate.pl";
 
 open STDOUT,"| $^X $xlate $flavour ".shift || die "can't call $xlate: $!";
 
diff --git a/src/crypto/zinc/chacha20/ppc-xlate.pl 
b/src/crypto/zinc/perlasm/ppc-xlate.pl
similarity index 100%
rename from src/crypto/zinc/chacha20/ppc-xlate.pl
rename to src/crypto/zinc/perlasm/ppc-xlate.pl
diff --git a/src/crypto/zinc/poly1305/poly1305-arm-glue.c 
b/src/crypto/zinc/poly1305/poly1305-arm-glue.c
index a80f046..6100700 100644
--- a/src/crypto/zinc/poly1305/poly1305-arm-glue.c
+++ b/src/crypto/zinc/poly1305/poly1305-arm-glue.c
@@ -24,75 +24,10 @@ static void __init poly1305_fpu_init(void)
 #elif defined(CONFIG_ZINC_ARCH_ARM)
poly1305_use_neon = elf_hwcap & HWCAP_NEON;
 #endif
 }
 
-#if defined(CONFIG_ZINC_ARCH_ARM64)
-struct poly1305_arch_internal {
-   union {
-   u32 h[5];
-   struct {
-   u64 h0, h1, h2;
-   };
-   };
-   u64 is_base2_26;
-   u64 r[2];
-};
-#elif

[PATCH 1/2] [Zinc] Add PowerPC chacha20 implementation from openssl/cryptograms

2019-05-12 Thread Shawn Landden 
There is a bug where may_use_simd()
returns false in kworker, and prevents most of this code from running.
I reported this upstream: https://bugzilla.kernel.org/show_bug.cgi?id=203571

Otherwise this is tested (with the VSX code enabled) on Power 9 (ppc64le).
Without this I get 2GiB/s over the loopback (so 4 GiB/s), and with this
I get 2.8 GiB/s (so 5.6 GiB/s), and more time is spent in poly1305 than 
chacha20.
This is on a 4-thread VPS.

Signed-off-by: Shawn Landden 

v2: more complete simd.h for PPC
benchmarks
whitespace issues
---
 src/compat/simd/include/linux/simd.h |   29 +-
 src/crypto/Kbuild.include|   18 +-
 src/crypto/zinc/chacha20/chacha20-ppc-glue.c |   67 +
 src/crypto/zinc/chacha20/chacha20-ppc.pl | 1355 ++
 src/crypto/zinc/chacha20/chacha20.c  |2 +
 src/crypto/zinc/chacha20/ppc-xlate.pl|  353 +
 6 files changed, 1821 insertions(+), 3 deletions(-)
 create mode 100644 src/crypto/zinc/chacha20/chacha20-ppc-glue.c
 create mode 100644 src/crypto/zinc/chacha20/chacha20-ppc.pl
 create mode 100644 src/crypto/zinc/chacha20/ppc-xlate.pl

diff --git a/src/compat/simd/include/linux/simd.h 
b/src/compat/simd/include/linux/simd.h
index c75c724..44060a9 100644
--- a/src/compat/simd/include/linux/simd.h
+++ b/src/compat/simd/include/linux/simd.h
@@ -11,10 +11,13 @@
 #if defined(CONFIG_X86_64)
 #include 
 #include 
 #elif defined(CONFIG_KERNEL_MODE_NEON)
 #include 
+#elif defined(CONFIG_ALTIVEC) || defined(CONFIG_VSX)
+#include 
+#include 
 #endif
 
 typedef enum {
HAVE_NO_SIMD = 1 << 0,
HAVE_FULL_SIMD = 1 << 1,
@@ -28,17 +31,28 @@ static inline void simd_get(simd_context_t *ctx)
*ctx = !IS_ENABLED(CONFIG_PREEMPT_RT_BASE) && may_use_simd() ? 
HAVE_FULL_SIMD : HAVE_NO_SIMD;
 }
 
 static inline void simd_put(simd_context_t *ctx)
 {
+if (*ctx & HAVE_SIMD_IN_USE) {
 #if defined(CONFIG_X86_64)
-   if (*ctx & HAVE_SIMD_IN_USE)
kernel_fpu_end();
 #elif defined(CONFIG_KERNEL_MODE_NEON)
-   if (*ctx & HAVE_SIMD_IN_USE)
kernel_neon_end();
+#elif defined(CONFIG_PPC32) || defined(CONFIG_PPC64)
+   if (cpu_has_feature(CPU_FTR_VSX_COMP)) {
+   disable_kernel_vsx();
+   preempt_enable();
+   } else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP)) {
+   disable_kernel_altivec();
+   preempt_enable();
+   } else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE)) {
+   disable_kernel_fp();
+   preempt_enable();
+   }
 #endif
+   }
*ctx = HAVE_NO_SIMD;
 }
 
 static inline bool simd_relax(simd_context_t *ctx)
 {
@@ -60,10 +74,21 @@ static __must_check inline bool simd_use(simd_context_t 
*ctx)
return true;
 #if defined(CONFIG_X86_64)
kernel_fpu_begin();
 #elif defined(CONFIG_KERNEL_MODE_NEON)
kernel_neon_begin();
+#elif defined(CONFIG_PPC32) || defined(CONFIG_PPC64)
+   if (cpu_has_feature(CPU_FTR_VSX_COMP)) {
+   preempt_disable();
+   enable_kernel_vsx();
+   } else if (cpu_has_feature(CPU_FTR_ALTIVEC_COMP)) {
+   preempt_disable();
+   enable_kernel_altivec();
+   } else if (!cpu_has_feature(CPU_FTR_FPU_UNAVAILABLE)) {
+   preempt_disable();
+   enable_kernel_fp();
+   }
 #endif
*ctx |= HAVE_SIMD_IN_USE;
return true;
 }
 
diff --git a/src/crypto/Kbuild.include b/src/crypto/Kbuild.include
index 460684d..4e05181 100644
--- a/src/crypto/Kbuild.include
+++ b/src/crypto/Kbuild.include
@@ -11,17 +11,25 @@ ifeq ($(CONFIG_MIPS)$(CONFIG_CPU_MIPS32_R2),yy)
 CONFIG_ZINC_ARCH_MIPS := y
 endif
 ifeq ($(CONFIG_MIPS)$(CONFIG_64BIT),yy)
 CONFIG_ZINC_ARCH_MIPS64 := y
 endif
+ifeq ($(CONFIG_PPC32),y)
+CONFIG_ZINC_ARCH_PPC32 := y
+endif
+ifeq ($(CONFIG_PPC64),y)
+CONFIG_ZINC_ARCH_PPC64 := y
+endif
 
 zinc-y += chacha20/chacha20.o
 zinc-$(CONFIG_ZINC_ARCH_X86_64) += chacha20/chacha20-x86_64.o
 zinc-$(CONFIG_ZINC_ARCH_ARM) += chacha20/chacha20-arm.o 
chacha20/chacha20-unrolled-arm.o
 zinc-$(CONFIG_ZINC_ARCH_ARM64) += chacha20/chacha20-arm64.o
 zinc-$(CONFIG_ZINC_ARCH_MIPS) += chacha20/chacha20-mips.o
 AFLAGS_chacha20-mips.o += -O2 # This is required to fill the branch delay slots
+zinc-$(CONFIG_ZINC_ARCH_PPC32) += chacha20/chacha20-ppc.o
+zinc-$(CONFIG_ZINC_ARCH_PPC64) += chacha20/chacha20-ppc.o
 
 zinc-y += poly1305/poly1305.o
 zinc-$(CONFIG_ZINC_ARCH_X86_64) += poly1305/poly1305-x86_64.o
 zinc-$(CONFIG_ZINC_ARCH_ARM) += poly1305/poly1305-arm.o
 zinc-$(CONFIG_ZINC_ARCH_ARM64) += poly1305/poly1305-arm64.o
@@ -36,22 +44,30 @@ zinc-$(CONFIG_ZINC_ARCH_X86_64) += blake2s/blake2s-x86_64.o
 
 zinc-y += curve25519/curve25519.o
 zinc-$(CONFIG_ZINC_ARCH_ARM) += curve25519/curve25519-arm.o
 
 quiet_cmd_perlasm = PERLASM $@
-

Re: Overlapping AllowedIPs Configuration

2019-05-12 Thread Henning Reich 
No, I think its correct behaviour.
If you have overlapping networks  the more specific route is preferred.
10.10.10.0/24 overrule 10.10.0.0/16.
If the subnets are the same, the last one is the more specific (because
most recent one) and should be used.

And in germany, we say (literal translation): You're allowed to shoot
yourself in the knee.
(to be self-defeating) :-)



Aleksa Sarai  schrieb am Sa., 11. Mai 2019, 15:09:

> Hi all,
>
> I just found out that WireGuard apparently allows you to configure an
> interface that has peers with overlapping AllowedIPs ranges -- which
> obviously won't work with cryptokey routing -- but additionally is
> strange since I feel this should cause an error when configuring the
> interface.
>
> In my case, I accidentally used /32 when generating the IPv6 addresses
> of my clients and ended up with a config like:
>
>   [Interface]
>   Address = 10.13.37.1/32,fd00:dead:beef:cafe::1/64
>   ListenPort = 51820
>   PrivateKey = [key]
>
>   # Peer A.
>   [Peer]
>   PublicKey = [pub]
>   PreSharedKey = [psk]
>   AllowedIPs = 10.13.40.1/32,fd00:dead:beef:1000::/32
>
>   # Peer B.
>   [Peer]
>   PublicKey = [pub]
>   PreSharedKey = [psk]
>   AllowedIPs = 10.13.41.1/32,fd00:dead:beef:1001::/32
>
> This config is wrong (because both peers have overlapping addresses
> specified for AllowedIPs), but wireguard will happily accept it:
>
>   % wg-quick up wg-foo
>   [#] ip link add wg-yavin type wireguard
>   [#] wg setconf wg-yavin /dev/fd/63
>   [#] ip address add 10.13.37.1/32 dev wg-yavin
>   [#] ip address add fd00:dead:beef:cafe::1/64 dev wg-yavin
>   [#] ip link set mtu 1420 up dev wg-yavin
>   [#] ip route add fd42:dead::/32 dev wg-yavin
>   [#] ip route add 10.13.41.1/32 dev wg-yavin
>   [#] ip route add 10.13.40.1/32 dev wg-yavin
>
> This configuration results in only one of the peers actually being given
> the IPv6 range, but I feel like "wg setconf" should've rejected this
> configuration.
>
>   % wg
>   interface: wg-foo
> public key: [pub]
> private key: (hidden)
> listening port: 51820
>
>   peer: [peer A]
> preshared key: (hidden)
> allowed ips: 10.13.40.1/32
>
>   peer: [peer B]
> preshared key: (hidden)
> allowed ips: 10.13.41.1/32, fd42:dead::/32
>
> --
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> 
> ___
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard Bug?

2019-05-12 Thread Lonnie Abelbeck 



> On May 12, 2019, at 8:44 AM, Ryan Whelan  wrote:
> 
> I am building a system which coordinates the meshing of wireguard devices.  
> Currently, all the devices are running on an embedded platform (AMD Geode 
> LX500) and works as expected.  However, when introducing a 64bit KVM host for 
> testing, all the 32bit hosts running on the Geode platform, report the 
> following warning and drop offline temporarily.  The CPU usage on KVM host 
> spikes and all the CPU time is spent on the kernel threads servicing the WG 
> interfaces.
> 
> I'm using kernel 4.19.41 and have seen the issue with both the last WG 
> snapshot as well building from master.

Hi Ryan,

Did you mean "AMD Geode LX800 @500 MHz" ? (ex. ALIX/net5501)

If so, I have a couple of those using kernel 3.16.64 (i586) mixed with 3.16.64 
(x86_64), and WG works well between them, no issues like you reported.  iperf3 
over WG runs at 23.8 Mbits/sec.

Lonnie

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard andoird and Fire TV

2019-05-12 Thread Samuel Holland 
On 5/6/19 4:27 AM, Revath S Kumar wrote:
> Hello all,
> 
> I tried to side load the wireguard android on Fire TV stick.
> I was successfully able to install and create a new config.
> But once the config is created I was not able to enable the config.
> 
> The navigation using the FireTV remote never gets focus on config toggle 
> button.
> 
> Any plan to support TV sooner?

See https://lists.zx2c4.com/pipermail/wireguard/2019-January/003768.html

It's possible to get it working with the remote, but that would require someone
to write (and test!) the code to do so. Right now there's nobody working on the
Android app.

> with regards,
> Revath S Kumar,
> JavaScripter / Rubyist / PHP

Cheers,
Samuel
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard Bug?

2019-05-12 Thread Jason A. Donenfeld 
Hey Ryan,

Can you confirm the following?

- You can easily reproduce this in a matter of seconds.
- The stacktrace you sent is from from the 32bit machine.
- The 64bit KVM machine, after triggering the stacktrace on the 32bit
machines, starts using tons of CPU.

Could you also send the .config of the 32bit machine and perhaps any
additional interesting information about the 64bit KVM machine?

Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Wireguard Bug?

2019-05-12 Thread Ryan Whelan 
I am building a system which coordinates the meshing of wireguard devices.
Currently, all the devices are running on an embedded platform (AMD Geode
LX500) and works as expected.  However, when introducing a 64bit KVM host
for testing, all the 32bit hosts running on the Geode platform, report the
following warning and drop offline temporarily.  The CPU usage on KVM host
spikes and all the CPU time is spent on the kernel threads servicing the WG
interfaces.

I'm using kernel 4.19.41 and have seen the issue with both the last WG
snapshot as well building from master.

Is this a bug in WG?

May 10 18:36:25 buildroot kern.warn kernel: WARNING: CPU: 0 PID: 9 at
kernel/workqueue.c:1442 __queue_work+0x1d4/0x2aa
May 10 18:36:25 buildroot kern.warn kernel: CPU: 0 PID: 9 Comm: ksoftirqd/0
Tainted: GW 4.19.41-banana #1
May 10 18:36:25 buildroot kern.warn kernel: EIP: __queue_work+0x1d4/0x2aa
May 10 18:36:25 buildroot kern.warn kernel: Code: c1 e8 4e 09 1d 00 c7 05
30 d3 5f c1 00 00 00 00 c7 45 e4 00 00 00 00 e9 76 fe ff ff 8b 3d 80 3c 60
c1 89 78 10 e9 32 ff ff ff <0f> 0b b8 01 00 00 00 e8 1c 82 00 00 a1 a8 9e
5f c1 85 c0 0f 85 3b
May 10 18:36:25 buildroot kern.warn kernel: EAX:  EBX: cfb63044
ECX: 0003 EDX: cfb63048
May 10 18:36:25 buildroot kern.warn kernel: ESI: cfdfbb00 EDI: cfab29c0
EBP: cf847d38 ESP: cf847d1c
May 10 18:36:25 buildroot kern.warn kernel: DS: 007b ES: 007b FS:  GS:
00e0 SS: 0068 EFLAGS: 00010086
May 10 18:36:25 buildroot kern.warn kernel: CR0: 80050033 CR2: a7bb5058
CR3: 0eebe000 CR4: 0090
May 10 18:36:25 buildroot kern.warn kernel: Call Trace:
May 10 18:36:25 buildroot kern.warn kernel:  queue_work_on+0x19/0x1d
May 10 18:36:25 buildroot kern.warn kernel:  wg_packet_receive+0x4a5/0x557
May 10 18:36:25 buildroot kern.warn kernel:  ? send6+0x1fc/0x1fc
May 10 18:36:25 buildroot kern.warn kernel:  wg_receive+0x16/0x25
May 10 18:36:25 buildroot kern.warn kernel:  udp_queue_rcv_skb+0x254/0x324
May 10 18:36:25 buildroot kern.warn kernel:
udp_unicast_rcv_skb.isra.12+0x68/0x7a
May 10 18:36:25 buildroot kern.warn kernel:  __udp4_lib_rcv+0x413/0x88b
May 10 18:36:25 buildroot kern.warn kernel:  udp_rcv+0x12/0x14
May 10 18:36:25 buildroot kern.warn kernel:
ip_local_deliver_finish+0x82/0x1ff
May 10 18:36:25 buildroot kern.warn kernel:  ip_local_deliver+0xc0/0xcb
May 10 18:36:25 buildroot kern.warn kernel:  ?
ip_sublist_rcv_finish+0x41/0x41
May 10 18:36:25 buildroot kern.warn kernel:  ip_rcv_finish+0x24/0x2a
May 10 18:36:25 buildroot kern.warn kernel:  ip_rcv+0xa1/0xaf
May 10 18:36:25 buildroot kern.warn kernel:  ?
ip_rcv_finish_core.isra.0+0x331/0x331
May 10 18:36:25 buildroot kern.warn kernel:
__netif_receive_skb_one_core+0x3f/0x59
May 10 18:36:25 buildroot kern.warn kernel:  __netif_receive_skb+0x16/0x4f
May 10 18:36:25 buildroot kern.warn kernel:
netif_receive_skb_internal+0x26/0xaf
May 10 18:36:25 buildroot kern.warn kernel:  netif_receive_skb+0x8/0xa
May 10 18:36:25 buildroot kern.warn kernel:  rhine_napipoll+0x5ef/0x9c6
May 10 18:36:25 buildroot kern.warn kernel:  net_rx_action+0x197/0x24d
May 10 18:36:25 buildroot kern.warn kernel:  __do_softirq+0xd6/0x1ae
May 10 18:36:25 buildroot kern.warn kernel:  run_ksoftirqd+0x21/0x24
May 10 18:36:25 buildroot kern.warn kernel:  smpboot_thread_fn+0x137/0x1ea
May 10 18:36:25 buildroot kern.warn kernel:  kthread+0xbe/0xea
May 10 18:36:25 buildroot kern.warn kernel:  ? sort_range+0x18/0x18
May 10 18:36:25 buildroot kern.warn kernel:  ?
__kthread_create_on_node+0x13e/0x13e
May 10 18:36:25 buildroot kern.warn kernel:  ret_from_fork+0x19/0x24
May 10 18:36:25 buildroot kern.warn kernel: ---[ end trace c200a14cd22c0ee1
]---
May 10 18:36:25 buildroot kern.warn kernel: WARNING: CPU: 0 PID: 9 at
kernel/workqueue.c:1442 __queue_work+0x1d4/0x2aa
May 10 18:36:25 buildroot kern.warn kernel: CPU: 0 PID: 9 Comm: ksoftirqd/0
Tainted: GW 4.19.41-banana #1
May 10 18:36:25 buildroot kern.warn kernel: EIP: __queue_work+0x1d4/0x2aa
May 10 18:36:25 buildroot kern.warn kernel: Code: c1 e8 4e 09 1d 00 c7 05
30 d3 5f c1 00 00 00 00 c7 45 e4 00 00 00 00 e9 76 fe ff ff 8b 3d 80 3c 60
c1 89 78 10 e9 32 ff ff ff <0f> 0b b8 01 00 00 00 e8 1c 82 00 00 a1 a8 9e
5f c1 85 c0 0f 85 3b
May 10 18:36:25 buildroot kern.warn kernel: EAX:  EBX: cfb62044
ECX: 0003 EDX: cfb62048
May 10 18:36:25 buildroot kern.warn kernel: ESI: cfdfbb00 EDI: cfab29c0
EBP: cf847d38 ESP: cf847d1c
May 10 18:36:25 buildroot kern.warn kernel: DS: 007b ES: 007b FS:  GS:
00e0 SS: 0068 EFLAGS: 00010086
May 10 18:36:25 buildroot kern.warn kernel: CR0: 80050033 CR2: a7bb5058
CR3: 0eebe000 CR4: 0090
May 10 18:36:25 buildroot kern.warn kernel: Call Trace:
May 10 18:36:25 buildroot kern.warn kernel:  queue_work_on+0x19/0x1d
May 10 18:36:25 buildroot kern.warn kernel:  wg_packet_receive+0x4a5/0x557
May 10 18:36:25 buildroot kern.warn kernel:  ? send6+0x1fc/0x1fc
May 10 18:36:25 buildroot kern.warn kernel:  wg_receive+0x16/0x25
May 10 18:36:25 buildroot kern.warn