From syzbot+19e796f043fe3be7b76a at syzkaller.appspotmail.com  Thu Jan  8 22:43:23 2026
From: syzbot+19e796f043fe3be7b76a at syzkaller.appspotmail.com (syzbot)
Date: Thu, 08 Jan 2026 14:43:23 -0800
Subject: [syzbot] [wireguard?] WARNING in stub_timer
Message-ID: <6960330b.050a0220.1c677c.03a9.GAE@google.com>

Hello,

syzbot found the following issue on:

HEAD commit:    54e82e93ca93 Merge tag 'core_urgent_for_v6.19_rc4' of git:..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1022ee22580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=513255d80ab78f2b
dashboard link: https://syzkaller.appspot.com/bug?extid=19e796f043fe3be7b76a
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-54e82e93.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f3befb5f53a4/vmlinux-54e82e93.xz
kernel image: https://storage.googleapis.com/syzbot-assets/92820ca1dbd8/bzImage-54e82e93.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+19e796f043fe3be7b76a at syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: kernel/time/timer.c:716 at stub_timer+0xa/0x20 kernel/time/timer.c:716, CPU#0: kworker/0:1/10
Modules linked in:
CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: events_power_efficient wg_ratelimiter_gc_entries
RIP: 0010:stub_timer+0xa/0x20 kernel/time/timer.c:716
Code: 0f 94 c0 5b 41 5e e9 05 73 b0 09 cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa e8 27 fa 12 00 90 <0f> 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
RSP: 0018:ffffc90000007c98 EFLAGS: 00010246
RAX: ffffffff81ae0d39 RBX: 0000000000000101 RCX: ffff88801bef0000
RDX: 0000000000000100 RSI: ffffffff8bc095c0 RDI: ffffc9000db0f1c0
RBP: ffffc90000007d90 R08: ffffffff8f824677 R09: 1ffffffff1f048ce
R10: dffffc0000000000 R11: ffffffff81ae0d30 R12: 0000000000000000
R13: ffffc9000db0f1c0 R14: 1ffff92000000f98 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffff88808d414000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2cc5528910 CR3: 00000000377e7000 CR4: 0000000000352ef0
Call Trace:
 <IRQ>
 call_timer_fn+0x16e/0x590 kernel/time/timer.c:1748
 expire_timers kernel/time/timer.c:1799 [inline]
 __run_timers kernel/time/timer.c:2373 [inline]
 __run_timer_base+0x61a/0x860 kernel/time/timer.c:2385
 run_timer_base kernel/time/timer.c:2394 [inline]
 run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2404
 handle_softirqs+0x22b/0x7c0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 invoke_softirq kernel/softirq.c:496 [inline]
 __irq_exit_rcu+0x60/0x150 kernel/softirq.c:723
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
 sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1056
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:lock_release+0x2d8/0x3b0 kernel/locking/lockdep.c:5893
Code: e4 e2 10 00 00 00 00 eb b5 e8 84 7f bd 09 f7 c3 00 02 00 00 74 b9 65 48 8b 05 74 9e e2 10 48 3b 44 24 28 75 44 fb 48 83 c4 30 <5b> 41 5c 41 5d 41 5e 41 5f 5d e9 59 5e c0 09 cc 48 8d 3d 11 6d e7
RSP: 0018:ffffc900001c79e0 EFLAGS: 00000282
RAX: f62d7e25cf48d100 RBX: 0000000000000283 RCX: 0000000080000001
RDX: 0000000000000002 RSI: ffffffff8d97c93e RDI: ffffffff8bc095e0
RBP: ffff88801bef0b80 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff52000038f34 R12: 0000000000000002
R13: 0000000000000002 R14: ffffffff8ea6eef8 R15: ffff88801bef0000
 __raw_spin_unlock include/linux/spinlock_api_smp.h:141 [inline]
 _raw_spin_unlock+0x16/0x50 kernel/locking/spinlock.c:186
 spin_unlock include/linux/spinlock.h:391 [inline]
 wg_ratelimiter_gc_entries+0x384/0x450 drivers/net/wireguard/ratelimiter.c:76
 process_one_work kernel/workqueue.c:3257 [inline]
 process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421
 kthread+0x711/0x8a0 kernel/kthread.c:463
 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
 </TASK>
