[PATCH selinux-next] selinux: Annotate lockdep for services locks
Stephen Smalley
sds at tycho.nsa.gov
Tue Feb 20 13:59:02 UTC 2018
On Mon, 2018-02-19 at 16:18 +0100, Peter Enderborg wrote:
> From: Peter <peter.enderborg at sony.com>
>
> The locks are moved to dynamic allocation, we need to
> help the lockdep system to classify the locks.
> This adds to lockdep annotation for the page mutex and
> for the ss lock.
>
> Signed-off-by: Peter Enderborg <peter.enderborg at sony.com>
> ---
> This is the rebase of suggested patches from selinuxns tree
> and are intended to be applyed on top of:
> selinux: wrap global selinux state
> from Stephen Smalley
>
> security/selinux/ss/services.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/security/selinux/ss/services.c
> b/security/selinux/ss/services.c
> index 3698352213d7..a741552e22b5 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -81,11 +81,15 @@ char
> *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> };
>
> static struct selinux_ss selinux_ss;
> +static struct lock_class_key selinux_ss_class_key;
> +static struct lock_class_key selinux_status_class_key;
>
> void selinux_ss_init(struct selinux_ss **ss)
> {
> rwlock_init(&selinux_ss.policy_rwlock);
> + lockdep_set_class(&selinux_ss.policy_rwlock,
> &selinux_ss_class_key);
> mutex_init(&selinux_ss.status_lock);
> + lockdep_set_class(&selinux_ss.status_lock,
> &selinux_status_class_key);
> *ss = &selinux_ss;
> }
Pardon my ignorance, but can you explain why we need an explicit call
to lockdep_set_class() here? I see it used for e.g. the inode i_lock,
but there the class is per-file_system_type. It doesn't seem to be
always be used for all locks when they are dynamically initialized or
allocated, e.g. get_empty_filp does not call lockdep_set_class() for
struct file's f_owner.lock or f_lock even though they are dynamically
allocated and initialized. What makes this case different?
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive
mailing list