[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1bXLXmjGf1Yx6JXbc4-Z8DjkZPZkfvesvjFXq3jw11NQ@mail.gmail.com>
Date: Thu, 21 Jun 2018 16:53:20 +0200
From: Arnd Bergmann <arnd@...db.de>
To: "Yan, Zheng" <ukernel@...il.com>
Cc: Zheng Yan <zyan@...hat.com>, Sage Weil <sage@...hat.com>,
Ilya Dryomov <idryomov@...il.com>,
y2038 Mailman List <y2038@...ts.linaro.org>,
ceph-devel <ceph-devel@...r.kernel.org>,
Jeff Layton <jlayton@...hat.com>,
Chengguang Xu <cgxu519@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5] ceph: stop using current_kernel_time()
On Thu, Jun 21, 2018 at 2:29 PM, Yan, Zheng <ukernel@...il.com> wrote:
> On Wed, Jun 20, 2018 at 11:52 PM Arnd Bergmann <arnd@...db.de> wrote:
>>
>> ceph_mdsc_create_request() is one of the last callers of the
>> deprecated current_kernel_time() as well as timespec_trunc().
>>
>> This changes it to use the timespec64 based interfaces instead,
>> though we still need to convert the result until we are ready to
>> change over req->r_stamp.
>>
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>> ---
>> fs/ceph/mds_client.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
>> index dc8bc664a871..69c839316a7a 100644
>> --- a/fs/ceph/mds_client.c
>> +++ b/fs/ceph/mds_client.c
>> @@ -1779,6 +1779,7 @@ struct ceph_mds_request *
>> ceph_mdsc_create_request(struct ceph_mds_client *mdsc, int op, int mode)
>> {
>> struct ceph_mds_request *req = kzalloc(sizeof(*req), GFP_NOFS);
>> + struct timespec64 ts;
>>
>> if (!req)
>> return ERR_PTR(-ENOMEM);
>> @@ -1797,7 +1798,9 @@ ceph_mdsc_create_request(struct ceph_mds_client *mdsc, int op, int mode)
>> init_completion(&req->r_safe_completion);
>> INIT_LIST_HEAD(&req->r_unsafe_item);
>>
>> - req->r_stamp = timespec_trunc(current_kernel_time(), mdsc->fsc->sb->s_time_gran);
>> + ktime_get_coarse_real_ts64(&ts);
>> + req->r_stamp = timespec64_to_timespec(timespec64_trunc(ts,
>> + mdsc->fsc->sb->s_time_gran));
>>
>
> does current_time() internally uses ktime_get_coarse_real_ts64()? If
> not, granularity difference may cause problem. see commit
> 56199016e8672feb7b903eda003a863d5bf2b8c4 for more information
Yes, current_time() is based on current_kernel_time64(), which calls
ktime_get_coarse_real_ts64(). I'm in the process of removing both
current_kernel_time() and current_kernel_time64() in favor
of ktime_get_coarse_real_ts64() for consistency. The resolution
is unchanged here.
Arnd
Powered by blists - more mailing lists