Re: [Y2038] [PATCH 18/21] fs: nfs: Make nfs boot time y2038 safe

[Trond Myklebust]

On 6/10/16, 09:12, "Anna Schumaker"  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
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 18/21] fs: nfs: Make nfs boot time y2038 safe

[Trond Myklebust]

On 6/9/16, 01:05, "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?

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
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 8/8] net: sunrpc: Replace CURRENT_TIME by current_fs_time()

[Trond Myklebust]

On Mon, Feb 22, 2016 at 10:17 AM, Deepa Dinamani <deepa.ker...@gmail.com> wrote:
>
> CURRENT_TIME macro is not appropriate for filesystems as it
> doesn't use the right granularity for filesystem timestamps.
> Use current_fs_time() instead.
>
> Signed-off-by: Deepa Dinamani <deepa.ker...@gmail.com>
> Cc: "J. Bruce Fields" <bfie...@fieldses.org>
> Cc: Jeff Layton <jlay...@poochiereds.net>
> Cc: Trond Myklebust <trond.mykleb...@primarydata.com>
> Cc: Anna Schumaker <anna.schuma...@netapp.com>
> Cc: "David S. Miller" <da...@davemloft.net>
> Cc: linux-...@vger.kernel.org
> Cc: net...@vger.kernel.org
> ---
>  net/sunrpc/rpc_pipe.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
> index 31789ef..bab3187 100644
> --- a/net/sunrpc/rpc_pipe.c
> +++ b/net/sunrpc/rpc_pipe.c
> @@ -477,7 +477,9 @@ rpc_get_inode(struct super_block *sb, umode_t mode)
> return NULL;
> inode->i_ino = get_next_ino();
> inode->i_mode = mode;
> -   inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
> +   inode->i_atime = current_fs_time(sb);
> +   inode->i_mtime = inode->i_atime;
> +   inode->i_ctime = inode->i_atime;
> switch (mode & S_IFMT) {
> case S_IFDIR:
> inode->i_fop = _dir_operations;

Why would we care? This is a pseudo-fs. There is no expectation w.r.t.
timestamp accuracy or resolution.

Cheers,
  Trond
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038