From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AB8CFE743D6 for ; Fri, 29 Sep 2023 00:40:52 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=WaP79h5b; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RxWjb2h90z3fPm for ; Fri, 29 Sep 2023 10:40:51 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=WaP79h5b; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=mit.edu (client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver=lists.ozlabs.org) X-Greylist: delayed 740 seconds by postgrey-1.37 at boromir; Fri, 29 Sep 2023 07:39:44 AEST Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RxRhc5MRLz3cCS for ; Fri, 29 Sep 2023 07:39:42 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-111-87.bstnma.fios.verizon.net [173.48.111.87]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 38SLQv6B021535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Sep 2023 17:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1695936431; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=WaP79h5bQ62LFZ7vHHOCmGWKrdVEw7kTPaoOfwjqG7743/KpOeTQfqQpPAFra25uw qHhUQptGls8wmshhyjdnO9G7FinJGRSu/H+Pr36/HOeVsY2L1QKwp6wJYXWDQj3sU6 spxP8X5T3MP/kvZK7FBaCvSP9XyEeM6QQ1hm7OJdJzn5aY8Xu6Fua+baunPXgUoy7L KhVrZIKyvYcsT0NIC33rKKlIWvn/ApA3rOkeZe9sao19Z+JDKma1IeqPjZOBPScT5p +jnf6c81JzZ84Oc7GpEzLi5aGjfgb8lOPxXH2Up3ynLvwNxgs1A65KPgjW+ME/+Top l7dosLTQv306w== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 06AD715C0266; Thu, 28 Sep 2023 17:26:57 -0400 (EDT) Date: Thu, 28 Sep 2023 17:26:56 -0400 From: "Theodore Ts'o" To: Jeff Layton Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers Message-ID: <20230928212656.GC189345@mit.edu> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> X-Mailman-Approved-At: Fri, 29 Sep 2023 10:31:49 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Konstantin Komarov , "Rafael J . Wysocki" , "Darrick J. Wong" , Anders Larsen , Carlos Llamas , Andrii Nakryiko , Mattia Dongili , Hugh Dickins , Yonghong Song , Alexander Gordeev , Christoph Hellwig , Mike Marshall , Paulo Alcantara , linux-xfs@vger.kernel.org, James Morris , Christoph Hellwig , Christian Borntraeger , devel@lists.orangefs.org, Shyam Prasad N , linux-um@lists.infradead.org, Nicholas Piggin , Alexander Viro , Eric Van Hensbergen , Suren Baghdasaryan , Trond Myklebust , Anton Altaparmakov , Christian Brauner , Greg Kroah-Hartman , Stephen Smalley , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Ronnie Sahlberg , Sergey Senozhatsky , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Chuck Lever , Sven Schnelle , Jiri Olsa , Jan Kara , Tejun Heo , Andrew Morton , linux-trace-kernel@vger.kernel.org, Linus Torvalds , Dave Kleikamp , linux-mm@kvack.org, Joel Fernandes , Eric Dumazet , Stanislav Fomichev , codalist@telemann.coda.cs.cmu.edu, linux-s390@vger.kernel.org, linux-nilfs@vger.kernel.org, Paul Moore , Leon Romanovsky , John Fastabend , Luis Chamberlain , Iurii Zaikin , Namjae Jeon , Masami Hiramatsu , Todd Kjos , Vasily Gorbik , selinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org, Miklos Szeredi , John Johansen , Jaegeuk Kim , Martijn Coenen , OGAWA Hirofumi , Hao Luo , Tony Luck , Nicolas Pitre , linux-ntfs-dev@lists.sourceforge.net, Muchun Song , linux-f2fs-devel@lists.sourceforge.net, "Guilherme G. Piccoli" , gfs2@lists.linux.dev, "Eric W. Biederman" , Anna Schumaker , Brad Warrum , Mike Kravetz , linux-efi@vger. kernel.org, Martin Brandenburg , ocfs2-devel@lists.linux.dev, Alexei Starovoitov , Yue Hu , Chris Mason , linux-mtd@lists.infradead.org, linux-hardening@vger.kernel.org, Marc Dionne , Jiri Slaby , linux-afs@lists.infradead.org, Ian Kent , Naohiro Aota , Daniel Borkmann , Dennis Dalessandro , linux-rdma@vger.kernel.org, coda@cs.cmu.edu, Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Ilya Dryomov , Paolo Abeni , "Serge E. Hallyn" , Christian Schoenebeck , Kees Cook , Arnd Bergmann , autofs@vger.kernel.org, Steven Rostedt , Mark Gross , Damien Le Moal , Eric Paris , ceph-devel@vger.kernel.org, Gao Xiang , Jan Harkes , linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org, Olga Kornievskaia , Song Liu , samba-technical@lists.samba.org, Steve French , Jeremy Kerr , Netdev , Bob Peterson , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, ntfs3@lists.linux.dev, linux-erofs@lists.ozlabs.org, "David S . Miller" , Chandan Babu R , jfs-discussion@lists.sourceforge.net, Jan Kara , Neil Brown , Dominique Martinet , Amir Goldstein , Bob Copeland , KP Singh , linux-unionfs@vger.kernel.org, David Howells , Joseph Qi , Andreas Dilger , M ikulas Patocka , Ard Biesheuvel , Anton Ivanov , Andreas Gruenbacher , Richard Weinberger , Mark Fasheh , Dai Ngo , Jason Gunthorpe , linux-serial@vger.kernel.org, Jakub Kicinski , Salah Triki , platform-driver-x86@vger.kernel.org, Evgeniy Dushistov , linux-cifs@vger.kernel.org, Heiko Carstens , Chao Yu , apparmor@lists.ubuntu.com, Josef Bacik , Tom Talpey , Hans de Goede , "Tigran A. Aivazian" , David Sterba , Xiubo Li , Ryusuke Konishi , Johannes Thumshirn , Ritu Agarwal , Luis de Bethencourt , Martin KaFai Lau , v9fs@lists.linux.dev, David Sterba , linux-security-module@vger.kernel.org, Jeffle Xu , Phillip Lougher , Johannes Berg , Sungjong Seo , David Woodhouse , linux-karma-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, Joel Becker Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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