Date: Thu, 28 Sep 2023 17:18:42 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Jeff Layton <jlayton@...nel.org>, "Darrick J. Wong" <djwong@...nel.org>, Arnd Bergmann <arnd@...db.de>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, 
	David Sterba <dsterba@...e.cz>, Amir Goldstein <amir73il@...il.com>, 
	"Eric W. Biederman" <ebiederm@...ssion.com>, Kees Cook <keescook@...omium.org>, 
	Jeremy Kerr <jk@...abs.org>, Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, 
	Christophe Leroy <christophe.leroy@...roup.eu>, Heiko Carstens <hca@...ux.ibm.com>, 
	Vasily Gorbik <gor@...ux.ibm.com>, Alexander Gordeev <agordeev@...ux.ibm.com>, 
	Christian Borntraeger <borntraeger@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arve Hjønnevåg <arve@...roid.com>, 
	Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>, 
	Joel Fernandes <joel@...lfernandes.org>, Carlos Llamas <cmllamas@...gle.com>, 
	Suren Baghdasaryan <surenb@...gle.com>, Mattia Dongili <malattia@...ux.it>, 
	Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>, Jason Gunthorpe <jgg@...pe.ca>, 
	Leon Romanovsky <leon@...nel.org>, Brad Warrum <bwarrum@...ux.ibm.com>, 
	Ritu Agarwal <rituagar@...ux.ibm.com>, Hans de Goede <hdegoede@...hat.com>, 
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	Mark Gross <markgross@...nel.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Eric Van Hensbergen <ericvh@...nel.org>, Latchesar Ionkov <lucho@...kov.net>, 
	Dominique Martinet <asmadeus@...ewreck.org>, Christian Schoenebeck <linux_oss@...debyte.com>, 
	David Sterba <dsterba@...e.com>, David Howells <dhowells@...hat.com>, 
	Marc Dionne <marc.dionne@...istor.com>, Ian Kent <raven@...maw.net>, 
	Luis de Bethencourt <luisbg@...nel.org>, Salah Triki <salah.triki@...il.com>, 
	"Tigran A. Aivazian" <aivazian.tigran@...il.com>, Chris Mason <clm@...com>, 
	Josef Bacik <josef@...icpanda.com>, Xiubo Li <xiubli@...hat.com>, 
	Ilya Dryomov <idryomov@...il.com>, Jan Harkes <jaharkes@...cmu.edu>, coda@...cmu.edu, 
	Joel Becker <jlbec@...lplan.org>, Christoph Hellwig <hch@....de>, Nicolas Pitre <nico@...xnic.net>, 
	"Rafael J . Wysocki" <rafael@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, Gao Xiang <xiang@...nel.org>, 
	Chao Yu <chao@...nel.org>, Yue Hu <huyue2@...jj8bn.sched.sma.tdnsstic1.cn>, 
	Jeffle Xu <jefflexu@...ux.alibaba.com>, Namjae Jeon <linkinjeon@...nel.org>, 
	Sungjong Seo <sj1557.seo@...sung.com>, Jan Kara <jack@...e.com>, 
	Andreas Dilger <adilger.kernel@...ger.ca>, Jaegeuk Kim <jaegeuk@...nel.org>, 
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>, Christoph Hellwig <hch@...radead.org>, 
	Miklos Szeredi <miklos@...redi.hu>, Bob Peterson <rpeterso@...hat.com>, 
	Andreas Gruenbacher <agruenba@...hat.com>, Richard Weinberger <richard@....at>, 
	Anton Ivanov <anton.ivanov@...bridgegreys.com>, Johannes Berg <johannes@...solutions.net>, 
	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>, Mike Kravetz <mike.kravetz@...cle.com>, 
	Muchun Song <muchun.song@...ux.dev>, Jan Kara <jack@...e.cz>, 
	David Woodhouse <dwmw2@...radead.org>, Dave Kleikamp <shaggy@...nel.org>, Tejun Heo <tj@...nel.org>, 
	Trond Myklebust <trond.myklebust@...merspace.com>, Anna Schumaker <anna@...nel.org>, 
	Chuck Lever <chuck.lever@...cle.com>, Neil Brown <neilb@...e.de>, 
	Olga Kornievskaia <kolga@...app.com>, Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>, 
	Ryusuke Konishi <konishi.ryusuke@...il.com>, Anton Altaparmakov <anton@...era.com>, 
	Konstantin Komarov <almaz.alexandrovich@...agon-software.com>, Mark Fasheh <mark@...heh.com>, 
	Joseph Qi <joseph.qi@...ux.alibaba.com>, Bob Copeland <me@...copeland.com>, 
	Mike Marshall <hubcap@...ibond.com>, Martin Brandenburg <martin@...ibond.com>, 
	Luis Chamberlain <mcgrof@...nel.org>, Iurii Zaikin <yzaikin@...gle.com>, Tony Luck <tony.luck@...el.com>, 
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>, Anders Larsen <al@...rsen.net>, Steve French <sfrench@...ba.org>, 
	Paulo Alcantara <pc@...guebit.com>, Ronnie Sahlberg <lsahlber@...hat.com>, 
	Shyam Prasad N <sprasad@...rosoft.com>, Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Phillip Lougher <phillip@...ashfs.org.uk>, Steven Rostedt <rostedt@...dmis.org>, 
	Masami Hiramatsu <mhiramat@...nel.org>, Evgeniy Dushistov <dushistov@...l.ru>, 
	Chandan Babu R <chandan.babu@...cle.com>, Damien Le Moal <dlemoal@...nel.org>, 
	Naohiro Aota <naohiro.aota@....com>, Johannes Thumshirn <jth@...nel.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, Hugh Dickins <hughd@...gle.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, "David S . Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	John Johansen <john.johansen@...onical.com>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, 
	Stephen Smalley <stephen.smalley.work@...il.com>, Eric Paris <eparis@...isplace.org>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org, 
	platform-driver-x86@...r.kernel.org, linux-rdma@...r.kernel.org, 
	linux-serial@...r.kernel.org, linux-usb@...r.kernel.org, v9fs@...ts.linux.dev, 
	linux-afs@...ts.infradead.org, autofs@...r.kernel.org, 
	linux-btrfs@...r.kernel.org, ceph-devel@...r.kernel.org, 
	codalist@...emann.coda.cs.cmu.edu, linux-efi@...r.kernel.org, 
	linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org, 
	linux-f2fs-devel@...ts.sourceforge.net, gfs2@...ts.linux.dev, 
	linux-um@...ts.infradead.org, linux-mtd@...ts.infradead.org, 
	jfs-discussion@...ts.sourceforge.net, linux-nfs@...r.kernel.org, 
	linux-nilfs@...r.kernel.org, linux-ntfs-dev@...ts.sourceforge.net, 
	ntfs3@...ts.linux.dev, ocfs2-devel@...ts.linux.dev, 
	linux-karma-devel@...ts.sourceforge.net, devel@...ts.orangefs.org, 
	linux-unionfs@...r.kernel.org, linux-hardening@...r.kernel.org, 
	reiserfs-devel@...r.kernel.org, linux-cifs@...r.kernel.org, 
	samba-technical@...ts.samba.org, linux-trace-kernel@...r.kernel.org, 
	linux-xfs@...r.kernel.org, bpf@...r.kernel.org, 
	Netdev <netdev@...r.kernel.org>, apparmor@...ts.ubuntu.com, 
	linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers

