linux-ext4 - Re: [RFC 00/32] making inode time stamps y2038 ready

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] [day] [month] [year] [list]

Message-ID: <10173877.4plnjUiyX8@wuerfel>
Date:	Tue, 10 Jun 2014 11:54:14 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Dave Chinner <david@...morbit.com>, hch@...radead.org,
	linux-mtd@...ts.infradead.org, logfs@...fs.org,
	linux-afs@...ts.infradead.org,
	"Joseph S. Myers" <joseph@...esourcery.com>,
	linux-arch@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-scsi@...r.kernel.org, ceph-devel@...r.kernel.org,
	cluster-devel@...hat.com, coda@...cmu.edu, geert@...ux-m68k.org,
	linux-ext4@...r.kernel.org, codalist@...emann.coda.cs.cmu.edu,
	fuse-devel@...ts.sourceforge.net, reiserfs-devel@...r.kernel.org,
	xfs@....sgi.com, john.stultz@...aro.org, tglx@...utronix.de,
	linux-nfs@...r.kernel.org, linux-ntfs-dev@...ts.sourceforge.net,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net, ocfs2-devel@....oracle.com,
	linux-fsdevel@...r.kernel.org, lftan@...era.com,
	linux-btrfs@...r.kernel.org
Subject: Re: [RFC 00/32] making inode time stamps y2038 ready

On Wednesday 04 June 2014 17:10:24 H. Peter Anvin wrote:
> On 06/04/2014 12:24 PM, Arnd Bergmann wrote:
> > 
> > For other timekeeping stuff in the kernel, I agree that using some
> > 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
> > ...) has advantages, that's exactly the point I was making earlier
> > against simply extending the internal time_t/timespec to 64-bit
> > seconds for everything.
> > 
> 
> How much of a performance issue is it to make time_t 64 bits, and for
> the bits there are, how hard are they to fix?

Probably very little overhead for most uses, it's more the regression
potential in the less common parts of the kernel I'm worried about.

There is a significant but not overwhelming number of uses of the
main problematic types in the kernel:

arnd@...rfel:~/arm-soc$ git grep -wl time_t | wc
    188     188    5566
arnd@...rfel:~/arm-soc$ git grep -wl timeval | wc
    320     320   10353
arnd@...rfel:~/arm-soc$ git grep -wl timespec | wc
    406     406   10886

I believe we have to audit all of them anyway if we want to change
the kernel to less problematic types and introduce new user
interfaces.

IMHO this work is helped if we change the uses to a new type
as we find the problems. This lets us do the work one subsystem
at a time and avoid accidental ABI changes. I don't care much what
type that will be, and having a 96-bit type will certainly work
well in a lot of cases, but I don't see a strong reason to use
that over other types, especially when they can be more efficient.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html