From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org,
Alexander Shishkin <alexander.shishkin@linux.intel.com>
Subject: [PATCH v3 4/9] stm class: Fix locking in unbinding policy path
Date: Tue, 22 Dec 2015 17:25:18 +0200 [thread overview]
Message-ID: <1450797923-23072-5-git-send-email-alexander.shishkin@linux.intel.com> (raw)
In-Reply-To: <1450797923-23072-1-git-send-email-alexander.shishkin@linux.intel.com>
Right now, if stm device removal has to unbind from a policy (that is,
an stm device that has STP policy, gets removed), it will trigger a
nested lock on the stm device's policy mutex.
This patch fixes the problem by moving the locking from the policy
unbinding to policy removal (configfs path), where it's actually needed;
the other caller of the policy unbinding function already takes the
mutex around the call.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
drivers/hwtracing/stm/policy.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 11ab6d01ad..94d3abfb73 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -272,13 +272,17 @@ void stp_policy_unbind(struct stp_policy *policy)
{
struct stm_device *stm = policy->stm;
+ /*
+ * stp_policy_release() will not call here if the policy is already
+ * unbound; other users should not either, as no link exists between
+ * this policy and anything else in that case
+ */
if (WARN_ON_ONCE(!policy->stm))
return;
- mutex_lock(&stm->policy_mutex);
- stm->policy = NULL;
- mutex_unlock(&stm->policy_mutex);
+ lockdep_assert_held(&stm->policy_mutex);
+ stm->policy = NULL;
policy->stm = NULL;
stm_put_device(stm);
@@ -287,8 +291,16 @@ void stp_policy_unbind(struct stp_policy *policy)
static void stp_policy_release(struct config_item *item)
{
struct stp_policy *policy = to_stp_policy(item);
+ struct stm_device *stm = policy->stm;
+ /* a policy *can* be unbound and still exist in configfs tree */
+ if (!stm)
+ return;
+
+ mutex_lock(&stm->policy_mutex);
stp_policy_unbind(policy);
+ mutex_unlock(&stm->policy_mutex);
+
kfree(policy);
}
--
2.6.4
next prev parent reply other threads:[~2015-12-22 15:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-22 15:25 [PATCH v3 0/9] stm/intel_th: Updates for 4.4 Alexander Shishkin
2015-12-22 15:25 ` [PATCH v3 1/9] stm class: Hide STM-specific options if STM is disabled Alexander Shishkin
2015-12-22 15:25 ` [PATCH v3 2/9] intel_th: INTEL_TH should depend on HAS_DMA Alexander Shishkin
2015-12-22 15:25 ` [PATCH v3 3/9] stm class: Select CONFIG_SRCU Alexander Shishkin
2015-12-22 15:25 ` Alexander Shishkin [this message]
2015-12-22 15:25 ` [PATCH v3 5/9] stm class: Fix link list locking Alexander Shishkin
2015-12-22 15:25 ` [PATCH v3 6/9] stm class: Fix an off-by-one in master array allocation Alexander Shishkin
2015-12-22 15:25 ` [PATCH v3 7/9] stm class: Prevent user-controllable allocations Alexander Shishkin
2015-12-22 15:25 ` [PATCH v3 8/9] intel_th: pci: Add Apollo Lake SOC support Alexander Shishkin
2015-12-22 15:25 ` [PATCH v3 9/9] intel_th: pci: Add Broxton " Alexander Shishkin
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=1450797923-23072-5-git-send-email-alexander.shishkin@linux.intel.com \
--to=alexander.shishkin@linux.intel.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®