At the moment, use-after-free issues in RCU allocations are hard to discover with KASAN at runtime because the RCU subsystem heavily optimizes for throughput and doesn't care much about the latency between e.g. kfree_rcu() and the actual freeing; therefore, KASAN is only informed that the object is no longer accessible long after the RCU grace period has already ended. It would be helpful to have an RCU mode where the kernel essentially maintains an ordered list of active grace periods, allowing it to synchronously discover items with expired grace period on kfree_rcu()/call_rcu() (if no grace periods are active) or rcu_read_unlock() (when the last relevant grace period ended). This will necessarily cause cache contention linear in either the number of RCU read-side critical sections (if a global sequence number model is used) or the number of kfree_rcu()/call_rcu() calls (if global timestamps or a set of local sequence numbers are used for figuring out the ordering of grace periods). Since RCU read-side critical sections are much more common than kfree_rcu()/call_rcu(), it may be worth thinking about how to implement this on top of instructions like RDTSCP, so that cacheline-bouncing global synchronization only happens on kfree_rcu()/call_rcu() and when grace periods exit while kfree_rcu()/call_rcu() work items are waiting to be executed. Development of this should probably be coordinated with Paul McKenney.
This now exists as rcupdate.rcu_expedited=1 and was enabled on syzbot: https://github.com/google/syzkaller/pull/2021 ...which was added in 2012... https://github.com/torvalds/linux/commit/3705b88db0d7cc4 Paul?
Jann, if you see anything else actionable here, please reopen. Otherwise it seems to be resolved.