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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.11.1602241223530.3670@nanos>
Date:	Wed, 24 Feb 2016 13:19:07 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arnd Bergmann <arnd@...db.de>
cc:	y2038@...ts.linaro.org, Deepa Dinamani <deepa.kernel@...il.com>,
	linux-fsdevel@...r.kernel.org, david@...morbit.com,
	' Theodore Ts'''o <tytso@....edu>,
	linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals

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.
 
> 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