Messages in this thread | | | Date | Wed, 5 Aug 2020 16:08:52 -0700 | From | "Paul E. McKenney" <> | Subject | Finally starting on short RCU grace periods, but... |
| |
Hello!
If I remember correctly, one of you asked for a way to shorten RCU grace periods so that KASAN would have a better chance of detecting bugs such as pointers being leaked out of RCU read-side critical sections. I am finally starting entering and testing code for this, but realized that I had forgotten a couple of things:
1. I don't remember exactly who asked, but I suspect that it was Kostya. I am using his Reported-by as a placeholder for the moment, but please let me know if this should be adjusted.
2. Although this work is necessary to detect situtions where call_rcu() is used to initiate a grace period, there already exists a way to make short grace periods that are initiated by synchronize_rcu(), namely, the rcupdate.rcu_expedited kernel boot parameter. This will cause all calls to synchronize_rcu() to act like synchronize_rcu_expedited(), resulting in about 2-3 orders of magnitude reduction in grace-period latency on small systems (say 16 CPUs).
In addition, I plan to make a few other adjustments that will increase the probability of KASAN spotting a pointer leak even in the rcupdate.rcu_expedited case.
But if you would like to start this sort of testing on current mainline, rcupdate.rcu_expedited is your friend!
Thanx, Paul
| |