On 18 June 2018 at 17:49, Arnd Bergmann <[email protected]> wrote: > On Mon, Jun 18, 2018 at 5:47 PM, Ard Biesheuvel > <[email protected]> wrote: >> On 18 June 2018 at 16:17, Arnd Bergmann <[email protected]> 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.
Won't we have that same problem in 2038? > 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 _______________________________________________ Y2038 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/y2038
