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:   Tue, 21 Apr 2020 23:23:47 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Harald Arnesen <harald@...gtun.org>,
        Ingo Molnar <mingo@...nel.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Giovanni Gherdovich <ggherdovich@...e.cz>
Subject: Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2)

On Tue, Apr 21, 2020 at 12:03:10PM -0700, Linus Torvalds wrote:
> On Mon, Apr 20, 2020 at 1:52 AM Harald Arnesen <harald@...gtun.org> wrote:
> >
> > Neither rc1 nor rc2 will boot on my laptop. The attached picture is all
> > I have been able to capture.
> 
> I know you saw the reply about this probably being fixed by
> 
>   https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz/
> 
> but it would be lovely if you could actually verify that that series
> of four patches does indeed fix it for you.

(not seeing the original report in the archives or my list copy)

I'm assuming it's some sort of dodgy virt setup, actual real proper
hardware should never get here like that.

> Your oops is on that divide instruction:
> 
>         freq_scale = div64_u64(acnt, mcnt);
> 
> and while we had a check for mcnt not being zero earlier, we did
> 
>         mcnt *= arch_max_freq_ratio;
> 
> after that check. I could see it becoming zero either due to an
> overflow, or due to arch_max_freq_ratio being 0.

Right, so that's not supposed to happen, as you say, we should not
enable this code if the ratio is 0, and we should not overflow mcnt due
to reading that reg once per tick.

But yeha, virt, anything can happen :/

> I think the first commit in that series is supposed to fix that
> arch_max_freq_ratio being 0 case, but it still feels like the code
> that does the divide is checking for zero in the wrong place...

Yeah, we can certainly modify that. As is, real actual hardware should
never even hit that case either. So we might as well move that check and
then also make it disable all this frequency scaling stuff if we ever do
hit it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