On Thu, 28 Sept 2023 at 14:28, Theodore Ts'o <tytso@....edu> wrote:
>
> I don't think anyone will complain about breaking the userspace API
> --- especially since if, say, the CIA was using this for their spies'
> drop boxes, they probably wouldn't want to admit it.  :-)

Well, you will find that real apps do kind of of care.

Just to take a very real example, "git" will very much notice time
granularity issues and care - because git will cache the 'stat' times
in the index.

So if you get a different stat time (because the vfs layer has changed
some granularity), git will then have to check the files carefully
again and update the index.

You can simulate this "re-check all files" with something like this:

    $ time git diff

    real 0m0.040s
    user 0m0.035s
    sys 0m0.264s

    $ rm .git/index && git read-tree HEAD

    $ time git diff

    real 0m9.595s
    user 0m7.287s
    sys 0m2.810s

so the difference between just doing a "look, index information
matches current 'stat' information" and "oops, index does not have the
stat data" is "40 milliseconds" vs "10 seconds".

That's a big difference, and you'd see that each time the granularity
changes. But then once the index file has been updated, it's back to
the good case.

So yes, real programs to cache stat information, and it matters for performance.

But I don't think any actual reasonable program will have
*correctness* issues, though - because there are certainly filesystems
out there that don't do nanosecond resolution (and other operations
like copying trees around will obviously also change times).

Anybody doing steganography in the timestamps is already not going to
have a great time, really.

                 Linus

Powered by blists - more mailing lists