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: <65b412ef-fc57-4988-bf92-3c924a1c74a5@roeck-us.net>
Date: Wed, 27 Nov 2024 15:02:18 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: John Stultz <jstultz@...gle.com>
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 11/27/24 14:08, John Stultz wrote:
> 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.

Sorry, I keep misspelling it. kudo-bmc.

>>>From other qemu bmc reults I'm guessing this is an arm32 architecture?
> 
Yes.

> 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?
> 

An example log is at [1]. It says

clocksource: npcm7xx-timer1: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 597268854 ns
...
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
...
clocksource: Switched to clocksource npcm7xx-timer1

I don't know where exactly it stalls; sometime after handover to userspace.
I'll be happy to do some more debugging, but you'll nee to let me know what
to look for.

Thanks,
Guenter

---
[1] https://kerneltests.org/builders/qemu-arm-v7-master/builds/324/steps/qemubuildcommand/logs/stdio