On Wed, Aug 19, 2020 at 11:54 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > Convert the policy read-write lock to RCU. This is significantly > simplified by the earlier work to encapsulate the policy data > structures and refactor the policy load and boolean setting logic. > Move the latest_granting sequence number into the selinux_policy > structure so that it can be updated atomically with the policy. > Since removing the policy rwlock and moving latest_granting reduces > the selinux_ss structure to nothing more than a wrapper around the > selinux_policy pointer, get rid of the extra layer of indirection. > > At present this change merely passes a hardcoded 1 to > rcu_dereference_check() in the cases where we know we do not need to > take rcu_read_lock(), with the preceding comment explaining why. > Alternatively we could pass fsi->mutex down from selinuxfs and > apply a lockdep check on it instead. > > Based in part on earlier attempts to convert the policy rwlock > to RCU by Kaigai Kohei [1] and by Peter Enderborg [2]. > > [1] https://lore.kernel.org/selinux/6e2f9128-e191-ebb3-0e87-74bfccb0767f@xxxxxxxxxxxxx/ > [2] https://lore.kernel.org/selinux/20180530141104.28569-1-peter.enderborg@xxxxxxxx/ > > Signed-off-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx> > --- > v3 passes the selinux_policy pointer down to lower level functions > after the initial rcu_dereference() so that we never dereference it > twice on the same code path. It also corrects a missing rcu_deference() > and gets rid of some unnecessary cases of rcu_read_lock()/unlock(). > Remaining open questions include whether I should change selinuxfs > to pass down fsi->mutex so that we can use it in a lockdep check > for rcu_dereference_check() and whether the sidtab live convert is > safe after this change. I forgot to mention: v3 is relative to https://patchwork.kernel.org/patch/11724203/ on top of the selinux next branch.
