Re: [PATCH v5] selinux: sidtab: reverse lookup hash table

[Jeffrey Vander Stoep <jeffv@google.com>]

> > 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.
>