In Classic RCU, a single read-side critical section could indefinitely delay all RCU callbacks, for example, as follows:
1 /* BUGGY: Do not use!! */ 2 rcu_read_lock(); 3 schedule_timeout_interruptible(longdelay); 4 rcu_read_unlock(); |
This sort of behavior might be tolerated if RCU were used only within a single subsystem that was carefully designed to withstand long-term delay of grace periods. It is the fact that a single RCU read-side bug in one isolated subsystem can delay all users of RCU that forced these long-term RCU read-side delays to be abolished.
One way around this issue is for grace-period detection to be performed on a subsystem-by-subsystem basis, so that a lethargic RCU reader will delay grace periods only within that reader's subsystem. Since each subsystem can have only a bounded number of memory blocks awaiting a grace period, and since the number of subsystems is also presumably bounded, the total amount of memory awaiting a grace period will also be bounded. The designer of a given subsystem is responsible for: (1) ensuring that SRCU read-side sleeping is bounded and (2) limiting the amount of memory waiting for synchronize_srcu().D.1
This is precisely the approach that SRCU takes, as described in the following section.
Paul E. McKenney 2011-12-16