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-next>] [day] [month] [year] [list]
Message-Id: <20230424151104.175456-1-jlayton@kernel.org>
Date:   Mon, 24 Apr 2023 11:11:01 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dave Chinner <david@...morbit.com>,
        Chuck Lever <chuck.lever@...cle.com>
Cc:     Jan Kara <jack@...e.cz>, Amir Goldstein <amir73il@...il.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-xfs@...r.kernel.org, linux-mm@...ck.org,
        linux-nfs@...r.kernel.org
Subject: [PATCH v2 0/3] fs: multigrain timestamps

A few weeks ago, during one of the discussions around i_version, Dave
Chinner wrote this:

"You've missed the part where I suggested lifting the "nfsd sampled
i_version" state into an inode state flag rather than hiding it in
the i_version field. At that point, we could optimise away the
secondary ctime updates just like you are proposing we do with the
i_version updates.  Further, we could also use that state it to
decide whether we need to use high resolution timestamps when
recording ctime updates - if the nfsd has not sampled the
ctime/i_version, we don't need high res timestamps to be recorded
for ctime...."

While I don't think we can practically optimize away ctime updates
like we do with i_version, I do like the idea of using this scheme to
indicate when we need to use a high-res timestamp.

This patchset is a second attempt at implementing this. The main
difference with this set is that it uses the lowest-order bit of the
tv_nsec field as the flag instead of using an i_state flag. This also
allows us to use atomic ops instead of a spinlock.

With this, the patchset also contains a new opt-in mechanism: You must
set a SB_MULTIGRAIN_TS flag in the superblock, and also raise your
sb->s_time_gran to at least 2.

The first patch adds the necessary infrastructure, and the last two
patches convert tmpfs and xfs to use it. If this looks good, I'll start
embarking on converting other filesystems to this scheme as well.

Comments and suggestions welcome!

Jeff Layton (3):
  fs: add infrastructure for multigrain inode i_m/ctime
  shmem: mark for high-res timestamps on next update after getattr
  xfs: mark the inode for high-res timestamp update in getattr

 fs/inode.c                      | 57 +++++++++++++++++++++++++++---
 fs/stat.c                       | 24 +++++++++++++
 fs/xfs/libxfs/xfs_trans_inode.c |  2 +-
 fs/xfs/xfs_acl.c                |  2 +-
 fs/xfs/xfs_inode.c              |  2 +-
 fs/xfs/xfs_inode_item.c         |  2 +-
 fs/xfs/xfs_iops.c               |  9 +++--
 fs/xfs/xfs_super.c              |  5 ++-
 include/linux/fs.h              | 62 +++++++++++++++++++++++----------
 mm/shmem.c                      | 29 ++++++++-------
 10 files changed, 152 insertions(+), 42 deletions(-)

-- 
2.40.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