Messages in this thread | | | Date | Mon, 25 Nov 2013 18:59:24 +0800 | From | Xiao Guangrong <> | Subject | Re: [PATCH v3 07/15] KVM: MMU: introduce nulls desc |
| |
Hi Peter,
On 11/25/2013 05:31 PM, Peter Zijlstra wrote: > On Fri, Nov 22, 2013 at 05:14:29PM -0200, Marcelo Tosatti wrote: >> Also, there is no guarantee of termination (as long as sptes are >> deleted with the correct timing). BTW, can't see any guarantee of >> termination for rculist nulls either (a writer can race with a lockless >> reader indefinately, restarting the lockless walk every time). > > What's an rculist null?
I guess Marcelo was talking about rculist_nulls.h (Documentation/RCU/rculist_nulls.txt).
> rculists have regular termination conditions, > they'll reach the end (also head, due to circular etc..) in N steps, > where N is the number of elements. > > Of course you can keep adding elements to protract this situation, but > you'll run out of memory eventually -- you also have to make sure to > insert them after the element being read, otherwise the iteration will > simply miss them. > > Deleting an element preserves the element itself -- it has to be > RCU-freed to be part of an rculist, and the element also preserves its > fwd link, so any iterator will either not see the element, or if they're > at the element, they'll continue their iteration as normal (rculist > doesn't have backward iterators). > > A deleted element may not be re-used before an RCU grace period has > lapsed. Same as for freeing such an element. So if you want to move an > rculist element you need to: > > list_del_rcu() > synchronize_rcu(); > list_add_rcu(); > > Or use the list_splice_init_rcu() primitive which also explicitly takes > a @sync argument.
Thanks for your detailed explanation, Peter!
What about if the element is allocated from SLAB_DESTROY_BY_RCU slab? That means the element may be reused while do iteration.
| |