Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1341938 > unrolled thread

Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals Julia Lawall <julia.lawall@lip6.fr> - 2016-02-24 13:30 +0100

#1341938 — Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals

On Wed, 24 Feb 2016, Thomas Gleixner wrote:

> On Fri, 12 Feb 2016, Arnd Bergmann wrote:
> > Regarding the three versions, I think all of them are doable
> > doable, and they all have their upsides and downsides but no
> > showstoppers.
> >
> > Let me summarize what I see in the patches:
> >
> > 2a is the smallest set of changes in number of lines, as you indicated
> >    in the previous discussion (I was skeptical here initially, but
> >    you were right). The main downside is that each patch has to
> >    carefully consider what happens at the point when the type gets
> >    flipped, so that printk format strings are correct and assignments
> >    to local variables don't truncate the range. It also requires
> >    changing the types again after the VFS change, but that is
> >    something we can automate using coccinelle.
>
> Yes, you can do that final change with coccinelle, but all in all this has the
> highest risk.

Recent versions of Coccinelle can help a bit with format string changes.
See demos/format.cocci.

julia

> > 2b has the main advantage of not changing behavior with the flip, so
> >    we can convert all file systems to use vfs_time relatively easily
> >    and then later make them actually use 64-bit timestamps with
> >    a patch that each file system developer can do for themselves.
>
> And that's a very clear advantage of this approch. The change is purely
> mechanical and can be largely done with coccinelle.
>
> >    One downside is that it leads to rather ugly code as discussed
> >    before, examples are in "[RFC v2b 5/5] fs: xfs: change inode
> >    times to use vfs_time data type" and "[RFC v2b 3/5] fs: btrfs:
> >    Use vfs_time accessors".
>
> -       now = current_fs_time(inode->i_sb);
> -       if (!timespec_equal(&inode->i_mtime, &now))
> -               inode->i_mtime = now;
> +       now = vfs_time_to_timespec(current_fs_time(inode->i_sb));
> +       ts = vfs_time_to_timespec(inode->i_mtime);
> +       if (!timespec_equal(&ts, &now))
> +               inode->i_mtime = timespec_to_vfs_time(now);
> +
> +       ts = vfs_time_to_timespec(inode->i_mtime);
> +       if (!timespec_equal(&ts, &now))
> +               inode->i_ctime = timespec_to_vfs_time(now);
>
> You can either provide a helper function which does that m/c_time update at
> the VFS level where you can hide the mess or just accept that this transition
> will introduce some odd constructs like the above.
>
> > 2c gets us the furthest along the way for the conversion, close
> >    to where we want to end up in the long run, so we could do that
> >    to file systems one by one. The behavior change is immediate,
> >    so there are fewer possible surprises than with 2a, but it
> >    also means the most upfront work.
>
> I would'nt worry about the upfront work to much, if it is the cleanest way to
> do the conversion. Though, I'm not seing how that really makes the whole thing
> simpler.
>
> So far we had good results with changing core code first and then fix up the
> users one by one and at the end remove any intermediary helpers which we
> introduced along the way. So I'd chose 2b as it's a very clear transition
> mechanism with pretty low risk.
>
> Thanks,
>
> 	tglx
>
>
> _______________________________________________
> Y2038 mailing list
> Y2038@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/y2038
>

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web