linux-kernel - Re: Re: [PATCH] clk/meson: fixes memleak issue in init err branch

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]

Message-ID: <CAFBinCD0CP9y5tKqXQKzKRj-UKvQeahyGA6cD43wVqeE5uQRBA@mail.gmail.com>
Date:   Sat, 2 May 2020 13:10:01 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     赵军奎 <bernard@...o.com>
Cc:     opensource.kernel@...o.com,
        Neil Armstrong <narmstrong@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Kevin Hilman <khilman@...libre.com>,
        linux-kernel@...r.kernel.org, linux-amlogic@...ts.infradead.org,
        linux-clk@...r.kernel.org, Jerome Brunet <jbrunet@...libre.com>
Subject: Re: Re: [PATCH] clk/meson: fixes memleak issue in init err branch

Hi Bernhard,

On Thu, Apr 30, 2020 at 5:33 AM 赵军奎 <bernard@...o.com> wrote:
[...]
> I am not sure whether my understanding is correct.
> I feels that the failure of our module can not block the entire kernel from starting.
> Maybe we should throw an exception, clear the status, as "old way",
> and continue to execute the kernel.
I added a HACK right at the beginning of meson8b_clkc_init_common where I added:
if (true)
  return; // HACK: simulate an error

when I then try to boot the resulting kernel there's silence after
u-boot is done:
Starting kernel ...
(output stops here)

This is expected, because the UART clock is provided by this clock
controller. And since we didn't register it there will be no serial
output.

Then I added "earlycon" to the boot args and attached the output to this mail.
The result is still not great, because only the early console is
working. Also timer initialization (smp_twd) as well as SMP startup
failed.
All other peripherals also failed to probe, because almost everything
on this SoC depends on this main clock controller (the two exceptions
that I know are: the always-on remote processor and the DDR clock
controller).

I hope that this explains the behavior when the main clock and reset
controllers are not registered (either due to my hack or if there's an
actual error).
Please let me know if you have more questions.
Now I would like to hear your suggestion, how to handle errors in this driver!

Regards
Martin

View attachment "earlycon-output.txt" of type "text/plain" (22955 bytes)