Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
creation, 2014-09-04) forgot to update one place where we hold
the prepare_lock while creating debugfs directories. This means
we still have the chance of a deadlock that the commit was trying
to fix. Actually fix it by moving the debugfs creation outside
the prepare_lock.
Reported-by: Russell King - ARM Linux <[email protected]>
Fixes: 6314b6796e3c "clk: Don't hold prepare_lock across debugfs creation"
Signed-off-by: Stephen Boyd <[email protected]>
---
drivers/clk/clk.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 44cdc47a6cc5..c9430653ddc9 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -240,12 +240,13 @@ static const struct file_operations clk_dump_fops = {
.release = single_release,
};
-/* caller must hold prepare_lock */
static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
{
struct dentry *d;
int ret = -ENOMEM;
+ lockdep_assert_held(clk_debug_lock);
+
if (!clk || !pdentry) {
ret = -EINVAL;
goto out;
@@ -1944,7 +1945,6 @@ int __clk_init(struct device *dev, struct clk *clk)
else
clk->rate = 0;
- clk_debug_register(clk);
/*
* walk the list of orphan clocks and reparent any that are children of
* this clock
@@ -1979,6 +1979,9 @@ int __clk_init(struct device *dev, struct clk *clk)
out:
clk_prepare_unlock();
+ if (!ret)
+ clk_debug_register(clk);
+
return ret;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On Fri, Dec 12, 2014 at 03:04:16PM -0800, Stephen Boyd wrote:
> Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
> creation, 2014-09-04) forgot to update one place where we hold
> the prepare_lock while creating debugfs directories. This means
> we still have the chance of a deadlock that the commit was trying
> to fix. Actually fix it by moving the debugfs creation outside
> the prepare_lock.
>
> Reported-by: Russell King - ARM Linux <[email protected]>
Please use "Russell King <[email protected]>" rather than this
address, thanks.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
Quoting Russell King - ARM Linux (2014-12-12 15:05:43)
> On Fri, Dec 12, 2014 at 03:04:16PM -0800, Stephen Boyd wrote:
> > Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
> > creation, 2014-09-04) forgot to update one place where we hold
> > the prepare_lock while creating debugfs directories. This means
> > we still have the chance of a deadlock that the commit was trying
> > to fix. Actually fix it by moving the debugfs creation outside
> > the prepare_lock.
> >
> > Reported-by: Russell King - ARM Linux <[email protected]>
>
> Please use "Russell King <[email protected]>" rather than this
> address, thanks.
Applied to clk-next and fixed up the email address locally.
Regards,
Mike
>
> --
> FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
> according to speedtest.net.
On Fri, Dec 12, 2014 at 03:24:16PM -0800, Mike Turquette wrote:
> Quoting Russell King - ARM Linux (2014-12-12 15:05:43)
> > On Fri, Dec 12, 2014 at 03:04:16PM -0800, Stephen Boyd wrote:
> > > Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
> > > creation, 2014-09-04) forgot to update one place where we hold
> > > the prepare_lock while creating debugfs directories. This means
> > > we still have the chance of a deadlock that the commit was trying
> > > to fix. Actually fix it by moving the debugfs creation outside
> > > the prepare_lock.
> > >
> > > Reported-by: Russell King - ARM Linux <[email protected]>
> >
> > Please use "Russell King <[email protected]>" rather than this
> > address, thanks.
>
> Applied to clk-next and fixed up the email address locally.
Please make sure it gets into stable kernels too as v3.18 suffers from
this bug, thanks.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Fri, 12 Dec 2014, Stephen Boyd wrote:
> Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
> creation, 2014-09-04) forgot to update one place where we hold
> the prepare_lock while creating debugfs directories. This means
> we still have the chance of a deadlock that the commit was trying
> to fix. Actually fix it by moving the debugfs creation outside
> the prepare_lock.
>
> Reported-by: Russell King - ARM Linux <[email protected]>
> Fixes: 6314b6796e3c "clk: Don't hold prepare_lock across debugfs creation"
> Signed-off-by: Stephen Boyd <[email protected]>
> + lockdep_assert_held(clk_debug_lock);
That change is not mentioned in the changelog and seems to be
unrelated to the issue at hand.
Other than that:
Reviewed-by: Thomas Gleixner <[email protected]>