From: Thomas Gleixner <tglx@linutronix.de>
To: John Stultz <jstultz@google.com>
Cc: kernel test robot <oliver.sang@intel.com>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, x86@kernel.org,
Marco Elver <elver@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Frederic Weisbecker <frederic@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Stephen Boyd <sboyd@kernel.org>
Subject: Re: [tip:timers/core] [timekeeping] 5aa6c43eca: BUG:KCSAN:data-race_in_timekeeping_debug_get_ns/timekeeping_update_from_shadow
Date: Thu, 31 Oct 2024 11:53:12 +0100 [thread overview]
Message-ID: <87o730wnl3.ffs@tglx> (raw)
In-Reply-To: <875xp9xiz9.ffs@tglx>
On Thu, Oct 31 2024 at 00:35, Thomas Gleixner wrote:
> On Wed, Oct 30 2024 at 15:16, John Stultz wrote:
>> On Wed, Oct 30, 2024 at 1:50 AM Thomas Gleixner <tglx@linutronix.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.
Nah. It's irrelevant now too. Before the time getters gained the math
overflow handling this definitely was a problem, but now it's just
noise. timekeeping_advance() can handle that case correctly.
Thanks,
tglx
prev parent reply other threads:[~2024-10-31 10:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 5:47 [tip:timers/core] [timekeeping] 5aa6c43eca: BUG:KCSAN:data-race_in_timekeeping_debug_get_ns/timekeeping_update_from_shadow kernel test robot
2024-10-30 8:50 ` Thomas Gleixner
2024-10-30 9:46 ` Marco Elver
2024-10-30 22:16 ` John Stultz
2024-10-30 23:35 ` Thomas Gleixner
2024-10-31 10:53 ` Thomas Gleixner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o730wnl3.ffs@tglx \
--to=tglx@linutronix.de \
--cc=anna-maria@linutronix.de \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=frederic@kernel.org \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=peterz@infradead.org \
--cc=sboyd@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.