[PATCH 0/3] Drain module-owned RCU callbacks during teardown

[PATCH 0/3] Drain module-owned RCU callbacks during teardown

[Jiale Yao]

VFIO PCI core, TUN, and Lima each enqueue an RCU callback implemented in
module text. Their teardown paths can run after the callback producer has
stopped but before a previously queued callback has completed. Unloading
the module in that interval lets rcu_do_batch() invoke freed module text.

For Lima, the same window also allows the callback's slab cache to be
destroyed and its global pointer cleared before the callback frees the
fence.

Drain callbacks after their producers have stopped. The three changes are
independent and each patch remains buildable on its own.

The affected object files were built with CONFIG_TUN=m. The series was
also checked with checkpatch.pl. Runtime reproduction was not performed.

Jiale Yao (3):
  vfio/pci: Drain eventfd RCU callbacks on module exit
  tun: Drain eBPF RCU callbacks on module exit
  drm/lima: Drain fence callbacks before destroying slab

 drivers/gpu/drm/lima/lima_sched.c | 1 +
 drivers/net/tun.c                 | 1 +
 drivers/vfio/pci/vfio_pci_core.c  | 1 +
 3 files changed, 3 insertions(+)

-- 
2.34.1

[PATCH 2/3] tun: Drain eBPF RCU callbacks on module exit

[Jiale Yao]

Replacing or clearing a TUN eBPF program defers its destruction to
tun_prog_free(). In the device teardown path, tun_free_netdev() can queue
this callback as a private destructor. The rcu_barrier() in
netdev_run_todo() runs before private destructors, so it cannot drain the
new callback.

After the last file or persistent-device reference is released, tun can
therefore unload before the callback runs. Drain outstanding callbacks at
the end of module cleanup so they cannot execute from freed module text.

Fixes: 96f84061620c ("tun: add eBPF based queue selection method")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
 drivers/net/tun.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 5a302709a68a..bde5032bf4f4 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -3855,6 +3855,7 @@ static void __exit tun_cleanup(void)
 	misc_deregister(&tun_miscdev);
 	rtnl_link_unregister(&tun_link_ops);
 	unregister_netdevice_notifier(&tun_notifier_block);
+	rcu_barrier();
 }
 
 /* Get an underlying socket object from tun file.  Returns error unless file is
-- 
2.34.1

Re: [PATCH 2/3] tun: Drain eBPF RCU callbacks on module exit

[Willem de Bruijn]

Jiale Yao wrote:
> Replacing or clearing a TUN eBPF program defers its destruction to
> tun_prog_free(). In the device teardown path, tun_free_netdev() can queue
> this callback as a private destructor. The rcu_barrier() in
> netdev_run_todo() runs before private destructors, so it cannot drain the
> new callback.
> 
> After the last file or persistent-device reference is released, tun can
> therefore unload before the callback runs. Drain outstanding callbacks at
> the end of module cleanup so they cannot execute from freed module text.
> 
> Fixes: 96f84061620c ("tun: add eBPF based queue selection method")
> Signed-off-by: Jiale Yao <yaojiale02@163.com>

Reviewed-by: Willem de Bruijn <willemb@google.com>

Re: [PATCH 2/3] tun: Drain eBPF RCU callbacks on module exit

[Jakub Kicinski]

On Sun, 27 Sep 2026 00:25:51 +0800 Jiale Yao wrote:
> Subject: [PATCH 2/3] tun: Drain eBPF RCU callbacks on module exit

please repost this if you expect networking to take the patch
patchwork will wait for the other emails that you did not cc us on
you shouldn't pointlessly make patches for different subsystems into 
a series 

Re:Re: [PATCH 2/3] tun: Drain eBPF RCU callbacks on module exit

[jiale yao]

Hi Jakub,
At 2026-10-02 07:12:09, "Jakub Kicinski" <kuba@kernel.org> wrote:
>On Sun, 27 Sep 2026 00:25:51 +0800 Jiale Yao wrote:
>> Subject: [PATCH 2/3] tun: Drain eBPF RCU callbacks on module exit
>
>please repost this if you expect networking to take the patch
>patchwork will wait for the other emails that you did not cc us on
>you shouldn't pointlessly make patches for different subsystems into 
>a series

Thanks for pointing this out. I have split out the TUN change and
reposted it as a standalone patch,
in https://lore.kernel.org/all/20261003093822.544964-1-yaojiale02@163.com/ 

Jiale