linux-kernel - Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time

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]

Date:	Tue, 12 Jan 2016 10:27:07 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	y2038@...ts.linaro.org
Cc:	Dave Chinner <david@...morbit.com>,
	Deepa Dinamani <deepa.kernel@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time

On Tuesday 12 January 2016 19:29:57 Dave Chinner wrote:
> 
> This is what I meant about premature optimisation - you've got a
> wonderfully complex solution to a problem that we don't need to
> solve to support timestamps >y2038. It's also why it goes down the
> wrong path at this point - most of the changes are not necessary if
> all we need to do is a simple timespec -> timespec64 type change and
> the addition timestamp range limiting in the existing truncation
> function...

I originally suggested doing the split representation because I
was worried about the downsides of using timespec64 on 32-bit systems
after looking at actual memory consumption on my test box.

At this moment, I have a total of 145712700 inodes in memory on a machine
with 64GB ram, saving 12 bytes on each amounts to a total of 145MB. I think
it was more than that when I first looked, so it's between 0.2% and 0.3%
of savings in total memory, which is certainly worth discussing about,
given the renewed interest in conserving RAM in general. If we want to
save this memory, then doing it at the same time as the timespec64 conversion
is the right time so we don't need to touch every file twice.

One point that I had not considered though is on the 32-bit systems we
are talking about, not only is RAM much smaller, but also there would be
a smaller fraction of RAM available to store inodes, so there is not as
much to gain.

	Arnd