linux-kernel - Re: [patch 2/2] timekeeping: Always check for negative motion

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: <CANDhNCo1RtcfqUJsuAQ+HdS7E29+gByfek5-4KYiAk3Njk4M3Q@mail.gmail.com>
Date: Wed, 27 Nov 2024 14:08:47 -0800
From: John Stultz <jstultz@...gle.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, 
	Anna-Maria Behnsen <anna-maria@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>, 
	Stephen Boyd <sboyd@...nel.org>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [patch 2/2] timekeeping: Always check for negative motion

On Sun, Nov 24, 2024 at 4:48 PM Guenter Roeck <linux@...ck-us.net> wrote:
> On Thu, Oct 31, 2024 at 01:04:08PM +0100, Thomas Gleixner wrote:
> > clocksource_delta() has two variants. One with a check for negative motion,
> > which is only selected by x86. This is a historic leftover as this function
> > was previously used in the time getter hot paths.
> >
> > Since 135225a363ae timekeeping_cycles_to_ns() has unconditional protection
> > against this as a by-product of the protection against 64bit math overflow.
> >
> > clocksource_delta() is only used in the clocksource watchdog and in
> > timekeeping_advance(). The extra conditional there is not hurting anyone.
> >
> > Remove the config option and unconditionally prevent negative motion of the
> > readout.
> >
> > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
>
> This patch causes the kuda-bmc qemu emulation to stall. Reverting it fixes
> the problem.
>

I'm not familiar with kuda-bmc and I'm not finding too many details
searching on it.
>From other qemu bmc reults I'm guessing this is an arm32 architecture?

Do you have any more details about where it's stalling?  Also dmesg
details might help illuminate what clocksource was used, etc.
I'm wondering if the clocksource mask value is incorrect for the
clocksource being used here?

thanks
-john