All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Dong Aisheng <b29396@freescale.com>
Cc: Dong Aisheng <aisheng.dong@freescale.com>,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	mturquette@linaro.org, shawn.guo@linaro.org,
	linux-arm-kernel@lists.infradead.org,
	Ranjani.Vaidyanathan@freescale.com, b20596@freescale.com,
	r64343@freescale.com, b20788@freescale.com
Subject: Re: [PATCH RFC v1 2/5] clk: add missing lock when call clk_core_enable in clk_set_parent
Date: Wed, 6 May 2015 17:01:54 -0700	[thread overview]
Message-ID: <20150507000154.GD21794@codeaurora.org> (raw)
In-Reply-To: <20150504083549.GC4082@shlinux1.ap.freescale.net>

On 05/04, Dong Aisheng wrote:
> On Thu, Apr 30, 2015 at 12:07:47PM -0700, Stephen Boyd wrote:
> > On 04/15/15 07:26, Dong Aisheng wrote:
> > > clk_core_enable is executed without &enable_clock in clk_set_parent function.
> > > Adding it to avoid potential race condition issue.
> > >
> > > Fixes: 035a61c314eb ("clk: Make clk API return per-user struct clk instances")
> > > Cc: Mike Turquette <mturquette@linaro.org>
> > > Cc: Stephen Boyd <sboyd@codeaurora.org>
> > > Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
> > > ---
> > 
> > Can you please describe the race condition? From what I can tell there
> > is not a race condition here and we've gone around on this part of the
> > code before to fix any race conditions.
> > 
> 
> Do you mean we do not need to acquire enable lock when execute clk_core_enable
> in set_parent function? Can you help explain a bit more why?
> 
> The clk doc looks to me says the enable lock should be held across calls to
> the .enable, .disable and .is_enabled operations.
> 
> And before the commit
> 035a61c314eb ("clk: Make clk API return per-user struct clk instances"),
> all the clk_enable/disable in set_parent() is executed with lock.
> 
> A rough thinking of race condition is assuming Thread A calls
> clk_set_parent(x, y) while Thread B calls clk_enable(x), clock x is disabled
> but prepared initially, due to clk_core_enable in set_parent() is not
> executed with enable clock, the clk_core_enable may be reentrant during
> the locking time executed by B.
> Won't this be a race condition?
> 

Ah I see now. The commit text could say something like this:

