On 18 June 2018 at 17:54, Arnd Bergmann arnd@arndb.de wrote:
On Mon, Jun 18, 2018 at 5:50 PM, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 18 June 2018 at 17:49, Arnd Bergmann arnd@arndb.de wrote:
On Mon, Jun 18, 2018 at 5:47 PM, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 18 June 2018 at 16:17, Arnd Bergmann arnd@arndb.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);elseatomic64_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.
Won't we have that same problem in 2038?
No, it goes from 0x7fffffff00000000 to 0x8000000000000000, followed by 0x8000000001000000.
Ah, right. I'm with you now :-)
I'll queue this in the efi tree.