On Mon, May 17, 2010 at 09:35:28PM -0400, Mathieu Desnoyers wrote:
[ . . . ]
My first thought is that we have added quite a bit of RCU consistency
check code in the past few months, so we should see what bugs they find
and what bugs escape. It is all too easy to create consistency check
code that is more trouble than it is worth.
But in the meantime, let's see what would be required to check for
failures to insert grace-period delays:
o There would need to be something like rcu_unreference(),
rcu_no_more_readers() or some such after the grace period.
The update side would then become something like the following:
oldp = rcu_dereference_protected(gp, &mylock);
rcu_assign_pointer(gp, newp);
synchronize_rcu();
rcu_no_more_readers(oldp);
kfree(oldp);
o There would need to be something to check all of the pointers
traversed in the read-side critical sections:
rcu_read_lock();
...
p1 = rcu_dereference(gp1->field1);
...
p2 = rcu_dereference(gp2->field2);
...
rcu_validate(p1);
rcu_validate(p2);
rcu_read_unlock();
One thing that bothers me about this is that we are forcing the developer
to do a lot of extra typing. For example, rcu_no_more_readers() is in
a truth-and-beauty sense redundant with kfree() -- why type both? The
same could be said about rcu_validate() and rcu_read_unlock(), but nested
RCU read-side critical sections make this difficult.
Or am I misunderstanding what you are suggesting?
Thanx, Paul
--
