From: Will Deacon <will.deacon@arm.com>
To: linux-kernel@vger.kernel.org
Cc: paulmck@linux.vnet.ibm.com, Will Deacon <will.deacon@arm.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: [PATCH v2 1/4] security/apparmor: Replace homebrew use of write_can_lock with lockdep
Date: Tue, 3 Oct 2017 19:25:26 +0100 [thread overview]
Message-ID: <1507055129-12300-1-git-send-email-will.deacon@arm.com> (raw)
The lockdep subsystem provides a robust way to assert that a lock is
held, so use that instead of write_can_lock, which can give incorrect
results for qrwlocks.
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
security/apparmor/include/lib.h | 11 -----------
security/apparmor/label.c | 8 ++++----
2 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/security/apparmor/include/lib.h b/security/apparmor/include/lib.h
index 436b3a722357..f546707a2bbb 100644
--- a/security/apparmor/include/lib.h
+++ b/security/apparmor/include/lib.h
@@ -19,17 +19,6 @@
#include "match.h"
-/* Provide our own test for whether a write lock is held for asserts
- * this is because on none SMP systems write_can_lock will always
- * resolve to true, which is what you want for code making decisions
- * based on it, but wrong for asserts checking that the lock is held
- */
-#ifdef CONFIG_SMP
-#define write_is_locked(X) !write_can_lock(X)
-#else
-#define write_is_locked(X) (1)
-#endif /* CONFIG_SMP */
-
/*
* DEBUG remains global (no per profile flag) since it is mostly used in sysctl
* which is not related to profile accesses.
diff --git a/security/apparmor/label.c b/security/apparmor/label.c
index c5b99b954580..ad28e03a6f30 100644
--- a/security/apparmor/label.c
+++ b/security/apparmor/label.c
@@ -80,7 +80,7 @@ void __aa_proxy_redirect(struct aa_label *orig, struct aa_label *new)
AA_BUG(!orig);
AA_BUG(!new);
- AA_BUG(!write_is_locked(&labels_set(orig)->lock));
+ lockdep_assert_held_exclusive(&labels_set(orig)->lock);
tmp = rcu_dereference_protected(orig->proxy->label,
&labels_ns(orig)->lock);
@@ -571,7 +571,7 @@ static bool __label_remove(struct aa_label *label, struct aa_label *new)
AA_BUG(!ls);
AA_BUG(!label);
- AA_BUG(!write_is_locked(&ls->lock));
+ lockdep_assert_held_exclusive(&ls->lock);
if (new)
__aa_proxy_redirect(label, new);
@@ -608,7 +608,7 @@ static bool __label_replace(struct aa_label *old, struct aa_label *new)
AA_BUG(!ls);
AA_BUG(!old);
AA_BUG(!new);
- AA_BUG(!write_is_locked(&ls->lock));
+ lockdep_assert_held_exclusive(&ls->lock);
AA_BUG(new->flags & FLAG_IN_TREE);
if (!label_is_stale(old))
@@ -645,7 +645,7 @@ static struct aa_label *__label_insert(struct aa_labelset *ls,
AA_BUG(!ls);
AA_BUG(!label);
AA_BUG(labels_set(label) != ls);
- AA_BUG(!write_is_locked(&ls->lock));
+ lockdep_assert_held_exclusive(&ls->lock);
AA_BUG(label->flags & FLAG_IN_TREE);
/* Figure out where to put new node */
--
2.1.4
next reply other threads:[~2017-10-03 18:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-03 18:25 Will Deacon [this message]
2017-10-03 18:25 ` [PATCH v2 2/4] locking: Remove {read,spin,write}_can_lock Will Deacon
2017-10-10 11:06 ` [tip:locking/core] locking/core: Remove {read,spin,write}_can_lock() tip-bot for Will Deacon
2017-10-03 18:25 ` [PATCH v2 3/4] locking: Remove dummy arch_{read,spin,write}_relax implementations Will Deacon
2017-10-10 11:07 ` [tip:locking/core] locking/arch: Remove dummy arch_{read,spin,write}_relax() implementations tip-bot for Will Deacon
2017-10-03 18:25 ` [PATCH v2 4/4] locking: Remove dummy arch_{read,spin,write}_lock_flags implementations Will Deacon
2017-10-10 11:07 ` [tip:locking/core] locking/arch: Remove dummy arch_{read,spin,write}_lock_flags() implementations tip-bot for Will Deacon
2017-10-10 11:06 ` [tip:locking/core] locking/rwsem, security/apparmor: Replace homebrew use of write_can_lock() with lockdep tip-bot for Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1507055129-12300-1-git-send-email-will.deacon@arm.com \
--to=will.deacon@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox