[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0dP+zvucn=_um1zRgBYQCskrhqa2KNSDtnpSu199baWw@mail.gmail.com>
Date: Mon, 18 Jun 2018 17:49:25 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: y2038 Mailman List <y2038@...ts.linaro.org>,
Tyler Baicar <tbaicar@...eaurora.org>,
Will Deacon <will.deacon@....com>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
Yazen Ghannam <yazen.ghannam@....com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
gengdongjiu <gengdongjiu@...wei.com>,
linux-efi <linux-efi@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] efi: cper: avoid using get_seconds()
On Mon, Jun 18, 2018 at 5:47 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 18 June 2018 at 16:17, Arnd Bergmann <arnd@...db.de> wrote:
>> - atomic64_set(&seq, ((u64)get_seconds()) << 32);
>> + if (!atomic64_read(&seq)) {
>> + time64_t time = ktime_get_real_seconds();
>> +
>> + /*
>> + * This code is unlikely to still be needed in year 2106,
>> + * but just in case, let's use a few more bits for timestamps
>> + * after y2038 to be sure they keep increasing monotonically
>> + * for the next few hundred years...
>> + */
>> + if (time < 0x80000000)
>> + atomic64_set(&seq, (ktime_get_real_seconds()) << 32);
>> + else
>> + atomic64_set(&seq, 0x8000000000000000ull |
>> + ktime_get_real_seconds() << 24);
>> + }
>
> Given that these values are never decoded and interpreted as
> timestamps, can't we simply switch to the second flavour immediately?
I considered that, but the downside would be that all future filenames would
come before all past file names. I don't know if the order is important at
all, but the current implementation at least looks like it's intended to keep
all file names strictly sorted across boots.
Arnd
Powered by blists - more mailing lists