----------------
Code disassembly (best guess):
   0:	e4 e2                	in     $0xe2,%al
   2:	10 00                	adc    %al,(%rax)
   4:	00 00                	add    %al,(%rax)
   6:	00 eb                	add    %ch,%bl
   8:	b5 e8                	mov    $0xe8,%ch
   a:	84 7f bd             	test   %bh,-0x43(%rdi)
   d:	09 f7                	or     %esi,%edi
   f:	c3                   	ret
  10:	00 02                	add    %al,(%rdx)
  12:	00 00                	add    %al,(%rax)
  14:	74 b9                	je     0xffffffcf
  16:	65 48 8b 05 74 9e e2 	mov    %gs:0x10e29e74(%rip),%rax        # 0x10e29e92
  1d:	10
  1e:	48 3b 44 24 28       	cmp    0x28(%rsp),%rax
  23:	75 44                	jne    0x69
  25:	fb                   	sti
  26:	48 83 c4 30          	add    $0x30,%rsp
* 2a:	5b                   	pop    %rbx <-- trapping instruction
  2b:	41 5c                	pop    %r12
  2d:	41 5d                	pop    %r13
  2f:	41 5e                	pop    %r14
  31:	41 5f                	pop    %r15
  33:	5d                   	pop    %rbp
  34:	e9 59 5e c0 09       	jmp    0x9c05e92
  39:	cc                   	int3
  3a:	48                   	rex.W
  3b:	8d                   	.byte 0x8d
  3c:	3d                   	.byte 0x3d
  3d:	11 6d e7             	adc    %ebp,-0x19(%rbp)


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller at googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

From demiobenour at gmail.com  Wed Jan 14 05:45:38 2026
From: demiobenour at gmail.com (Demi Marie Obenour)
Date: Wed, 14 Jan 2026 00:45:38 -0500
Subject: Plans for post-quantum security?
Message-ID: <aed97fd8-28ca-4a29-bbbe-28ac31744c35@gmail.com>

Are there plans to make WireGuard post-quantum secure?  Post-quantum
cryptography is actually faster than X25519, and it is the default
in browsers and many libraries now [1].  It is also the default in
OpenSSH, which warns if it is not in use.

There is an academic paper [2] with a post-quantum VPN based on
WireGuard, but to keep the handshake packets inside the IPv6 MTU,
they had to make trade-offs:

1. The key-encapsulation mechanism used for forward secrecy
   is a modified version of Saber that is only secure against
   chosen-plaintext attack, not chosen-ciphertext attack.  This is
   (hopefully) sufficient for the task here, but this might take
   careful analysis to prove.  It also isn't standardized anywhere
   I am aware of.

2. Classic McEliece is used for long-term asymmetric keys.  It has
   small ciphertexts, but massive public keys.

I have some thoughts of my own, but first I'd like to know if there are
any plans from the developers and if suggestions would be appreciated.
I'd like to not need to switch to IPsec!

Of course, one can always repeatedly update the PresharedKey
field using a daemon running in userspace, but this loses some of
WireGuard's advantages.  It is also tricky to do without having to
send traffic outside the tunnel, and it only rekeys so long as the
daemon keeps running.

[1]: https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-support/
[2]: https://eprint.iacr.org/2020/379.pdf
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB288B55FFF9C22C1.asc
Type: application/pgp-keys
Size: 7140 bytes
Desc: OpenPGP public key
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20260114/c029df07/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20260114/c029df07/attachment.sig>

From horms at kernel.org  Wed Jan 14 15:41:14 2026
From: horms at kernel.org (Simon Horman)
Date: Wed, 14 Jan 2026 15:41:14 +0000
Subject: [PATCH net-next v3] wireguard: allowedips: Use kfree_rcu()
 instead of call_rcu()
In-Reply-To: <20260112130633.25563-1-fushuai.wang@linux.dev>
References: <20260112130633.25563-1-fushuai.wang@linux.dev>
Message-ID: <aWe5GhgmyDkaBLwS@horms.kernel.org>

On Mon, Jan 12, 2026 at 09:06:33PM +0800, Fushuai Wang wrote:
> From: Fushuai Wang <wangfushuai at baidu.com>
> 
> Replace call_rcu() + kmem_cache_free() with kfree_rcu() to simplify
> the code and reduce function size.
> 
> Signed-off-by: Fushuai Wang <wangfushuai at baidu.com>

Thanks,

I believe this address prior review and moreover I agree
with the approach taken here.

Reviewed-by: Simon Horman <horms at kernel.org>

...

From kuba at kernel.org  Thu Jan 15 03:32:37 2026
From: kuba at kernel.org (Jakub Kicinski)
Date: Wed, 14 Jan 2026 19:32:37 -0800
Subject: [net-next,
 v3] wireguard: allowedips: Use kfree_rcu() instead of call_rcu()
