> > If you use the existing _rcu accessors you will get correctly enforced > > dependency ordering on the reader side and correctly placed release > > ordering on the updater side. I don't think that's a big overkill, and > > you can use the RCU accessors to achieve the lockless traversal. > > OK, but you don't need the read_lock()/unlock(), rcu_head field in the > entries, and kfree_rcu(), right? Hmm... I can get rid of rcu_head/kfree_rcu in any case because we never remove items during normal use so we don't require the "rcu grace period". > > > > > hlist_add() is not safe against a concurrent traversal because the > > WRITE_ONCE() provides no memory ordering guarantees, allowing the readers > > to see an uninitialised node. > > Right, so we would need a new function that does smp_store_release() instead. > > > > > How exactly would list_for_each_entry_lockless() and hlist_add_something() > > differ from the RCU variants, assuming they're implemented correctly? > > Looking at the implementation of rcu_dereference() and > rcu_assign_pointer(), they would probably be practically the same, > except the rcu_read_lock_held() check in rcu_dereference(). That and > they would clearly communicate that they are not doing actual RCU, but > just allow lockless traversal of an add-only hlist. > > -- > Ondrej Mosnacek <omosnace at redhat dot com> > Software Engineer, Security Technologies > Red Hat, Inc. >
