[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9r7EX6g-r=qB=jRCPhKKTDXVt4PMsm0xF0o26qwdP8=4A@mail.gmail.com>
Date: Fri, 14 Jun 2019 11:56:47 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Arnd Bergmann <arnd@...db.de>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Clemens Ladisch <clemens@...isch.de>,
Sultan Alsawaf <sultan@...neltoast.com>,
Waiman Long <longman@...hat.com>, X86 ML <x86@...nel.org>
Subject: Re: infinite loop in read_hpet from ktime_get_boot_fast_ns
Hi Thomas,
On Fri, Jun 14, 2019 at 11:50 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> jiffies64 uses a seqcount on 32bit as well.
Right, but not 64-bit, which is some sort of improvement I suppose.
> Hrm, I'm not a great fan of these shortcuts which cut corners based on
> 'somewhat rarely, so it should not matter'. Should not matter always
> strikes back at some point. :)
What's the actual rare event you have in mind? That on 32-bits, only
half of the value is updated while resuming from sleep? But isn't
there already a race in that case? Namely, either the boot offset is
never queried until the system has fully resumed (safe), or there's
actually some overlap, where the boot offset is queried on resumption
before it's updated. In the former case, a race isn't possible because
of other locking. In the latter case, there's already a race
contingent on the same instructions executing that's way worse. So I
wonder if this is in the category of "hasn't ever mattered" rather
than "should not matter".
> So what you are looking for is jiffies based on boot time?
Right. Just sent a patch.
Jason
Powered by blists - more mailing lists