From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: linux-next: build failure after merge of the y2038 tree Date: Mon, 17 Dec 2018 13:49:33 +0100 Message-ID: References: <20181217201146.170ca9b4@canb.auug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Steve French , linux-cifs@vger.kernel.org, Linux-Next Mailing List , Linux Kernel Mailing List , palcantara@suse.de, Aurelien Aptel , stfrench@microsoft.com To: Stephen Rothwell Return-path: In-Reply-To: <20181217201146.170ca9b4@canb.auug.org.au> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-cifs.vger.kernel.org On Mon, Dec 17, 2018 at 10:11 AM Stephen Rothwell wrote: > I have applied the following merge fix patch (better versions welcome): > > From: Stephen Rothwell > Date: Mon, 17 Dec 2018 20:03:28 +1100 > Subject: [PATCH] cifs: update for current_kernel_time64() removal > > Signed-off-by: Stephen Rothwell > --- 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 > 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