On 2026-07-08 12:22:58 [-0700], Paul E. McKenney wrote:

The RCU-callback ordering guarantees are quite weak:

…
So this is not working.

What you maybe *could* do is to have the two RCU callbacks communicate,
so that the last one to be invoked did the work of both of them.  For
example, use a shared variable initialized to 2, then have each callback
do atomic_dec_and_test(), with the "winner" doing the work.

Would that do the trick?

This would work but we would have to fix each one or make it slower for
everyone in the common case. So I think adding a rcu_barrier() to module
unload wouldn't be that bad and Petr did not say "get out" so ;)

I've been looking a bit more:
- fs/netfs/objects.c
  call_rcu(&rreq->rcu, netfs_free_request_rcu). No rcu_barrier or
  flush_worker. 

- net/sched/sch_taprio.c
  call_rcu(&oper->rcu, taprio_free_sched_cb) from with the destroy
  callback. There is a rcu_barrier() but for classification not qdisc.

- drivers/net/tun.c.
  tun_free_netdev() from the net_device::priv_destructor.

The net things _might_ be okay since there is netdev_run_todo() with a
rcu_barrier() which is run at rtnl_unlock(). So it might work.

- drivers/vfio/pci/vfio_pci_core.c
  call_rcu() but I don't see anything rcu_barrier() like.

- security/keys/trusted-keys/trusted_core.c 
  security/keys/encrypted-keys/encrypted.c
  call_rcu() from an update callback. No rcu_barrier in security/.
  This looks "easy".

- drivers/gpu/drm/lima/lima_sched.c
  lima_fence_release() does call_rcu() from an release callback. Don't
  see anything that would enforce a rcu barrier here. The remove path
  has also a lima_sched_slab_fini() which removes the slab cache used in
  the rcu callback.

And we had the infinibad thing which got fixed in the meantime.
So I *think* this qualifies for an rcu_barrier() in the module unload
path. No objections I guess?

							Thanx, Paul

Sebastian