Date: Thu, 28 Sep 2023 17:26:56 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Jeff Layton <jlayton@...nel.org>
Cc: "Darrick J. Wong" <djwong@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.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, Sep 28, 2023 at 01:40:55PM -0400, Jeff Layton wrote:
> 
> Correct. We'd lose some fidelity in currently stored timestamps, but as
> Linus and Ted pointed out, anything below ~100ns granularity is
> effectively just noise, as that's the floor overhead for calling into
> the kernel. It's hard to argue that any application needs that sort of
> timestamp resolution, at least with contemporary hardware. 
> 
> Doing that would mean that tests that store specific values in the
> atime/mtime and expect to be able to fetch exactly that value back would
> break though, so we'd have to be OK with that if we want to try it. The
> good news is that it's relatively easy to experiment with new ways to
> store timestamps with these wrappers in place.

The reason why we store 1ns granularity in ext4's on-disk format (and
accept that we only support times only a couple of centuries into the
future, as opposed shooting for an on-disk format good for several
millennia :-), was in case there was userspace that might try to store
a very fine-grained timestamp and want to be able to get it back
bit-for-bit identical.

For example, what if someone was trying to implement some kind of
steganographic scheme where they going store a secret message (or more
likely, a 256-bit AES key) in the nanosecond fields of the file's
{c,m,a,cr}time timestamps, "hiding in plain sight".  Not that I think
that we have to support something like that, since the field is for
*timestamps* not cryptographic bits, so if we break someone who is
doing that, do we care?

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.  :-)

       	    	     	      	      	    - Ted

Powered by blists - more mailing lists