Before commit 035a61c314eb ("clk: Make clk API return per-user
struct clk instances") we acquired the enable_lock in
__clk_set_parent_{before,after}() by means of calling
clk_enable(). After commit 035a61c314eb we use clk_core_enable()
in place of the clk_enable(), and clk_core_enable() doesn't
acquire the enable_lock. This opens up a race condition between
clk_set_parent() and clk_enable().

I've replaced the commit text and applied it to clk-fixes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v1 2/5] clk: add missing lock when call clk_core_enable in clk_set_parent
Date: Wed, 6 May 2015 17:01:54 -0700	[thread overview]
Message-ID: <20150507000154.GD21794@codeaurora.org> (raw)
In-Reply-To: <20150504083549.GC4082@shlinux1.ap.freescale.net>

On 05/04, Dong Aisheng wrote:
> On Thu, Apr 30, 2015 at 12:07:47PM -0700, Stephen Boyd wrote:
> > On 04/15/15 07:26, Dong Aisheng wrote:
> > > clk_core_enable is executed without &enable_clock in clk_set_parent function.
> > > Adding it to avoid potential race condition issue.
> > >
> > > Fixes: 035a61c314eb ("clk: Make clk API return per-user struct clk instances")
> > > Cc: Mike Turquette <mturquette@linaro.org>
> > > Cc: Stephen Boyd <sboyd@codeaurora.org>
> > > Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
> > > ---
> > 
> > Can you please describe the race condition? From what I can tell there
> > is not a race condition here and we've gone around on this part of the
> > code before to fix any race conditions.
> > 
> 
> Do you mean we do not need to acquire enable lock when execute clk_core_enable
> in set_parent function? Can you help explain a bit more why?
> 
> The clk doc looks to me says the enable lock should be held across calls to
> the .enable, .disable and .is_enabled operations.
> 
> And before the commit
> 035a61c314eb ("clk: Make clk API return per-user struct clk instances"),
> all the clk_enable/disable in set_parent() is executed with lock.
> 
> A rough thinking of race condition is assuming Thread A calls
> clk_set_parent(x, y) while Thread B calls clk_enable(x), clock x is disabled
> but prepared initially, due to clk_core_enable in set_parent() is not
> executed with enable clock, the clk_core_enable may be reentrant during
> the locking time executed by B.
> Won't this be a race condition?
> 

Ah I see now. The commit text could say something like this:

Before commit 035a61c314eb ("clk: Make clk API return per-user
struct clk instances") we acquired the enable_lock in
__clk_set_parent_{before,after}() by means of calling
clk_enable(). After commit 035a61c314eb we use clk_core_enable()
in place of the clk_enable(), and clk_core_enable() doesn't
acquire the enable_lock. This opens up a race condition between
clk_set_parent() and clk_enable().

I've replaced the commit text and applied it to clk-fixes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2015-05-07  0:01 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15 14:26 [PATCH RFC v1 0/5] clk: support clocks which requires parent clock on during operation Dong Aisheng
2015-04-15 14:26 ` Dong Aisheng
2015-04-15 14:26 ` [PATCH RFC v1 1/5] clk: change clk_core name of __clk_set_parent_after Dong Aisheng
2015-04-15 14:26   ` Dong Aisheng
2015-04-30 19:06   ` Stephen Boyd
2015-04-30 19:06     ` Stephen Boyd
2015-05-04  8:15     ` Dong Aisheng
2015-05-04  8:15       ` Dong Aisheng
2015-04-15 14:26 ` [PATCH RFC v1 2/5] clk: add missing lock when call clk_core_enable in clk_set_parent Dong Aisheng
2015-04-15 14:26   ` Dong Aisheng
2015-04-30 19:07   ` Stephen Boyd
2015-04-30 19:07     ` Stephen Boyd
2015-05-04  8:35     ` Dong Aisheng
2015-05-04  8:35       ` Dong Aisheng
2015-05-07  0:01       ` Stephen Boyd [this message]
2015-05-07  0:01         ` Stephen Boyd
2015-05-13  9:21         ` Dong Aisheng
2015-05-13  9:21           ` Dong Aisheng
2015-04-15 14:26 ` [PATCH RFC v1 3/5] clk: remove unneeded __clk_enable and __clk_disable Dong Aisheng
2015-04-15 14:26   ` Dong Aisheng
2015-04-30 19:09   ` Stephen Boyd
2015-04-30 19:09     ` Stephen Boyd
2015-04-30 22:05     ` Stephen Boyd
2015-04-30 22:05       ` Stephen Boyd
2015-05-04  8:16       ` Dong Aisheng
2015-05-04  8:16         ` Dong Aisheng
2015-04-15 14:26 ` [PATCH RFC v1 4/5] clk: core: add CLK_SET_PARENT_ON flags to support clocks require parent on Dong Aisheng
2015-04-15 14:26   ` Dong Aisheng
2015-05-01  1:09   ` Stephen Boyd
2015-05-01  1:09     ` Stephen Boyd
2015-05-04 10:36     ` Dong Aisheng
2015-05-04 10:36       ` Dong Aisheng
2015-05-06 23:34       ` Stephen Boyd
2015-05-06 23:34         ` Stephen Boyd
2015-05-13  9:20         ` Dong Aisheng
2015-05-13  9:20           ` Dong Aisheng
2015-04-15 14:26 ` [PATCH RFC v1 5/5] clk: introduce clk_core_enable_lock and clk_core_disable_lock functions Dong Aisheng
2015-04-15 14:26   ` Dong Aisheng
2015-05-01  1:10   ` Stephen Boyd
2015-05-01  1:10     ` Stephen Boyd
2015-05-04 10:38     ` Dong Aisheng
2015-05-04 10:38       ` Dong Aisheng
2015-04-22  6:12 ` [PATCH RFC v1 0/5] clk: support clocks which requires parent clock on during operation Dong Aisheng
2015-04-22  6:12   ` Dong Aisheng
2015-04-30  2:37   ` Dong Aisheng
2015-04-30  2:37     ` Dong Aisheng

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=20150507000154.GD21794@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=Ranjani.Vaidyanathan@freescale.com \
    --cc=aisheng.dong@freescale.com \
    --cc=b20596@freescale.com \
    --cc=b20788@freescale.com \
    --cc=b29396@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=r64343@freescale.com \
    --cc=shawn.guo@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.