In-Reply-To: <20260112130633.25563-1-fushuai.wang@linux.dev>
References: <20260112130633.25563-1-fushuai.wang@linux.dev>
Message-ID: <20260115033237.1545400-1-kuba@kernel.org>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least pausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
wireguard: allowedips: Use kfree_rcu() instead of call_rcu()

This commit replaces call_rcu() with a custom kmem_cache_free() callback
with kfree_rcu() to simplify the code. The change affects how nodes are
freed in the remove_node() function.

> diff --git a/drivers/net/wireguard/allowedips.c b/drivers/net/wireguard/allowedips.c
> index 09f7fcd7da78..5ece9acad64d 100644
> --- a/drivers/net/wireguard/allowedips.c
> +++ b/drivers/net/wireguard/allowedips.c
> @@ -48,11 +48,6 @@ static void push_rcu(struct allowedips_node **stack,
>  	}
>  }
>
> -static void node_free_rcu(struct rcu_head *rcu)
> -{
> -	kmem_cache_free(node_cache, container_of(rcu, struct allowedips_node, rcu));
> -}
> -

[ ... ]

> @@ -271,13 +266,13 @@ static void remove_node(struct allowedips_node *node, struct mutex *lock)
>  	if (free_parent)
>  		child = rcu_dereference_protected(parent->bit[!(node->parent_bit_packed & 1)],
>  						  lockdep_is_held(lock));
> -	call_rcu(&node->rcu, node_free_rcu);
> +	kfree_rcu(node, rcu);

Does wg_allowedips_slab_uninit() need to be updated to use
kvfree_rcu_barrier() instead of rcu_barrier()?

When CONFIG_KVFREE_RCU_BATCHED is enabled (the default), kfree_rcu()
uses a batched mechanism that queues work via queue_rcu_work(). The
rcu_barrier() call waits for RCU callbacks to complete, but these
callbacks only queue the actual free to a workqueue via rcu_work_rcufn().
The workqueue work that calls kvfree() may still be pending after
rcu_barrier() returns.

The existing cleanup path is:
  wg_allowedips_slab_uninit() -> rcu_barrier() -> kmem_cache_destroy()

With kfree_rcu(), this sequence could destroy the slab cache while
kfree_rcu_work() still has pending frees queued. The proper barrier for
kfree_rcu() is kvfree_rcu_barrier() which also calls flush_rcu_work()
on all pending batches.

>  	if (!free_parent)
>  		return;
>  	if (child)
>  		child->parent_bit_packed = parent->parent_bit_packed;
>  	*(struct allowedips_node **)(parent->parent_bit_packed & ~3UL) = child;
> -	call_rcu(&parent->rcu, node_free_rcu);
> +	kfree_rcu(parent, rcu);
>  }
-- 
pw-bot: cr

From arkamar at atlas.cz  Thu Jan 15 08:12:13 2026
From: arkamar at atlas.cz (Petr =?utf-8?B?VmFuxJtr?=)
Date: Thu, 15 Jan 2026 09:12:13 +0100
Subject: [net-next, v3] wireguard: allowedips: Use kfree_rcu() instead of
 call_rcu()
In-Reply-To: <20260115033237.1545400-1-kuba@kernel.org>
References: <20260112130633.25563-1-fushuai.wang@linux.dev>
 <20260115033237.1545400-1-kuba@kernel.org>
Message-ID: <202611581213-aWihXdQpdnhXv606-arkamar@atlas.cz>

Hi Jakub,

Minor side note: I noticed a small typo in the AI review foreword. I
assume this is part of a template:

On Wed, Jan 14, 2026 at 07:32:37PM -0800, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least pausible.
                                                        ^~~~~~~~
pausible -> plausible

Best,
Petr

From edumazet at google.com  Thu Jan 15 09:15:36 2026
From: edumazet at google.com (Eric Dumazet)
Date: Thu, 15 Jan 2026 10:15:36 +0100
Subject: [PATCH net-next v3] wireguard: allowedips: Use kfree_rcu()
 instead of call_rcu()
In-Reply-To: <20260115051221.68054-1-fushuai.wang@linux.dev>
References: <20260115033237.1545400-1-kuba@kernel.org>
 <20260115051221.68054-1-fushuai.wang@linux.dev>
Message-ID: <CANn89iKfuXjqKsn+xB6bpGOaqM7pN4ZcRJ=2KJg4WY76ArYXhQ@mail.gmail.com>

