[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <875xp9xiz9.ffs@tglx>
Date: Thu, 31 Oct 2024 00:35:06 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: John Stultz <jstultz@...gle.com>
Cc: kernel test robot <oliver.sang@...el.com>, Anna-Maria Behnsen
<anna-maria@...utronix.de>, oe-lkp@...ts.linux.dev, lkp@...el.com,
linux-kernel@...r.kernel.org, x86@...nel.org, Marco Elver
<elver@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, Frederic
Weisbecker <frederic@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
Stephen Boyd <sboyd@...nel.org>
Subject: Re: [tip:timers/core] [timekeeping] 5aa6c43eca:
BUG:KCSAN:data-race_in_timekeeping_debug_get_ns/timekeeping_update_from_shadow
On Wed, Oct 30 2024 at 15:16, John Stultz wrote:
> On Wed, Oct 30, 2024 at 1:50 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>> But that aside, since 135225a363ae timekeeping_cycles_to_ns() is fully
>> overflow protected and unconditionally handles negative motion (before
>> it was x86 only), the value of timekeeping_debug_get_ns() becomes
>> questionable.
>>
>> I'm leaning towards removing it completely.
>>
>> John?
>
> Yeah. I could be wrong, but I'm not sure of anyone beyond myself that
> has really utilized the TIMEKEEPING_DEBUG logic (and I've not enabled
> it myself in a few years). I don't think we've had any problem reports
> from it either.
>
> So no objection from me.
The question is whether we want to preserve the remaining 'offset'
check. I.e. either discard it or make it unconditional? It's cheep now.
Thanks,
tglx
Powered by blists - more mailing lists