linux-kernel - Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

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: <20160512091141.GA22420@infradead.org>
Date:	Thu, 12 May 2016 02:11:41 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	David Howells <dhowells@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-afs@...ts.infradead.org,
	linux-nfs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info
 available

On Tue, May 10, 2016 at 09:25:55AM +0100, David Howells wrote:
> Because it's not necessarily a perfectly working version of it.  See the Y2037
> problem for example.
> 
> I was assuming that C libraries might want to update the struct stat and the
> stat call() to provide fields that aren't currently there in Linux but are in
> other OS's.  We could even dispense with older stat syscalls on new arches.

Please stop this whole let's get rid of old syscalls on new
architectures stuff.  This just means we have to do the translation
multiple, and the one in userspace is more costly as we it needs to be
in every copy of the library.  And times where we had a single libc
instance (nevermind implementation) are long over if we ever actually
had them.

> However, if we're going to discard this possibility, we can make these
> features available only to direct calls of extended stat.

And even if we want to to do a stat emulation despite that above
argument let's add the flag once a major libc implementation actually
wants to use it and taylor it towards the use case.  Don't just add
it just because, and even more importantly don't make it the default.