On Thu, Jan 15, 2026 at 6:12?AM Fushuai Wang <fushuai.wang at linux.dev> wrote:
>
> >> @@ -271,13 +266,13 @@ static void remove_node(struct allowedips_node *node, struct mutex *lock)
> >>      if (free_parent)
> >>              child = rcu_dereference_protected(parent->bit[!(node->parent_bit_packed & 1)],
> >>                                                lockdep_is_held(lock));
> >> -    call_rcu(&node->rcu, node_free_rcu);
> >> +    kfree_rcu(node, rcu);
> >
> > Does wg_allowedips_slab_uninit() need to be updated to use
> > kvfree_rcu_barrier() instead of rcu_barrier()?
> >
> > When CONFIG_KVFREE_RCU_BATCHED is enabled (the default), kfree_rcu()
> > uses a batched mechanism that queues work via queue_rcu_work(). The
> > rcu_barrier() call waits for RCU callbacks to complete, but these
> > callbacks only queue the actual free to a workqueue via rcu_work_rcufn().
> > The workqueue work that calls kvfree() may still be pending after
> > rcu_barrier() returns.
> >
> > The existing cleanup path is:
> >   wg_allowedips_slab_uninit() -> rcu_barrier() -> kmem_cache_destroy()
> >
> > With kfree_rcu(), this sequence could destroy the slab cache while
> > kfree_rcu_work() still has pending frees queued. The proper barrier for
> > kfree_rcu() is kvfree_rcu_barrier() which also calls flush_rcu_work()
> > on all pending batches.
>
> We do not need to add an explict kvfree_rcu_barrier(), becasue the commit
> 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy()")
> already does it.

It was doing it, but got replaced recently with a plain rcu_barrier()

commit 0f35040de59371ad542b915d7b91176c9910dadc
Author: Harry Yoo <harry.yoo at oracle.com>
Date:   Mon Dec 8 00:41:47 2025 +0900

    mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction

We would like explicit +2 from mm _and_ rcu experts on this wireguard patch.

Thank you.

From kuba at kernel.org  Thu Jan 15 14:26:41 2026
From: kuba at kernel.org (Jakub Kicinski)
Date: Thu, 15 Jan 2026 06:26:41 -0800
Subject: [net-next, v3] wireguard: allowedips: Use kfree_rcu() instead
 of call_rcu()
In-Reply-To: <202611581213-aWihXdQpdnhXv606-arkamar@atlas.cz>
References: <20260112130633.25563-1-fushuai.wang@linux.dev>
 <20260115033237.1545400-1-kuba@kernel.org>
 <202611581213-aWihXdQpdnhXv606-arkamar@atlas.cz>
Message-ID: <20260115062641.57ef05fe@kernel.org>

On Thu, 15 Jan 2026 09:12:13 +0100 Petr Van?k wrote:
> Hi Jakub,
> 
> Minor side note: I noticed a small typo in the AI review foreword. I
> assume this is part of a template:
> 
> On Wed, Jan 14, 2026 at 07:32:37PM -0800, Jakub Kicinski wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least pausible.  
>                                                         ^~~~~~~~
> pausible -> plausible

Ah, thanks :)

From Jason at zx2c4.com  Thu Jan 15 14:33:42 2026
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 15 Jan 2026 15:33:42 +0100
Subject: [PATCH net-next v3] wireguard: allowedips: Use kfree_rcu()
 instead of call_rcu()
In-Reply-To: <CANn89iKfuXjqKsn+xB6bpGOaqM7pN4ZcRJ=2KJg4WY76ArYXhQ@mail.gmail.com>
References: <20260115033237.1545400-1-kuba@kernel.org>
 <20260115051221.68054-1-fushuai.wang@linux.dev>
 <CANn89iKfuXjqKsn+xB6bpGOaqM7pN4ZcRJ=2KJg4WY76ArYXhQ@mail.gmail.com>
Message-ID: <CAHmME9quqMVzD5zSEKvOFOYj3QLANAo2iYeqWQ1toV0C7gJXTg@mail.gmail.com>

Hi Eric,

