linux-kernel - Re: [PATCH v2 1/4] clk: Don't cache errors from clk_ops::get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Feb 2020 15:27:59 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Jerome Brunet <jbrunet@...libre.com>,
        Michael Turquette <mturquette@...libre.com>
Cc:     linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        Douglas Anderson <dianders@...omium.org>,
        Heiko Stuebner <heiko@...ech.de>
Subject: Re: [PATCH v2 1/4] clk: Don't cache errors from clk_ops::get_phase()

Quoting Jerome Brunet (2020-02-06 00:26:06)
> 
> On Thu 06 Feb 2020 at 00:27, Stephen Boyd <sboyd@...nel.org> wrote:
> 
> > We don't check for errors from clk_ops::get_phase() before storing away
> > the result into the clk_core::phase member. This can lead to some fairly
> > confusing debugfs information if these ops do return an error. Let's
> > skip the store when this op fails to fix this. While we're here, move
> > the locking outside of clk_core_get_phase() to simplify callers from
> > the debugfs side.
> >
> > Cc: Douglas Anderson <dianders@...omium.org>
> > Cc: Heiko Stuebner <heiko@...ech.de>
> > Cc: Jerome Brunet <jbrunet@...libre.com>
> > Signed-off-by: Stephen Boyd <sboyd@...nel.org>
> > ---
> >  drivers/clk/clk.c | 48 +++++++++++++++++++++++++++++++----------------
> >  1 file changed, 32 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index d529ad67805c..26213e82f5f9 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2660,12 +2660,14 @@ static int clk_core_get_phase(struct clk_core *core)
> >  {
> >       int ret;
> >  
> > -     clk_prepare_lock();
> 
> Should the function name get the "_nolock" suffix then ?
> 

I figure we can add such a one if clk_core_ prefix isn't enough to
differentiate.