linux-kernel - Re: [PATCH v2 1/2] soc/tegra: pmc: Query PCLK clock rate at probe time

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:   Mon, 29 Jul 2019 16:07:37 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Peter De Schrijver <pdeschrijver@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>
Cc:     linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] soc/tegra: pmc: Query PCLK clock rate at probe
 time

25.07.2019 14:15, Dmitry Osipenko пишет:
> 25.07.2019 12:36, Peter De Schrijver пишет:
>> On Tue, Jul 23, 2019 at 05:35:10AM +0300, Dmitry Osipenko wrote:
>>> The PCLK clock is running off SCLK, which is a critical clock that is
>>> very unlikely to randomly change its rate. It's also a bit clumsy (and
>>> apparently incorrect) to query the clock's rate with interrupts being
>>> disabled because clk_get_rate() takes a mutex and that's the case during
>>> suspend/cpuidle entering.
>>>
>>
>> SCLK and PCLK certainly can change rate at runtime, although the code to
>> handle this hasn't reached upstream yet.
> 
> Okay, maybe this patch is indeed not very worthwhile then. I'm leaving
> it up to you, guys, to decide.
> 

I now recalled what was the initial reason for this patch because
happened to bump into the problem once again.. it's really problematic
to call clk_get_rate() with the disabled preemption because some clk
notifier handler may block (EMC) and cause reschedule, hence the CCF
'prepare' mutex is kept locked during of CPUIDLE driver entering LP2
state and thus causing system lockup, since scheduling with the disabled
interrupts obviously won't work well.

So this patch actually is needed to be applied or some other solution
have to be provided. Since PCLK rate currently isn't altering anywhere
in the kernel, I'd suggest to imply apply this series. Please let me
know if you have any objections. I may re-iterate this patch with an
extended commit message, describing the resolved problem in a more
details, if necessary.