On Thu, Jan 15, 2026 at 10:15?AM Eric Dumazet <edumazet at google.com> wrote:
> > > The existing cleanup path is:
> > >   wg_allowedips_slab_uninit() -> rcu_barrier() -> kmem_cache_destroy()
> > >
> > > With kfree_rcu(), this sequence could destroy the slab cache while
> > > kfree_rcu_work() still has pending frees queued. The proper barrier for
> > > kfree_rcu() is kvfree_rcu_barrier() which also calls flush_rcu_work()
> > > on all pending batches.
> >
> > We do not need to add an explict kvfree_rcu_barrier(), becasue the commit
> > 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy()")
> > already does it.
>
> It was doing it, but got replaced recently with a plain rcu_barrier()
>
> commit 0f35040de59371ad542b915d7b91176c9910dadc
> Author: Harry Yoo <harry.yoo at oracle.com>
> Date:   Mon Dec 8 00:41:47 2025 +0900
>
>     mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction
>
> We would like explicit +2 from mm _and_ rcu experts on this wireguard patch.

I'll take this through the wireguard tree.

But just a question on your comment, "It was doing it, but got
replaced recently with a plain rcu_barrier()". Are you suggesting I
need a kvfree_rcu_barrier() instead? The latest net-next has a
kvfree_rcu_barrier_on_cache() called from kmem_cache_destroy()
still... But are you suggesting I add this anyway?

diff --git a/drivers/net/wireguard/allowedips.c
b/drivers/net/wireguard/allowedips.c
index 5ece9acad64d..aee39a0303b0 100644
--- a/drivers/net/wireguard/allowedips.c
+++ b/drivers/net/wireguard/allowedips.c
@@ -417,7 +417,7 @@ int __init wg_allowedips_slab_init(void)

 void wg_allowedips_slab_uninit(void)
 {
- rcu_barrier();
+ kvfree_rcu_barrier();
  kmem_cache_destroy(node_cache);
 }

Let me know.

Thanks,
Jason

From edumazet at google.com  Thu Jan 15 14:40:17 2026
From: edumazet at google.com (Eric Dumazet)
Date: Thu, 15 Jan 2026 15:40:17 +0100
Subject: [PATCH net-next v3] wireguard: allowedips: Use kfree_rcu()
 instead of call_rcu()
In-Reply-To: <CAHmME9quqMVzD5zSEKvOFOYj3QLANAo2iYeqWQ1toV0C7gJXTg@mail.gmail.com>
References: <20260115033237.1545400-1-kuba@kernel.org>
 <20260115051221.68054-1-fushuai.wang@linux.dev>
 <CANn89iKfuXjqKsn+xB6bpGOaqM7pN4ZcRJ=2KJg4WY76ArYXhQ@mail.gmail.com>
 <CAHmME9quqMVzD5zSEKvOFOYj3QLANAo2iYeqWQ1toV0C7gJXTg@mail.gmail.com>
Message-ID: <CANn89iKmNSPjsTBwN3166cKyipJbH64ZPE0O6i2AMh7vyKXS=w@mail.gmail.com>

On Thu, Jan 15, 2026 at 3:33?PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Eric,
>
> On Thu, Jan 15, 2026 at 10:15?AM Eric Dumazet <edumazet at google.com> wrote:
> > > > The existing cleanup path is:
> > > >   wg_allowedips_slab_uninit() -> rcu_barrier() -> kmem_cache_destroy()
> > > >
> > > > With kfree_rcu(), this sequence could destroy the slab cache while
> > > > kfree_rcu_work() still has pending frees queued. The proper barrier for
> > > > kfree_rcu() is kvfree_rcu_barrier() which also calls flush_rcu_work()
> > > > on all pending batches.
> > >
> > > We do not need to add an explict kvfree_rcu_barrier(), becasue the commit
> > > 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy()")
> > > already does it.
> >
> > It was doing it, but got replaced recently with a plain rcu_barrier()
> >
> > commit 0f35040de59371ad542b915d7b91176c9910dadc
> > Author: Harry Yoo <harry.yoo at oracle.com>
> > Date:   Mon Dec 8 00:41:47 2025 +0900
> >
> >     mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction
> >
> > We would like explicit +2 from mm _and_ rcu experts on this wireguard patch.
>
> I'll take this through the wireguard tree.
>
> But just a question on your comment, "It was doing it, but got
> replaced recently with a plain rcu_barrier()". Are you suggesting I
> need a kvfree_rcu_barrier() instead? The latest net-next has a
> kvfree_rcu_barrier_on_cache() called from kmem_cache_destroy()
> still... But are you suggesting I add this anyway?
>
> diff --git a/drivers/net/wireguard/allowedips.c
> b/drivers/net/wireguard/allowedips.c
> index 5ece9acad64d..aee39a0303b0 100644
> --- a/drivers/net/wireguard/allowedips.c
> +++ b/drivers/net/wireguard/allowedips.c
> @@ -417,7 +417,7 @@ int __init wg_allowedips_slab_init(void)
>
>  void wg_allowedips_slab_uninit(void)
>  {
> - rcu_barrier();
> + kvfree_rcu_barrier();

It seems kmem_cache_destroy() should take care of needed barriers,
at least this is what is claimed. An rcu_barrier() or kvfree_rcu_barrier()
should not be needed in wg_allowedips_slab_uninit() ?

Probably boring/distracting, I do not expect anyone needing to unload
this module in a loop and expect this to be ultra fast ?

>   kmem_cache_destroy(node_cache);
>  }
>
> Let me know.
>
> Thanks,
> Jason

