linux-kernel - Re: [PATCH v3 2/3] clk: divider: Switch from .round_rate to .determine

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]

Message-ID: <162525965307.3570193.9588997729905273358@swboyd.mtv.corp.google.com>
Date:   Fri, 02 Jul 2021 14:00:53 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Marek Szyprowski <m.szyprowski@...sung.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     Guenter Roeck <linux@...ck-us.net>, mturquette@...libre.com,
        linux-clk@...r.kernel.org,
        Neil Armstrong <narmstrong@...libre.com>, jbrunet@...libre.com,
        khilman@...libre.com, linux-kernel@...r.kernel.org,
        linux-amlogic@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 2/3] clk: divider: Switch from .round_rate to .determine_rate by default

Quoting Marek Szyprowski (2021-07-02 05:46:11)
> Hi
> 
> On 02.07.2021 11:19, Martin Blumenstingl wrote:
> > Hi Stephen,
> >
> > On Fri, Jul 2, 2021 at 3:02 AM Stephen Boyd <sboyd@...nel.org> wrote:
> > [...]
> >> My guess is that we have drivers copying the clk_ops from the
> >> divider_ops structure and so they are copying over round_rate but not
> >> determine_rate.
> > I just learned something new - thanks for investigating this as well!
> >
> > $ git grep "clk_divider_ops\.round_rate" drivers/
> > drivers/clk/bcm/clk-bcm2835.c:  return clk_divider_ops.round_rate(hw,
> > rate, parent_rate);
> 
> I confirm that this issue appears also on Raspberry Pi 3b+ board. I was 
> about to write a bug report, but you were faster. The funny thing is 
> that is so nondeterministic, that automated bisecting failed to catch it.
> 

I'd think it was deterministic. The function pointer is NULL after this
patch so it should always try to set the PC to 0 and fail to execute.
Unless that is somehow executable?