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
| ||
|
Message-ID: <CAHk-=wjTynK9BdGbi+8eShU77nkPvipFwRxEd1TSBrw2+LiuDg@mail.gmail.com> 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