On Tuesday 17 November 2015 23:20:28 Aya Mahfouz wrote:
> Changes all the uses of time_t for the structs key
> and key_preparsed_payload to time64_t. This also
> involves the functions that use them in security/keys.
> This is to handle the y2038 problem where time_t will
> overflow in 2038.
>
> Also since time_t was a long int and time64_t is long long,
> uses of LONG_MAX and TIME_T_MAX were replaced by S64_MAX.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Signed-off-by: Aya Mahfouz <[email protected]>
Looks pretty good. Two very minor comments:
> ---
> Changelog:
> v1: The changes were originally made by Arnd Bergmann in
> relation to time_t. I've broken down a patch sent to me
> into two independent patches.
I suppose you have tried and failed to split it up into smaller chunks?
> -static time_t key_gc_next_run = LONG_MAX;
> +static time64_t key_gc_next_run = S64_MAX;
> static struct key_type *key_gc_dead_keytype;
>
> static unsigned long key_gc_flags;
> @@ -53,12 +53,12 @@ struct key_type key_type_dead = {
> * Schedule a garbage collection run.
> * - time precision isn't particularly important
> */
> -void key_schedule_gc(time_t gc_at)
> +void key_schedule_gc(time64_t gc_at)
> {
> unsigned long expires;
> - time_t now = current_kernel_time().tv_sec;
> + time64_t now = ktime_get_real_seconds();
>
> - kenter("%ld", gc_at - now);
> + kenter("%ld", (long)(gc_at - now));
>
> if (gc_at <= now || test_bit(KEY_GC_REAP_KEYTYPE, &key_gc_flags)) {
> kdebug("IMMEDIATE");
I noticed now that this is wrong when gc_at is S64_MAX, because that
would overflow a 'long'. The code currently doesn't appear to do that,
but it's safer to just print it as a "%lld" instead as you do elsehwere.
Arnd
_______________________________________________
Y2038 mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/y2038