From ast at fiberby.net  Thu Jan 15 21:10:31 2026
From: ast at fiberby.net (=?UTF-8?q?Asbj=C3=B8rn=20Sloth=20T=C3=B8nnesen?=)
Date: Thu, 15 Jan 2026 21:10:31 +0000
Subject: [PATCH wireguard v5] tools: ynl: add sample for wireguard
Message-ID: <20260115211032.204481-1-ast@fiberby.net>

Add a sample application for WireGuard, using the generated C library.

The main benefit of this is to exercise the generated library,
which might be useful for future self-tests.

Example:
  $ make -C tools/net/ynl/lib
  $ make -C tools/net/ynl/generated
  $ make -C tools/net/ynl/samples wireguard
  $ ./tools/net/ynl/samples/wireguard
  usage: ./tools/net/ynl/samples/wireguard <ifindex|ifname>
  $ sudo ./tools/net/ynl/samples/wireguard wg-test
  Interface 3: wg-test
      Peer 6adfb183a4a2c94a2f92dab5ade762a4788[...]:
          Data: rx: 42 / tx: 42 bytes
          Allowed IPs:
              0.0.0.0/0
              ::/0

Signed-off-by: Asbj?rn Sloth T?nnesen <ast at fiberby.net>
---
v5:
- The series was applied, except patch 09 which had a leaky error path.
  The leak was fixed, so wireguard_get_device_req_free() is always called.
- The Makefile.deps changes was removed (commited in db6b35cffe59).
- The ynl_sock_create() is now given an struct ynl_error pointer.

v4: https://lore.kernel.org/r/20251126173546.57681-1-ast at fiberby.net/
- Thanks Jason and Jakub for all the feedback.
- Old patch 03 has been accepted into Jason's tree.
- Old patch 09 split_ops conversion has been moved to new 03.
- Old patch 10 function renaming was merged into old patch 11 (new 10).
- Patch 04 has been added to adjust .maxattr for GET_DEVICE.
- The old patches 04-08 and 11 was renumbered to patch 05-10.
- Changes to the spec:
  - Re-wrap the documentation lines in the spec.
  - Reword the index/type documentation.
  - get-device now have a more strict request attribute list.
  - The pre/post functions now avoids renaming.
- Changes to patch 10 (was 10+11):
  - The generated kernel code now uses YNL-ARG --function-prefix,
    to reduce the function renaming.
  - The generated files have been moved to their own sub-directory.
- The commit messages have in general been tweaked a bit.

v3: https://lore.kernel.org/r/20251105183223.89913-1-ast at fiberby.net/
- Spec: Make flags-mask checks implicit (thanks Jakub).
- Sample: Add header to Makefile.deps, and avoid copy (thanks Jakub).

v2: https://lore.kernel.org/r/20251031160539.1701943-1-ast at fiberby.net/
- Add missing forward declaration

v1: https://lore.kernel.org/r/20251029205123.286115-1-ast at fiberby.net/
- Policy arguement to nla_parse_nested() changed to NULL (thanks Johannes).
- Added attr-cnt-name to the spec, to reduce the diff a bit.
- Refined the doc in the spec a bit.
- Reword commit messages a bit.
- Reordered the patches, and reduced the series from 14 to 11 patches.

RFC: https://lore.kernel.org/r/20250904-wg-ynl-rfc at fiberby.net/

---
 MAINTAINERS                       |   1 +
 tools/net/ynl/samples/.gitignore  |   1 +
 tools/net/ynl/samples/wireguard.c | 106 ++++++++++++++++++++++++++++++
 3 files changed, 108 insertions(+)
 create mode 100644 tools/net/ynl/samples/wireguard.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d38dcab1fa068..f2a68bfc45963 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28113,6 +28113,7 @@ L:	netdev at vger.kernel.org
 S:	Maintained
 F:	Documentation/netlink/specs/wireguard.yaml
 F:	drivers/net/wireguard/
