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  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:   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)

Powered by blists - more mailing lists