mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
	y2038@lists.linaro.org, Eric Ren <zren@suse.com>,
	linux-kernel@vger.kernel.org,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] [PATCH] ocfs2: dlmglue: clean up timestamp handling
Date: Tue, 19 Jun 2018 12:14:07 -0500	[thread overview]
Message-ID: <20180619171407.yoncg72ed2vncf62@merlin> (raw)
In-Reply-To: <20180619155826.4106487-1-arnd@arndb.de>



On 06-19 17:58, Arnd Bergmann wrote:
> The handling of timestamps outside of the 1970..2038 range in the dlm
> glue is rather inconsistent: on 32-bit architectures, this has always
> wrapped around to negative timestamps in the 1902..1969 range, while on
> 64-bit kernels all timestamps are interpreted as positive 34 bit numbers
> in the 1970..2514 year range.
> 
> Now that the VFS code handles 64-bit timestamps on all architectures,
> we can make the behavior more consistent here, and return the same result
> that we had on 64-bit already, making the file system y2038 safe in the
> process. Outside of dlmglue, it already uses 64-bit on-disk timestamps
> anway, so that part is fine.
> 
> For consistency, I'm changing ocfs2_pack_timespec() to clamp
> anything outside of the supported range to the minimum and maximum
> values. This avoids a possible ambiguity of values before 1970
> in particular, which used to be interpreted as times at the end of the
> 2514 range previously.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Will all values written to LVB be the same with or without the patch?
I am considering the situation where in a cluster some machines have this
patch and some don't. Depending on that, this may require a version
change.

> ---
>  fs/ocfs2/dlmglue.c | 26 +++++++++-----------------
>  1 file changed, 9 insertions(+), 17 deletions(-)
> 
> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
> index 0ff424c6d17c..50610a9ed9f4 100644
> --- a/fs/ocfs2/dlmglue.c
> +++ b/fs/ocfs2/dlmglue.c
> @@ -2121,10 +2121,10 @@ static void ocfs2_downconvert_on_unlock(struct ocfs2_super *osb,
>  
>  /* LVB only has room for 64 bits of time here so we pack it for
>   * now. */
> -static u64 ocfs2_pack_timespec(struct timespec *spec)
> +static u64 ocfs2_pack_timespec(struct timespec64 *spec)
>  {
>  	u64 res;
> -	u64 sec = spec->tv_sec;
> +	u64 sec = clamp_t(time64_t, spec->tv_sec, 0, 0x3ffffffffull);
>  	u32 nsec = spec->tv_nsec;
>  
>  	res = (sec << OCFS2_SEC_SHIFT) | (nsec & OCFS2_NSEC_MASK);
> @@ -2140,7 +2140,6 @@ static void __ocfs2_stuff_meta_lvb(struct inode *inode)
>  	struct ocfs2_inode_info *oi = OCFS2_I(inode);
>  	struct ocfs2_lock_res *lockres = &oi->ip_inode_lockres;
>  	struct ocfs2_meta_lvb *lvb;
> -	struct timespec ts;
>  
>  	lvb = ocfs2_dlm_lvb(&lockres->l_lksb);
>  
> @@ -2161,15 +2160,12 @@ static void __ocfs2_stuff_meta_lvb(struct inode *inode)
>  	lvb->lvb_igid      = cpu_to_be32(i_gid_read(inode));
>  	lvb->lvb_imode     = cpu_to_be16(inode->i_mode);
>  	lvb->lvb_inlink    = cpu_to_be16(inode->i_nlink);
> -	ts = timespec64_to_timespec(inode->i_atime);
>  	lvb->lvb_iatime_packed  =
> -		cpu_to_be64(ocfs2_pack_timespec(&ts));
> -	ts = timespec64_to_timespec(inode->i_ctime);
> +		cpu_to_be64(ocfs2_pack_timespec(&inode->i_atime));
>  	lvb->lvb_ictime_packed =
> -		cpu_to_be64(ocfs2_pack_timespec(&ts));
> -	ts = timespec64_to_timespec(inode->i_mtime);
> +		cpu_to_be64(ocfs2_pack_timespec(&inode->i_ctime));
>  	lvb->lvb_imtime_packed =
> -		cpu_to_be64(ocfs2_pack_timespec(&ts));
> +		cpu_to_be64(ocfs2_pack_timespec(&inode->i_mtime));
>  	lvb->lvb_iattr    = cpu_to_be32(oi->ip_attr);
>  	lvb->lvb_idynfeatures = cpu_to_be16(oi->ip_dyn_features);
>  	lvb->lvb_igeneration = cpu_to_be32(inode->i_generation);
> @@ -2178,7 +2174,7 @@ static void __ocfs2_stuff_meta_lvb(struct inode *inode)
>  	mlog_meta_lvb(0, lockres);
>  }
>  
> -static void ocfs2_unpack_timespec(struct timespec *spec,
> +static void ocfs2_unpack_timespec(struct timespec64 *spec,
>  				  u64 packed_time)
>  {
>  	spec->tv_sec = packed_time >> OCFS2_SEC_SHIFT;
> @@ -2187,7 +2183,6 @@ static void ocfs2_unpack_timespec(struct timespec *spec,
>  
>  static void ocfs2_refresh_inode_from_lvb(struct inode *inode)
>  {
> -	struct timespec ts;
>  	struct ocfs2_inode_info *oi = OCFS2_I(inode);
>  	struct ocfs2_lock_res *lockres = &oi->ip_inode_lockres;
>  	struct ocfs2_meta_lvb *lvb;
> @@ -2215,15 +2210,12 @@ static void ocfs2_refresh_inode_from_lvb(struct inode *inode)
>  	i_gid_write(inode, be32_to_cpu(lvb->lvb_igid));
>  	inode->i_mode    = be16_to_cpu(lvb->lvb_imode);
>  	set_nlink(inode, be16_to_cpu(lvb->lvb_inlink));
> -	ocfs2_unpack_timespec(&ts,
> +	ocfs2_unpack_timespec(&inode->i_atime,
>  			      be64_to_cpu(lvb->lvb_iatime_packed));
> -	inode->i_atime = timespec_to_timespec64(ts);
> -	ocfs2_unpack_timespec(&ts,
> +	ocfs2_unpack_timespec(&inode->i_mtime,
>  			      be64_to_cpu(lvb->lvb_imtime_packed));
> -	inode->i_mtime = timespec_to_timespec64(ts);
> -	ocfs2_unpack_timespec(&ts,
> +	ocfs2_unpack_timespec(&inode->i_ctime,
>  			      be64_to_cpu(lvb->lvb_ictime_packed));
> -	inode->i_ctime = timespec_to_timespec64(ts);
>  	spin_unlock(&oi->ip_lock);
>  }
>  
> -- 
> 2.9.0
> 
> 
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel@oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel

-- 
Goldwyn

  reply	other threads:[~2018-06-19 17:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19 15:58 Arnd Bergmann
2018-06-19 17:14 ` Goldwyn Rodrigues [this message]
2018-06-19 19:11   ` [Ocfs2-devel] " Arnd Bergmann
2018-06-19 21:52     ` Goldwyn Rodrigues
2018-06-20  7:39       ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180619171407.yoncg72ed2vncf62@merlin \
    --to=rgoldwyn@suse.de \
    --cc=arnd@arndb.de \
    --cc=deepa.kernel@gmail.com \
    --cc=jlbec@evilplan.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@fasheh.com \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=y2038@lists.linaro.org \
    --cc=zren@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®