+F:	tools/net/ynl/samples/wireguard.c
 F:	tools/testing/selftests/wireguard/
 
 WISTRON LAPTOP BUTTON DRIVER
diff --git a/tools/net/ynl/samples/.gitignore b/tools/net/ynl/samples/.gitignore
index 05087ee323ba2..6fbed294feac0 100644
--- a/tools/net/ynl/samples/.gitignore
+++ b/tools/net/ynl/samples/.gitignore
@@ -8,3 +8,4 @@ rt-link
 rt-route
 tc
 tc-filter-add
+wireguard
diff --git a/tools/net/ynl/samples/wireguard.c b/tools/net/ynl/samples/wireguard.c
new file mode 100644
index 0000000000000..df601e742c287
--- /dev/null
+++ b/tools/net/ynl/samples/wireguard.c
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <arpa/inet.h>
+#include <string.h>
+#include <stdio.h>
+#include <errno.h>
+#include <ynl.h>
+
+#include "wireguard-user.h"
+
+static void print_allowed_ip(const struct wireguard_wgallowedip *aip)
+{
+	char addr_out[INET6_ADDRSTRLEN];
+
+	if (!inet_ntop(aip->family, aip->ipaddr, addr_out, sizeof(addr_out))) {
+		addr_out[0] = '?';
+		addr_out[1] = '\0';
+	}
+	printf("\t\t\t%s/%u\n", addr_out, aip->cidr_mask);
+}
+
+/* Only printing public key in this demo. For better key formatting,
+ * use the constant-time implementation as found in wireguard-tools.
+ */
+static void print_peer_header(const struct wireguard_wgpeer *peer)
+{
+	unsigned int len = peer->_len.public_key;
+	uint8_t *key = peer->public_key;
+	unsigned int i;
+
+	if (len != 32)
+		return;
+	printf("\tPeer ");
+	for (i = 0; i < len; i++)
+		printf("%02x", key[i]);
+	printf(":\n");
+}
+
+static void print_peer(const struct wireguard_wgpeer *peer)
+{
+	unsigned int i;
+
+	print_peer_header(peer);
+	printf("\t\tData: rx: %llu / tx: %llu bytes\n",
+	       peer->rx_bytes, peer->tx_bytes);
+	printf("\t\tAllowed IPs:\n");
+	for (i = 0; i < peer->_count.allowedips; i++)
+		print_allowed_ip(&peer->allowedips[i]);
+}
+
+static void build_request(struct wireguard_get_device_req *req, char *arg)
+{
+	char *endptr;
+	int ifindex;
+
+	ifindex = strtol(arg, &endptr, 0);
+	if (endptr != arg + strlen(arg) || errno != 0)
+		ifindex = 0;
+	if (ifindex > 0)
+		wireguard_get_device_req_set_ifindex(req, ifindex);
+	else
+		wireguard_get_device_req_set_ifname(req, arg);
+}
+
+int main(int argc, char **argv)
+{
+	struct wireguard_get_device_list *devs;
+	struct wireguard_get_device_req *req;
+	struct ynl_error yerr;
+	struct ynl_sock *ys;
+
+	if (argc < 2) {
+		fprintf(stderr, "usage: %s <ifindex|ifname>\n", argv[0]);
+		return 1;
+	}
+
+	ys = ynl_sock_create(&ynl_wireguard_family, &yerr);
+	if (!ys) {
+		fprintf(stderr, "YNL: %s\n", yerr.msg);
+		return 2;
+	}
+
+	req = wireguard_get_device_req_alloc();
+	build_request(req, argv[1]);
+
+	devs = wireguard_get_device_dump(ys, req);
+	if (!devs) {
+		fprintf(stderr, "YNL (%d): %s\n", ys->err.code, ys->err.msg);
+		wireguard_get_device_req_free(req);
+		ynl_sock_destroy(ys);
+		return 3;
+	}
+
+	ynl_dump_foreach(devs, d) {
+		unsigned int i;
+
+		printf("Interface %d: %s\n", d->ifindex, d->ifname);
+		for (i = 0; i < d->_count.peers; i++)
+			print_peer(&d->peers[i]);
+	}
+
+	wireguard_get_device_list_free(devs);
+	wireguard_get_device_req_free(req);
+	ynl_sock_destroy(ys);
+
+	return 0;
+}
-- 
2.51.0


