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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <16fd590e-7a00-4e71-a003-d6aafa83567d@oss.qualcomm.com>
Date: Thu, 22 May 2025 21:47:35 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Stephen Boyd <sboyd@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Konrad Dybcio <konradybcio@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH] clk: Warn (and therefore taint the kernel) on
 clk_ignore_unused

On 3/4/25 8:34 PM, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2025-03-03 15:17:21)
>> On Tue, 4 Mar 2025 at 00:16, Florian Fainelli
>> <florian.fainelli@...adcom.com> wrote:
>>>
>>> On 3/3/25 14:48, Stephen Boyd wrote:
>>>> Quoting Konrad Dybcio (2025-02-01 08:52:30)
> [...]
>>>>>
>>>>> The clock subsystem plays a crucial part in this quest, as even if
>>>>> the clock controllers themselves don't draw a lot of power when on
>>>>> (comparatively), improper description of clock requirements has been
>>>>> the #1 cause of incomplete/incorrect devicetree bindings in my
>>>>> experience.
>>>>
>>>> What is a user supposed to do about this warning stack? We already print
>>>> a warning. I don't see us dumping the stack when a driver is unfinished
>>>> and doesn't implement runtime PM to save power.
>>>>
>>>
>>> Agreed, I don't think this is tremendously helpful given that it does
>>> not even tell you what part is incomplete, it's just a broad warning for
>>> the entire system.
>>>
>>> Assuming you have a clock provided that can be used to turn clocks off,
>>> and you did not boot with 'clk_ignore_unused' set on the kernel command
>>> line, then you should discover pretty quickly which driver is not
>>> managing the clocks as it should no?
>>
>> Unfortunately it's sometimes not that easy. And some developers
>> pretend that 'clk_ignore_unused' is a viable way to run the system.
>>
> 
> Maybe we would be better off with a config option that removes the clk
> ignore unused ability entirely. Then you can have a kernel config check
> somewhere in the build process that verifies that a user can't even set
> the kernel commandline to change the behavior.

I used WARN specifically to taint the kernel (which would in turn throw off
any reasonable CI checks). Perhaps we could add a Kconfig entry (unless
there already is one) that would do the same, and clk_ignore_unused could
be gated behind it.

But then, it would make it harder to debug production kernels with that
parameter, which could potentially come in handy too

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