linux-kernel - Re: linux-next: build failure after merge of the y2038 tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a3LaRt8Gszbj2QYJhERKS=T3u=fzPTXaELW4a=BJDNnzA@mail.gmail.com>
Date:   Mon, 17 Dec 2018 13:49:33 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Steve French <smfrench@...il.com>, linux-cifs@...r.kernel.org,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        palcantara@...e.de, Aurelien Aptel <aaptel@...e.com>,
        stfrench@...rosoft.com
Subject: Re: linux-next: build failure after merge of the y2038 tree

On Mon, Dec 17, 2018 at 10:11 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:

> I have applied the following merge fix patch (better versions welcome):
>
> From: Stephen Rothwell <sfr@...b.auug.org.au>
> Date: Mon, 17 Dec 2018 20:03:28 +1100
> Subject: [PATCH] cifs: update for current_kernel_time64() removal
>
> Signed-off-by: Stephen Rothwell <sfr@...b.auug.org.au>
> ---

Your patch looks correct, and the conflict should be easy to
resolve by Steve merging this into his tree, as
ktime_get_coarse_real_ts64() is readily available in mainline
kernels.

Acked-by: Arnd Bergmann <arnd@...db.de>

>  fs/cifs/dfs_cache.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/cifs/dfs_cache.c b/fs/cifs/dfs_cache.c
> index 70f9c9e2175c..d20cc94d7abd 100644
> --- a/fs/cifs/dfs_cache.c
> +++ b/fs/cifs/dfs_cache.c
> @@ -103,7 +103,7 @@ static inline bool cache_entry_expired(const struct dfs_cache_entry *ce)
>  {
>         struct timespec64 ts;
>
> -       ts = current_kernel_time64();
> +       ktime_get_coarse_real_ts64(&ts);
>         return timespec64_compare(&ts, &ce->ce_etime) >= 0;
>  }
>
> @@ -338,8 +338,10 @@ static inline struct timespec64 get_expire_time(int ttl)
>                 .tv_sec = ttl,
>                 .tv_nsec = 0,
>         };
> +       struct timespec64 now;
>
> -       return timespec64_add(current_kernel_time64(), ts);
> +       ktime_get_coarse_real_ts64(&now);
> +       return timespec64_add(now, ts);
>  }

In case efficiency is a concern: using ktime_t with
ktime_get_coarse_real() may be much faster if we decide to
abandon the coarse-grained timespec64 accessors in the future.

Also, I wonder if the expiration here has to use CLOCK_REALTIME,
since that is affected by leap second adjustment and
clock_settime().

In other modules, we usually concluded that it should be either
CLOCK_MONOTONIC or CLOCK_BOOTTIME, depending on whether
you want the expiration timer to keep ticking during suspend.

        Arnd