linux-kernel - 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <538CCFDE.2010107@zytor.com>
Date:	Mon, 02 Jun 2014 12:26:22 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Arnd Bergmann <arnd@...db.de>,
	"Joseph S. Myers" <joseph@...esourcery.com>
CC:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	john.stultz@...aro.org, hch@...radead.org, tglx@...utronix.de,
	geert@...ux-m68k.org, lftan@...era.com,
	linux-fsdevel@...r.kernel.org, ceph-devel@...r.kernel.org,
	cluster-devel@...hat.com, coda@...cmu.edu,
	codalist@...EMANN.coda.cs.cmu.edu,
	fuse-devel@...ts.sourceforge.net, linux-afs@...ts.infradead.org,
	linux-btrfs@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
	linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
	linux-ntfs-dev@...ts.sourceforge.net, linux-scsi@...r.kernel.org,
	logfs@...fs.org, ocfs2-devel@....oracle.com,
	reiserfs-devel@...r.kernel.org, samba-technical@...ts.samba.org,
	xfs@....sgi.com
Subject: Re: [RFC 00/32] making inode time stamps y2038 ready

On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
> On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
>> On Fri, 30 May 2014, Arnd Bergmann wrote:
>>
>>> a) is this the right approach in general? The previous discussion
>>>    pointed this way, but there may be other opinions.
>>
>> The syscall changes seem like the sort of thing I'd expect, although 
>> patches adding new syscalls or otherwise affecting the kernel/userspace 
>> interface (as opposed to those relating to an individual filesystem) 
>> should go to linux-api as well as other relevant lists.
> 
> Ok. Sorry about missing linux-api, I confused it with linux-arch, which
> may not be as relevant here, except for the one question whether we
> actually want to have the new ABI on all 32-bit architectures or only
> as an opt-in for those that expect to stay around for another 24 years.
> 
> Two more questions for you:
> 
> - are you (and others) happy with adding this type of stat syscall
>   (fstatat64/fstat64) as opposed to the more generic xstat that has
>   been discussed in the past and that never made it through the bike-
>   shedding discussion?
> 
> - once we have enough buy-in from reviewers to merge this initial
>   series, should we proceed to define rest of the syscall ABI
>   (minus driver ioctls) so glibc and kernel can do the conversion
>   on top of that, or should we better try to do things one syscall
>   family at a time and actually get the kernel to handle them
>   correctly internally?
> 

The bit that is really going to hurt is every single ioctl that uses a
timespec.

Honestly, though, I really don't understand the point with "struct
inode_time".  It seems like the zeroeth-order thing is to change the
kernel internal version of struct timespec to have a 64-bit time... it
isn't just about inodes.  We then should be explicit about the external
uses of time, and use accessors.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/