Re: [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()

[Deepa Dinamani]

On Fri, Jun 10, 2016 at 3:21 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Wednesday, June 8, 2016 10:04:45 PM CEST Deepa Dinamani wrote:
>> CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will
>> be transitioned to use 64 bit time along with vfs in a
>> separate patch.
>> There is no plan to transistion CURRENT_TIME_SEC to use
>> y2038 safe time interfaces.
>>
>> current_fs_time() will also be extended to use superblock
>> range checking parameters when range checking is introduced.
>>
>> This works because alloc_super() fills in the the s_time_gran
>> in super block to NSEC_PER_SEC.
>>
>> Also note that filesystem specific times like the birthtime,
>> creation time that were using same interfaces to obtain time
>> retain same logistics.
>>
>> Signed-off-by: Deepa Dinamani <deepa.kernel@xxxxxxxxx>
>
> one question:
>
> In an earlier version, you had a small optimization to
> use ktime_get_real_seconds() instead of current_kernel_time()
> when the granularity is seconds.
>
> Do you still plan to send that one, or did you decide we don't
> need it?

I was actually planning to use get_seconds() instead of current_kernel_time().
And, transition both along with vfs to y2038 safe apis.
Difference between ktime_get_real_seconds() and current_kernel_time64()
is not much because they both require sequence counter.

It didn't make sense to me to optimize current_fs_time() for seconds
only, and not optimize for 1ns granularity also.
I plan to make changes to the function depending on how we end up
using timespec_trunc()
after the addition of range checking.

Thanks for the guidance on inclusion of reviewers. I'll follow this
approach when I post v2 of the series.

-Deepa