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 00:35:06 +0100 [thread overview]
Message-ID: <875xp9xiz9.ffs@tglx> (raw)
In-Reply-To: <CANDhNCoUyqvFa=mqrXra2KQ4ryeTnj-HkO4y8cxtQJyYZWz-2Q@mail.gmail.com>
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.
Thanks,
tglx
next prev parent reply other threads:[~2024-10-30 23:35 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 [this message]
2024-10-31 10:53 ` Thomas Gleixner
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=875xp9xiz9.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox