linux-kernel - Re: [RFC] opp: Fixup release of clock when using set/put clkname

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] [day] [month] [year] [list]

Date:   Wed, 15 Apr 2020 10:43:01 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Rajendra Nayak <rnayak@...eaurora.org>
Cc:     sboyd@...nel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] opp: Fixup release of clock when using set/put clkname

On 14-04-20, 20:35, Rajendra Nayak wrote:
> However, given I call these unconditionally in common drivers and on
> some (old) platforms we really don't have an OPP table (only scale clocks)
> things get a little tricky. So looks like the ref counting in such cases
> gets messed up, and we end up with dev_pm_opp_of_remove_table() calling
> _opp_table_kref_release() and releasing the clock, and then the subsequent
> call to dev_pm_opp_put_clkname() crashes.

We aren't supposed to call dev_pm_opp_of_remove_table() if
dev_pm_opp_of_add_table() isn't called or it failed. Either we can
handle this in core, which I would like to avoid, or just keep a
variable to track it in the driver, which will be easy enough I guess.

-- 
viresh