On 6/10/16, 09:12, "Anna Schumaker" <[email protected]> wrote:
>On 06/09/2016 05:10 PM, Deepa Dinamani wrote: >>>> boot_time is represented as a struct timespec. >>>> struct timespec and CURRENT_TIME are not y2038 safe. >>>> Overall, the plan is to use timespec64 for all internal >>>> kernel representation of timestamps. >>>> CURRENT_TIME will also be removed. >>>> Use struct timespec64 to represent boot_time. >>>> And, ktime_get_real_ts64() for the boot_time value. >>>> >>>> boot_time is used to construct the nfs client boot verifier. >>>> This will now wrap in 2106 instead of 2038 on 32-bit systems. >>>> The server only relies on the value being persistent until >>>> reboot so the wrapping should be fine. >>> >>> We really do not give a damn about wraparound here, since the boot time is >>> only ever compared for an exact match, and the odds of two reboots occurring >>> exactly 2^32 * 10^9 nanoseconds apart are cosmically small... >>> If struct timespec is going away, can we just convert this into a ktime_t? >> >> timespec64 is the same as timespec already on 64 bit machines. >> But, yes, we can use ktime_t here. >> >> Did you mean the internal storage value or the wire boo_time used for >> verifier? >> In case you don't want to change the wire value, then we will have a division >> operation, every time the verifier needs to be sent. > >The verifier is mostly used during mounting, so we don't send too many of >them. I don't think we need to worry about adding an extra division operation >here, they're pretty cheap compared to making RPC calls! :) > The only requirement for the verifier is that it be unique, so changing the format is not a problem either. Cheers Trond Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. _______________________________________________ Y2038 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/y2038