From Jason at zx2c4.com  Thu Jan 22 23:30:11 2026
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 23 Jan 2026 00:30:11 +0100
Subject: [PATCH net-next v3] wireguard: allowedips: Use kfree_rcu()
 instead of call_rcu()
In-Reply-To: <CANn89iKmNSPjsTBwN3166cKyipJbH64ZPE0O6i2AMh7vyKXS=w@mail.gmail.com>
References: <20260115033237.1545400-1-kuba@kernel.org>
 <20260115051221.68054-1-fushuai.wang@linux.dev>
 <CANn89iKfuXjqKsn+xB6bpGOaqM7pN4ZcRJ=2KJg4WY76ArYXhQ@mail.gmail.com>
 <CAHmME9quqMVzD5zSEKvOFOYj3QLANAo2iYeqWQ1toV0C7gJXTg@mail.gmail.com>
 <CANn89iKmNSPjsTBwN3166cKyipJbH64ZPE0O6i2AMh7vyKXS=w@mail.gmail.com>
Message-ID: <aXKzA7C39tJLJWzh@zx2c4.com>

On Thu, Jan 15, 2026 at 03:40:17PM +0100, Eric Dumazet wrote:
> On Thu, Jan 15, 2026 at 3:33?PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> >
> > Hi Eric,
> >
> > On Thu, Jan 15, 2026 at 10:15?AM Eric Dumazet <edumazet at google.com> wrote:
> > > > > The existing cleanup path is:
> > > > >   wg_allowedips_slab_uninit() -> rcu_barrier() -> kmem_cache_destroy()
> > > > >
> > > > > With kfree_rcu(), this sequence could destroy the slab cache while
> > > > > kfree_rcu_work() still has pending frees queued. The proper barrier for
> > > > > kfree_rcu() is kvfree_rcu_barrier() which also calls flush_rcu_work()
> > > > > on all pending batches.
> > > >
> > > > We do not need to add an explict kvfree_rcu_barrier(), becasue the commit
> > > > 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy()")
> > > > already does it.
> > >
> > > It was doing it, but got replaced recently with a plain rcu_barrier()
> > >
> > > commit 0f35040de59371ad542b915d7b91176c9910dadc
> > > Author: Harry Yoo <harry.yoo at oracle.com>
> > > Date:   Mon Dec 8 00:41:47 2025 +0900
> > >
> > >     mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction
> > >
> > > We would like explicit +2 from mm _and_ rcu experts on this wireguard patch.
> >
> > I'll take this through the wireguard tree.
> >
> > But just a question on your comment, "It was doing it, but got
> > replaced recently with a plain rcu_barrier()". Are you suggesting I
> > need a kvfree_rcu_barrier() instead? The latest net-next has a
> > kvfree_rcu_barrier_on_cache() called from kmem_cache_destroy()
> > still... But are you suggesting I add this anyway?
> >
> > diff --git a/drivers/net/wireguard/allowedips.c
> > b/drivers/net/wireguard/allowedips.c
> > index 5ece9acad64d..aee39a0303b0 100644
> > --- a/drivers/net/wireguard/allowedips.c
> > +++ b/drivers/net/wireguard/allowedips.c
> > @@ -417,7 +417,7 @@ int __init wg_allowedips_slab_init(void)
> >
> >  void wg_allowedips_slab_uninit(void)
> >  {
> > - rcu_barrier();
> > + kvfree_rcu_barrier();
> 
> It seems kmem_cache_destroy() should take care of needed barriers,
> at least this is what is claimed. An rcu_barrier() or kvfree_rcu_barrier()
> should not be needed in wg_allowedips_slab_uninit() ?
> 
> Probably boring/distracting, I do not expect anyone needing to unload
> this module in a loop and expect this to be ultra fast ?

Okay so I'll take this patch, and perhaps amend to it the _removal_ of
that rcu_barrier()?

Jason

From Jason at zx2c4.com  Thu Jan 22 23:32:14 2026
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 23 Jan 2026 00:32:14 +0100
Subject: [PATCH wireguard v5] tools: ynl: add sample for wireguard
In-Reply-To: <20260115211032.204481-1-ast@fiberby.net>
References: <20260115211032.204481-1-ast@fiberby.net>
Message-ID: <aXKzflND_hv4s4xj@zx2c4.com>

On Thu, Jan 15, 2026 at 09:10:31PM +0000, Asbj?rn Sloth T?nnesen wrote:
> Add a sample application for WireGuard, using the generated C library.

Applied. Thank you for taking this all the way.

Jason