* [PATCH 1/3] ext4: make dirdata work with metadata_csum
From: Artem Blagodarenko @ 2026-04-17 21:37 UTC (permalink / raw)
To: linux-ext4
Cc: adilger.kernel, Artem Blagodarenko, Pravin Shelar, Andreas Dilger
In-Reply-To: <20260417213723.74204-1-artem.blagodarenko@gmail.com>
Split monolithic definition of dx_root struct to separate dx_root_info
from fake struct ext4_dir_entry2 for improved code readability.
This allows "." and ".." dirents to have different sizes if necessary,
since we can't assume the rec_len 12 if dx_root dirents have dirdata.
Adds dx_get_dx_info() accessor instead of complex typecast at callers.
Does not change any functionality.
Signed-off-by: Pravin Shelar <pravin.shelar@sun.com>
Signed-off-by: Artem Blagodarenko <artem.blagodarenko@gmail.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
---
fs/ext4/namei.c | 177 ++++++++++++++++++++++++------------------------
1 file changed, 89 insertions(+), 88 deletions(-)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index c4b5e252af0e..ab2b4bb4a93d 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -244,22 +244,13 @@ struct dx_entry
* hash version mod 4 should never be 0. Sincerely, the paranoia department.
*/
-struct dx_root
+struct dx_root_info
{
- struct fake_dirent dot;
- char dot_name[4];
- struct fake_dirent dotdot;
- char dotdot_name[4];
- struct dx_root_info
- {
- __le32 reserved_zero;
- u8 hash_version;
- u8 info_length; /* 8 */
- u8 indirect_levels;
- u8 unused_flags;
- }
- info;
- struct dx_entry entries[];
+ __le32 reserved_zero;
+ u8 hash_version;
+ u8 info_length; /* 8 */
+ u8 indirect_levels;
+ u8 unused_flags;
};
struct dx_node
@@ -334,11 +325,7 @@ static struct ext4_dir_entry_tail *get_dirent_tail(struct inode *inode,
t = EXT4_DIRENT_TAIL(bh->b_data, EXT4_BLOCK_SIZE(inode->i_sb));
#endif
- if (t->det_reserved_zero1 ||
- (ext4_rec_len_from_disk(t->det_rec_len, blocksize) !=
- sizeof(struct ext4_dir_entry_tail)) ||
- t->det_reserved_zero2 ||
- t->det_reserved_ft != EXT4_FT_DIR_CSUM)
+ if (!ext4_dir_entry_is_tail((struct ext4_dir_entry_2 *)t))
return NULL;
return t;
@@ -413,7 +400,7 @@ static struct dx_countlimit *get_dx_countlimit(struct inode *inode,
struct ext4_dir_entry *dirent,
int *offset)
{
- struct ext4_dir_entry *dp;
+ struct ext4_dir_entry_2 *de;
struct dx_root_info *root;
int count_offset;
int blocksize = EXT4_BLOCK_SIZE(inode->i_sb);
@@ -422,10 +409,10 @@ static struct dx_countlimit *get_dx_countlimit(struct inode *inode,
if (rlen == blocksize)
count_offset = 8;
else if (rlen == 12) {
- dp = (struct ext4_dir_entry *)(((void *)dirent) + 12);
- if (ext4_rec_len_from_disk(dp->rec_len, blocksize) != blocksize - 12)
+ de = (struct ext4_dir_entry_2 *)(((void *)dirent) + 12);
+ if (ext4_rec_len_from_disk(de->rec_len, blocksize) != blocksize - 12)
return NULL;
- root = (struct dx_root_info *)(((void *)dp + 12));
+ root = (struct dx_root_info *)(((void *)de + 12));
if (root->reserved_zero ||
root->info_length != sizeof(struct dx_root_info))
return NULL;
@@ -533,6 +520,16 @@ ext4_next_entry(struct ext4_dir_entry_2 *p, unsigned long blocksize)
* Future: use high four bits of block for coalesce-on-delete flags
* Mask them off for now.
*/
+static struct dx_root_info *dx_get_dx_info(void *de_buf)
+{
+ /* get dotdot first */
+ de_buf = de_buf + ext4_dirent_rec_len(1, NULL);
+
+ /* dx root info is after dotdot entry */
+ de_buf = de_buf + ext4_dirent_rec_len(2, NULL);
+
+ return (struct dx_root_info *)de_buf;
+}
static inline ext4_lblk_t dx_get_block(struct dx_entry *entry)
{
@@ -574,11 +571,16 @@ static inline void dx_set_limit(struct dx_entry *entries, unsigned value)
((struct dx_countlimit *) entries)->limit = cpu_to_le16(value);
}
-static inline unsigned dx_root_limit(struct inode *dir, unsigned infosize)
+static inline unsigned dx_root_limit(struct inode *dir,
+ struct ext4_dir_entry_2 *dot_de, unsigned infosize)
{
- unsigned int entry_space = dir->i_sb->s_blocksize -
- ext4_dir_rec_len(1, NULL) -
- ext4_dir_rec_len(2, NULL) - infosize;
+ struct ext4_dir_entry_2 *dotdot_de;
+ unsigned entry_space;
+
+ dotdot_de = ext4_next_entry(dot_de, dir->i_sb->s_blocksize);
+ entry_space = dir->i_sb->s_blocksize -
+ ext4_dir_entry_len(dot_de, NULL) -
+ ext4_dir_entry_len(dotdot_de, NULL) - infosize;
if (ext4_has_feature_metadata_csum(dir->i_sb))
entry_space -= sizeof(struct dx_tail);
@@ -780,7 +782,7 @@ dx_probe(struct ext4_filename *fname, struct inode *dir,
{
unsigned count, indirect, level, i;
struct dx_entry *at, *entries, *p, *q, *m;
- struct dx_root *root;
+ struct dx_root_info *info;
struct dx_frame *frame = frame_in;
struct dx_frame *ret_err = ERR_PTR(ERR_BAD_DX_DIR);
u32 hash;
@@ -792,23 +794,24 @@ dx_probe(struct ext4_filename *fname, struct inode *dir,
if (IS_ERR(frame->bh))
return (struct dx_frame *) frame->bh;
- root = (struct dx_root *) frame->bh->b_data;
- if (root->info.hash_version != DX_HASH_TEA &&
- root->info.hash_version != DX_HASH_HALF_MD4 &&
- root->info.hash_version != DX_HASH_LEGACY &&
- root->info.hash_version != DX_HASH_SIPHASH) {
- ext4_warning_inode(dir, "Unrecognised inode hash code %u",
- root->info.hash_version);
+ info = dx_get_dx_info((struct ext4_dir_entry_2 *)frame->bh->b_data);
+ if (info->hash_version != DX_HASH_TEA &&
+ info->hash_version != DX_HASH_HALF_MD4 &&
+ info->hash_version != DX_HASH_LEGACY &&
+ info->hash_version != DX_HASH_SIPHASH) {
+ ext4_warning(dir->i_sb,
+ "Unrecognised inode hash code %d for directory #%lu",
+ info->hash_version, dir->i_ino);
goto fail;
}
if (ext4_hash_in_dirent(dir)) {
- if (root->info.hash_version != DX_HASH_SIPHASH) {
+ if (info->hash_version != DX_HASH_SIPHASH) {
ext4_warning_inode(dir,
"Hash in dirent, but hash is not SIPHASH");
goto fail;
}
} else {
- if (root->info.hash_version == DX_HASH_SIPHASH) {
+ if (info->hash_version == DX_HASH_SIPHASH) {
ext4_warning_inode(dir,
"Hash code is SIPHASH, but hash not in dirent");
goto fail;
@@ -816,7 +819,7 @@ dx_probe(struct ext4_filename *fname, struct inode *dir,
}
if (fname)
hinfo = &fname->hinfo;
- hinfo->hash_version = root->info.hash_version;
+ hinfo->hash_version = info->hash_version;
if (hinfo->hash_version <= DX_HASH_TEA)
hinfo->hash_version += EXT4_SB(dir->i_sb)->s_hash_unsigned;
hinfo->seed = EXT4_SB(dir->i_sb)->s_hash_seed;
@@ -832,13 +835,13 @@ dx_probe(struct ext4_filename *fname, struct inode *dir,
}
hash = hinfo->hash;
- if (root->info.unused_flags & 1) {
+ if (info->unused_flags & 1) {
ext4_warning_inode(dir, "Unimplemented hash flags: %#06x",
- root->info.unused_flags);
+ info->unused_flags);
goto fail;
}
- indirect = root->info.indirect_levels;
+ indirect = info->indirect_levels;
if (indirect >= ext4_dir_htree_level(dir->i_sb)) {
ext4_warning(dir->i_sb,
"Directory (ino: %lu) htree depth %#06x exceed"
@@ -851,14 +854,17 @@ dx_probe(struct ext4_filename *fname, struct inode *dir,
goto fail;
}
- entries = (struct dx_entry *)(((char *)&root->info) +
- root->info.info_length);
+ entries = (struct dx_entry *)(((char *)info) +
+ info->info_length);
- if (dx_get_limit(entries) != dx_root_limit(dir,
- root->info.info_length)) {
+ if (dx_get_limit(entries) !=
+ dx_root_limit(dir, (struct ext4_dir_entry_2 *)frame->bh->b_data,
+ info->info_length)) {
ext4_warning_inode(dir, "dx entry: limit %u != root limit %u",
dx_get_limit(entries),
- dx_root_limit(dir, root->info.info_length));
+ dx_root_limit(dir,
+ (struct ext4_dir_entry_2 *)frame->bh->b_data,
+ info->info_length));
goto fail;
}
@@ -944,7 +950,7 @@ static void dx_release(struct dx_frame *frames)
if (frames[0].bh == NULL)
return;
- info = &((struct dx_root *)frames[0].bh->b_data)->info;
+ info = dx_get_dx_info((struct ext4_dir_entry_2 *)frames[0].bh->b_data);
/* save local copy, "info" may be freed after brelse() */
indirect_levels = info->indirect_levels;
for (i = 0; i <= indirect_levels; i++) {
@@ -2156,44 +2162,38 @@ static int add_dirent_to_buf(handle_t *handle, struct ext4_filename *fname,
return err ? err : err2;
}
-static bool ext4_check_dx_root(struct inode *dir, struct dx_root *root)
+static bool ext4_check_dx_root(struct inode *dir,
+ struct ext4_dir_entry_2 *dot_de,
+ struct ext4_dir_entry_2 *dotdot_de,
+ struct ext4_dir_entry_2 **entry)
{
- struct fake_dirent *fde;
const char *error_msg;
- unsigned int rlen;
unsigned int blocksize = dir->i_sb->s_blocksize;
- char *blockend = (char *)root + dir->i_sb->s_blocksize;
+ struct ext4_dir_entry_2 *de = NULL;
- fde = &root->dot;
- if (unlikely(fde->name_len != 1)) {
+ if (unlikely(dot_de->name_len != 1)) {
error_msg = "invalid name_len for '.'";
goto corrupted;
}
- if (unlikely(strncmp(root->dot_name, ".", fde->name_len))) {
+ if (unlikely(strncmp(dot_de->name, ".", dot_de->name_len))) {
error_msg = "invalid name for '.'";
goto corrupted;
}
- rlen = ext4_rec_len_from_disk(fde->rec_len, blocksize);
- if (unlikely((char *)fde + rlen >= blockend)) {
- error_msg = "invalid rec_len for '.'";
- goto corrupted;
- }
- fde = &root->dotdot;
- if (unlikely(fde->name_len != 2)) {
+ if (unlikely(dotdot_de->name_len != 2)) {
error_msg = "invalid name_len for '..'";
goto corrupted;
}
- if (unlikely(strncmp(root->dotdot_name, "..", fde->name_len))) {
+ if (unlikely(strncmp(dotdot_de->name, "..", dotdot_de->name_len))) {
error_msg = "invalid name for '..'";
goto corrupted;
}
- rlen = ext4_rec_len_from_disk(fde->rec_len, blocksize);
- if (unlikely((char *)fde + rlen >= blockend)) {
+ de = ext4_next_entry(dotdot_de, blocksize);
+ if ((char *)de >= (((char *)dot_de) + blocksize)) {
error_msg = "invalid rec_len for '..'";
goto corrupted;
}
-
+ *entry = de;
return true;
corrupted:
@@ -2211,16 +2211,15 @@ static int make_indexed_dir(handle_t *handle, struct ext4_filename *fname,
struct inode *inode, struct buffer_head *bh)
{
struct buffer_head *bh2;
- struct dx_root *root;
struct dx_frame frames[EXT4_HTREE_LEVEL], *frame;
struct dx_entry *entries;
- struct ext4_dir_entry_2 *de, *de2;
+ struct ext4_dir_entry_2 *de, *de2, *dot_de, *dotdot_de;
char *data2, *top;
unsigned len;
int retval;
unsigned blocksize;
ext4_lblk_t block;
- struct fake_dirent *fde;
+ struct dx_root_info *dx_info;
int csum_size = 0;
if (ext4_has_feature_metadata_csum(inode->i_sb))
@@ -2237,17 +2236,15 @@ static int make_indexed_dir(handle_t *handle, struct ext4_filename *fname,
return retval;
}
- root = (struct dx_root *) bh->b_data;
- if (!ext4_check_dx_root(dir, root)) {
+ dot_de = (struct ext4_dir_entry_2 *)bh->b_data;
+ dotdot_de = ext4_next_entry(dot_de, blocksize);
+ if (!ext4_check_dx_root(dir, dot_de, dotdot_de, &de)) {
brelse(bh);
return -EFSCORRUPTED;
}
/* The 0th block becomes the root, move the dirents out */
- fde = &root->dotdot;
- de = (struct ext4_dir_entry_2 *)((char *)fde +
- ext4_rec_len_from_disk(fde->rec_len, blocksize));
- len = ((char *) root) + (blocksize - csum_size) - (char *) de;
+ len = ((char *)dot_de) + (blocksize - csum_size) - (char *)de;
/* Allocate new block for the 0th block's dirents */
bh2 = ext4_append(handle, dir, &block);
@@ -2278,24 +2275,27 @@ static int make_indexed_dir(handle_t *handle, struct ext4_filename *fname,
ext4_initialize_dirent_tail(bh2, blocksize);
/* Initialize the root; the dot dirents already exist */
- de = (struct ext4_dir_entry_2 *) (&root->dotdot);
- de->rec_len = ext4_rec_len_to_disk(
- blocksize - ext4_dir_rec_len(2, NULL), blocksize);
- memset (&root->info, 0, sizeof(root->info));
- root->info.info_length = sizeof(root->info);
+ dotdot_de->rec_len =
+ ext4_rec_len_to_disk(blocksize - le16_to_cpu(dot_de->rec_len),
+ blocksize);
+
+ /* initialize hashing info */
+ dx_info = dx_get_dx_info(dot_de);
+ memset(dx_info, 0, sizeof(*dx_info));
+ dx_info->info_length = sizeof(*dx_info);
if (ext4_hash_in_dirent(dir))
- root->info.hash_version = DX_HASH_SIPHASH;
+ dx_info->hash_version = DX_HASH_SIPHASH;
else
- root->info.hash_version =
+ dx_info->hash_version =
EXT4_SB(dir->i_sb)->s_def_hash_version;
- entries = root->entries;
+ entries = (void *)dx_info + sizeof(*dx_info);
dx_set_block(entries, 1);
dx_set_count(entries, 1);
- dx_set_limit(entries, dx_root_limit(dir, sizeof(root->info)));
+ dx_set_limit(entries, dx_root_limit(dir, dot_de, sizeof(*dx_info)));
/* Initialize as for dx_probe */
- fname->hinfo.hash_version = root->info.hash_version;
+ fname->hinfo.hash_version = dx_info->hash_version;
if (fname->hinfo.hash_version <= DX_HASH_TEA)
fname->hinfo.hash_version += EXT4_SB(dir->i_sb)->s_hash_unsigned;
fname->hinfo.seed = EXT4_SB(dir->i_sb)->s_hash_seed;
@@ -2598,7 +2598,7 @@ static int ext4_dx_add_entry(handle_t *handle, struct ext4_filename *fname,
if (restart || err)
goto journal_error;
} else {
- struct dx_root *dxroot;
+ struct dx_root_info *info;
memcpy((char *) entries2, (char *) entries,
icount * sizeof(struct dx_entry));
dx_set_limit(entries2, dx_node_limit(dir));
@@ -2606,8 +2606,9 @@ static int ext4_dx_add_entry(handle_t *handle, struct ext4_filename *fname,
/* Set up root */
dx_set_count(entries, 1);
dx_set_block(entries + 0, newblock);
- dxroot = (struct dx_root *)frames[0].bh->b_data;
- dxroot->info.indirect_levels += 1;
+ info = dx_get_dx_info((struct ext4_dir_entry_2 *)
+ frames[0].bh->b_data);
+ info->indirect_levels = 1;
dxtrace(printk(KERN_DEBUG
"Creating %d level index...\n",
dxroot->info.indirect_levels));
--
2.43.5
^ permalink raw reply related
* [PATCH 0/3] Data in direntry (dirdata) feature
From: Artem Blagodarenko @ 2026-04-17 21:37 UTC (permalink / raw)
To: linux-ext4; +Cc: adilger.kernel, Artem Blagodarenko
EXT4 currently stores a hash in the directory entry
(dirent) immediately after the file name to support
simultaneous fscrypt and casefold functionality.
It has been discussed within the EXT4 community that
this hash could instead be stored in dirdata. This
would make it the second (or third, in the case of
64-bit inode counts) user of dirdata.
At the same time, the existing format—where the hash
is placed after the file name—must continue to be
supported. With these patches, EXT4 can handle the
hash in both formats.
The first user of this feature, LUFID, has been
tested in the Lustre filesystem backend (LDISKFS)
[1].
Support for fscrypt and case-insensitive directories
with dirdata enabled has been verified using a
dedicated xfstest submitted to the EXT4 community as
a separate patch.
e2fsprogs support is provided in a separate patch.
[1] https://review.whamcloud.com/c/fs/lustre-release/+/64439
Artem Blagodarenko (3):
ext4: make dirdata work with metadata_csum
ext4: add dirdata support structures and helpers
ext4: dirdata feature
fs/ext4/dir.c | 9 +-
fs/ext4/ext4.h | 169 +++++++++++++++++++--
fs/ext4/inline.c | 22 +--
fs/ext4/namei.c | 379 ++++++++++++++++++++++++++++++-----------------
fs/ext4/super.c | 4 +-
fs/ext4/sysfs.c | 2 +
6 files changed, 422 insertions(+), 163 deletions(-)
--
2.43.5
^ permalink raw reply
* [GIT PULL] ext4 changes for 7.1-rc1
From: Theodore Ts'o @ 2026-04-17 15:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Developers List, Ext4 Developers List
The following changes since commit 9ee29d20aab228adfb02ca93f87fb53c56c2f3af:
ext4: always drain queued discard work in ext4_mb_release() (2026-03-27 23:39:10 -0400)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linux-7.0-rc1
for you to fetch changes up to 981fcc5674e67158d24d23e841523eccba19d0e7:
jbd2: fix deadlock in jbd2_journal_cancel_revoke() (2026-04-09 22:09:39 -0400)
----------------------------------------------------------------
Various clean ups and bug fixes in ext4 for 7.1:
* Refactor code paths involved with partial block zero-out in
prearation for converting ext4 to use iomap for buffered writes.
* Remove use of d_alloc() from ext4 in preparation for the deprecation
of this interface.
* Replace some J_ASSERTS with a journal abort so we can avoid a kernel
panic for a localized file system error
* Simplify various code paths in mballoc, move_extent, and fast commit
* Fix rare deadlock in jbd2_journal_cancel_revoke() that can be
triggered by generic/013 when blocksize < pagesize.
* Fix memory leak when releasing an extended attribute when its
value is stored in an ea_inode
* Fix various potential kunit test bugs in fs/ext4/extents.c
* Fix potential out-of-bounds access in check_xattr() with a corrupted
file system
* Make the jbd2_inode dirty range tracking safe for lockless reads
* Avoid a WARN_ON when writeback files due to a corrupted file system;
we already print an ext4 warning indicatign that data will be lost,
so the WARN_ON is not necessary and doesn't add any new information
----------------------------------------------------------------
David Laight (1):
ext4: fix diagnostic printf formats
Deepanshu Kartikey (2):
ext4: unmap invalidated folios from page tables in mpage_release_unused_pages()
ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access
Guoqing Jiang (1):
ext4: remove tl argument from ext4_fc_replay_{add,del}_range
Julia Lawall (1):
ext4/move_extent: use folio_next_pos()
Li Chen (5):
ext4: remove unused i_fc_wait
jbd2: add jinode dirty range accessors
ext4: use jbd2 jinode dirty range accessor
ocfs2: use jbd2 jinode dirty range accessor
jbd2: store jinode dirty range in PAGE_SIZE units
Milos Nikic (2):
jbd2: gracefully abort instead of panicking on unlocked buffer
jbd2: gracefully abort on transaction state corruptions
NeilBrown (3):
ext4: split __ext4_add_entry() out of ext4_add_entry()
ext4: add ext4_fc_eligible()
ext4: move dcache manipulation out of __ext4_link()
Philipp Hahn (1):
ext4: prefer IS_ERR_OR_NULL over manual NULL check
Sohei Koyama (1):
ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()
Weixie Cui (1):
ext4: simplify mballoc preallocation size rounding for small files
Ye Bin (5):
ext4: fix miss unlock 'sb->s_umount' in extents_kunit_init()
ext4: call deactivate_super() in extents_kunit_exit()
ext4: fix the error handling process in extents_kunit_init).
ext4: fix possible null-ptr-deref in extents_kunit_exit()
ext4: fix possible null-ptr-deref in mbt_kunit_exit()
Zhang Yi (14):
ext4: add did_zero output parameter to ext4_block_zero_page_range()
ext4: rename and extend ext4_block_truncate_page()
ext4: factor out journalled block zeroing range
ext4: rename ext4_block_zero_page_range() to ext4_block_zero_range()
ext4: move ordered data handling out of ext4_block_do_zero_range()
ext4: remove handle parameters from zero partial block functions
ext4: pass allocate range as loff_t to ext4_alloc_file_blocks()
ext4: move zero partial block range functions out of active handle
ext4: ensure zeroed partial blocks are persisted in SYNC mode
ext4: unify SYNC mode checks in fallocate paths
ext4: remove ctime/mtime update from ext4_alloc_file_blocks()
ext4: move pagecache_isize_extended() out of active handle
ext4: zero post-EOF partial block before appending write
jbd2: fix deadlock in jbd2_journal_cancel_revoke()
fs/ext4/ext4.h | 14 +--
fs/ext4/extents-test.c | 60 +++++++---
fs/ext4/extents.c | 163 +++++++++++++-------------
fs/ext4/fast_commit.c | 89 ++++-----------
fs/ext4/file.c | 17 +++
fs/ext4/inode.c | 304 ++++++++++++++++++++++++++++++++-----------------
fs/ext4/mballoc-test.c | 6 +-
fs/ext4/mballoc.c | 26 ++---
fs/ext4/move_extent.c | 4 +-
fs/ext4/namei.c | 48 ++++----
fs/ext4/super.c | 16 ++-
fs/ext4/symlink.c | 2 +-
fs/ext4/xattr.c | 6 +-
fs/jbd2/commit.c | 55 ++++++---
fs/jbd2/journal.c | 5 +-
fs/jbd2/revoke.c | 8 +-
fs/jbd2/transaction.c | 142 +++++++++++++++++------
fs/ocfs2/journal.c | 9 +-
include/linux/jbd2.h | 38 +++++--
19 files changed, 628 insertions(+), 384 deletions(-)
^ permalink raw reply
* Re: [PATCH] iomap: avoid memset iomap when iter is done
From: changfengnan @ 2026-04-17 9:15 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Brian Foster, Fengnan Chang, brauner, djwong, hch, linux-xfs,
linux-fsdevel, linux-ext4, lidiangang
In-Reply-To: <aeHg4hUsVTxzm66I@infradead.org>
> From: "Christoph Hellwig"<hch@infradead.org>
> Date: Fri, Apr 17, 2026, 15:27
> Subject: Re: [PATCH] iomap: avoid memset iomap when iter is done
> To: "Brian Foster"<bfoster@redhat.com>
> Cc: "Fengnan Chang"<fengnanchang@gmail.com>, <brauner@kernel.org>, <djwong@kernel.org>, <hch@infradead.org>, <linux-xfs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <linux-ext4@vger.kernel.org>, <lidiangang@bytedance.com>, "Fengnan Chang"<changfengnan@bytedance.com>
> On Thu, Apr 16, 2026 at 09:27:22AM -0400, Brian Foster wrote:
> > This seems reasonable to me in principle, but it feels a little odd to
> > leave a reset helper that doesn't really do a "reset."
>
> Agreed.
>
> > I wonder if this
> > should be refactored into an iomap_iter_complete() (i.e. "complete an
> > iteration") helper that includes the ret assignment logic just above the
> > reset call and returns it, and then maybe leave a oneline comment above
> > the memset so somebody doesn't blindly fold it back in the future. So
> > for example:
>
> What about just killing iomap_iter_reset_iomap in it's current form
> instead? Move the batch reset logic into a little helper if we care,
> and just inline the rest into the only claler to side-step the issue.
Sounds good, move iter->status out, and then rename
iomap_iter_reset_iomap to iomap_iter_clean_folio_batch.
>
^ permalink raw reply
* Re: [PATCH] iomap: avoid memset iomap when iter is done
From: Christoph Hellwig @ 2026-04-17 7:27 UTC (permalink / raw)
To: Brian Foster
Cc: Fengnan Chang, brauner, djwong, hch, linux-xfs, linux-fsdevel,
linux-ext4, lidiangang, Fengnan Chang
In-Reply-To: <aeDjui2LGSidEHcJ@bfoster>
On Thu, Apr 16, 2026 at 09:27:22AM -0400, Brian Foster wrote:
> This seems reasonable to me in principle, but it feels a little odd to
> leave a reset helper that doesn't really do a "reset."
Agreed.
> I wonder if this
> should be refactored into an iomap_iter_complete() (i.e. "complete an
> iteration") helper that includes the ret assignment logic just above the
> reset call and returns it, and then maybe leave a oneline comment above
> the memset so somebody doesn't blindly fold it back in the future. So
> for example:
What about just killing iomap_iter_reset_iomap in it's current form
instead? Move the batch reset logic into a little helper if we care,
and just inline the rest into the only claler to side-step the issue.
^ permalink raw reply
* Re: [PATCH v2 3/3] ext4: derive f_fsid from block device to avoid collisions
From: Christoph Hellwig @ 2026-04-17 7:34 UTC (permalink / raw)
To: Anand Jain
Cc: Theodore Tso, Christoph Hellwig, Darrick J. Wong, linux-ext4,
linux-btrfs, linux-xfs, Anand Jain, dsterba
In-Reply-To: <b593ab17-afaf-4128-97eb-0ab9c23dec5c@gmail.com>
On Thu, Apr 16, 2026 at 11:21:41PM +0800, Anand Jain wrote:
> > But given that you originally stumbled across this with Overlayfs,
> > because it was originally using s_uuid, and that didn't work well for
> > btrfs, why not change overlayfs to just use s_uuid plus kdev_t in its
> > xattr, and just fix the problem for overlayfs? That has the benefit
> > that it will work for all file system types in Linux, not just for
> > those where we have changed what f_fsid does.
>
> Using `kdev_t` (or any derivation of it) for persistent storage, such
> as Overlayfs xattrs, is problematic. Since `kdev_t` is transient and
> inconsistent across reboots or device re-discovery, it could lead to
> broken associations.
Yes, using a dev_t in anything persistent is a really bad ida.
> It seems we've reached the functional limits of f_fsid.
> If we want to solve this properly for Overlayfs, NFS handles, or a
> complex system monitoring..etc, we need a new identifier let's call
> it f_fsid_v2, that meets the following requirements:
>
> System-wide Uniqueness: Must distinguish between cloned filesystems.
>
> Persistence: Must remain consistent across reboots/HW re-enumeration.
>
> Non-On-Disk: Must not be stored on-disk.
The third requirement doesn't make much sense to me. If it is
persistent it. or something it can be derived from must be stored
on-disk.
>
>
> One possible implementation for f_fsid_v2 could be:
>
> f_fsid_v2 = hash(s_uuid, block_device_serial, [subvol_id])
>
> For pseudo block devices (virtio-blk, loop, nbd, brd,..),
> the serial could be derived recursively:
>
> serial_number = hash(backing_file.f_fsid_v2, backing_file.ino)
What i the point in this? All of this seems to be better served
by s_uuid.
> Note on Hardware Serials:
> Standard storage protocols (T10, NVMe, SAS) mandate unique,
> persistent serials per LUN. While I've seen T10 protocol
> violations during my time authoring Solaris HBA drivers, I
> believe these outliers shouldn't dictate the design.
No, T10 does not actually mandate unique identifiers, NVMe does, but the
implementations are often totally broken.
^ permalink raw reply
* Re: [RFC PATCH] iomap: add fast read path for small direct I/O
From: Christoph Hellwig @ 2026-04-17 7:30 UTC (permalink / raw)
To: changfengnan
Cc: Christoph Hellwig, Fengnan Chang, brauner, djwong, linux-xfs,
linux-fsdevel, linux-ext4, lidiangang
In-Reply-To: <d9210bcdf73fbe1ac8b6ec132865609a3ed68688.eee197c0.e67e.40c8.bd15.8fab5bbb42db@bytedance.com>
On Thu, Apr 16, 2026 at 11:16:23AM +0800, changfengnan wrote:
> > But it already is a major improvement, and one that would apply outside
> > of narrow special cases. So I'd really like to see that patch.
> You can see this in:
> https://lore.kernel.org/linux-fsdevel/20260416030642.26744-1-changfengnan@bytedance.com/T/#u
Thanks!
> > All direct I/O requires this.
> >
> > > - No bounce buffering, fscrypt, or fsverity involved.
> > > - No custom `iomap_dio_ops` (dops) registered by the filesystem.
> >
> > I'm really curious at what difference this makes. It removes a few
> > branches, but should not have much of an effect while limiting the
> > applicability a lot.
> Yes, the impact shouldn’t be significant.
> Since this is just a RFC version to confirm that I’m on the right path, there
> are many aspects that haven’t been fully thought through yet. I haven’t
> tested these scenarios yet, but I’ll add support for them later to
> check exactly what the impact is.
Sure. It might also make sense to skip some of this if it brings a big
enough benefit.
> > > +struct iomap_dio_fast_read {
> > > + struct kiocb *iocb;
> > > + size_t size;
> > > + bool should_dirty;
> > > + struct work_struct work;
> > > + struct bio bio ____cacheline_aligned_in_smp;
> >
> > Does the cache line alignment matter here? If yes, can you explain why
> > in a comment?
>
> I copy this from struct blkdev_dio , I'll do some test to verfiy.
Thanks. Btw, another thing that might be worth is to drop the
work_struct and reuse iomap_fail_reads or something similar to it.
This would be a pretty big size reduction. Additionally we should
be able to kill should_dirty and just rely on bio or kiocb flags.
^ permalink raw reply
* Re: [PATCH] iomap: avoid memset iomap when iter is done
From: changfengnan @ 2026-04-17 2:19 UTC (permalink / raw)
To: Mateusz Guzik
Cc: Darrick J. Wong, Brian Foster, Fengnan Chang, brauner, hch,
linux-xfs, linux-fsdevel, linux-ext4, lidiangang
In-Reply-To: <hgug5jbkwk352zrwcngdofwiy2hq4nk7eq7yvzi6nru5zyebd2@fe64yziutvlk>
> From: "Mateusz Guzik"<mjguzik@gmail.com>
> Date: Fri, Apr 17, 2026, 07:21
> Subject: Re: [PATCH] iomap: avoid memset iomap when iter is done
> To: "Darrick J. Wong"<djwong@kernel.org>
> Cc: "Brian Foster"<bfoster@redhat.com>, "Fengnan Chang"<fengnanchang@gmail.com>, <brauner@kernel.org>, <hch@infradead.org>, <linux-xfs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <linux-ext4@vger.kernel.org>, <lidiangang@bytedance.com>, "Fengnan Chang"<changfengnan@bytedance.com>
> On Thu, Apr 16, 2026 at 08:27:05AM -0700, Darrick J. Wong wrote:
> > What kind of computer is this where there's a 5% hit to iops from a
> > memset of ~150 bytes?
> >
>
> Such a memset is not free in its own right, but here the real problem is
> *how* it is done: by default gcc emits inlined 'rep stosq' which has
> utterly horrid performance (same as 'rep movsq') and in this particular
> case the 2 memsets in the source code result in 2 separate 'rep movsq'
> invocations.
Yes, two 'rep stosq'.
>
> I complained about it numerous times, see this to get a taste:
> https://lore.kernel.org/all/20250605164733.737543-1-mjguzik@gmail.com/
>
> Also see
> https://lore.kernel.org/all/202504181042.54ea2b8a-lkp@intel.com/
>
> If memory serves right gcc is going to fix it, so this is largely going
> to clear itself down the road.
Sounds good, I believe there are other similar issues that haven't been
discovered yet. In this case, removing `memset` is the best option, since
we don't need it.
>
^ permalink raw reply
* Re: [PATCH] iomap: avoid memset iomap when iter is done
From: changfengnan @ 2026-04-17 2:15 UTC (permalink / raw)
To: Dave Chinner
Cc: Darrick J. Wong, Brian Foster, Fengnan Chang, brauner, hch,
linux-xfs, linux-fsdevel, linux-ext4, lidiangang
In-Reply-To: <aeFlvXDShzIuOU9z@dread>
> From: "Dave Chinner"<dgc@kernel.org>
> Date: Fri, Apr 17, 2026, 06:42
> Subject: Re: [PATCH] iomap: avoid memset iomap when iter is done
> To: "Darrick J. Wong"<djwong@kernel.org>
> Cc: "Brian Foster"<bfoster@redhat.com>, "Fengnan Chang"<fengnanchang@gmail.com>, <brauner@kernel.org>, <hch@infradead.org>, <linux-xfs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <linux-ext4@vger.kernel.org>, <lidiangang@bytedance.com>, "Fengnan Chang"<changfengnan@bytedance.com>
> On Thu, Apr 16, 2026 at 08:27:05AM -0700, Darrick J. Wong wrote:
> > On Thu, Apr 16, 2026 at 09:27:22AM -0400, Brian Foster wrote:
> > > On Thu, Apr 16, 2026 at 11:06:42AM +0800, Fengnan Chang wrote:
> > > > When iomap_iter() finishes its iteration (returns <= 0), it is no longer
> > > > necessary to memset the entire iomap and srcmap structures.
> > > >
> > > > In high-IOPS scenarios (like 4k randread NVMe polling with io_uring),
> > > > where the majority of I/Os complete in a single extent map, this wasted
> > > > memory write bandwidth, as the caller will just discard the iterator.
> > > >
> > > > Use this command to test:
> > > > taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1
> > > > -n1 -P1 /mnt/testfile
> > > > IOPS improve about 5% on ext4 and XFS.
> > > >
> > > > However, we MUST still call iomap_iter_reset_iomap() to release the
> > > > folio_batch if IOMAP_F_FOLIO_BATCH is set, otherwise we leak page
> > > > references. Therefore, split the cleanup logic: always release the
> > > > folio_batch, but skip the memset() when ret <= 0.
> > > >
> > > > Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
> > > > ---
> > > > fs/iomap/iter.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
> > > > index c04796f6e57f..91eb5e6165ff 100644
> > > > --- a/fs/iomap/iter.c
> > > > +++ b/fs/iomap/iter.c
> > > > @@ -15,8 +15,6 @@ static inline void iomap_iter_reset_iomap(struct iomap_iter *iter)
> > > > }
> > > >
> > > > iter->status = 0;
> > > > - memset(&iter->iomap, 0, sizeof(iter->iomap));
> > > > - memset(&iter->srcmap, 0, sizeof(iter->srcmap));
> > > > }
> > > >
> > > > /* Advance the current iterator position and decrement the remaining length */
> > > > @@ -106,6 +104,9 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
> > > > if (ret <= 0)
> > > > return ret;
> > > >
> > > > + memset(&iter->iomap, 0, sizeof(iter->iomap));
> > > > + memset(&iter->srcmap, 0, sizeof(iter->srcmap));
> > > > +
> > >
> > > This seems reasonable to me in principle, but it feels a little odd to
> > > leave a reset helper that doesn't really do a "reset." I wonder if this
> > > should be refactored into an iomap_iter_complete() (i.e. "complete an
> > > iteration") helper that includes the ret assignment logic just above the
> > > reset call and returns it, and then maybe leave a oneline comment above
> > > the memset so somebody doesn't blindly fold it back in the future. So
> > > for example:
> > >
> > > ret = iomap_iter_complete(iter);
> > > if (ret <= 0)
> > > return ret;
> > >
> > > /* save cycles and only clear the mappings if we plan to iterate */
> > > memset(..);
> > > ...
> > >
> > > We'd probably have to recheck some of the iter state within the new
> > > helper, but that doesn't seem like a big deal to me. Thoughts?
> >
> > What kind of computer is this where there's a 5% hit to iops from a
> > memset of ~150 bytes?
>
> Even small costs can have a big impact when you have to pay it many
> times.
>
> i.e. 2 million IOPS * 2 * 72 bytes per IO = 288MB/s of memory being
> zeroed unnecessarily in very small (inefficient) chunks.
>
> That's definitely enough to cause a 5% drop in IOPS when the
> workload is CPU or memory bandwidth bound....
My CPU is Intel(R) Xeon(R) Platinum 8457C with 1TB RAM, NVMe is
PS1010 and the system is very idle, only run one command with one core:
taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 \
-X1 -n1 -P1 /mnt/mytest，IOPS improved from 1.9M to 2.0M.
My test is a CPU bound case，these two memset operations should
have taken only about 15 nanoseconds. at 2.0 million IOPS, the total
CPU time budget per I/O operation averages just 500 nanoseconds.
Taking into account the impact on the pipeline and the L1 cache, a 5%
improvement is reasonable.
>
> -Dave.
> --
> Dave Chinner
> dgc@kernel.org
>
^ permalink raw reply
* Re: [PATCH] iomap: avoid memset iomap when iter is done
From: Mateusz Guzik @ 2026-04-16 23:20 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Brian Foster, Fengnan Chang, brauner, hch, linux-xfs,
linux-fsdevel, linux-ext4, lidiangang, Fengnan Chang
In-Reply-To: <20260416152705.GC114239@frogsfrogsfrogs>
On Thu, Apr 16, 2026 at 08:27:05AM -0700, Darrick J. Wong wrote:
> What kind of computer is this where there's a 5% hit to iops from a
> memset of ~150 bytes?
>
Such a memset is not free in its own right, but here the real problem is
*how* it is done: by default gcc emits inlined 'rep stosq' which has
utterly horrid performance (same as 'rep movsq') and in this particular
case the 2 memsets in the source code result in 2 separate 'rep movsq'
invocations.
I complained about it numerous times, see this to get a taste:
https://lore.kernel.org/all/20250605164733.737543-1-mjguzik@gmail.com/
Also see
https://lore.kernel.org/all/202504181042.54ea2b8a-lkp@intel.com/
If memory serves right gcc is going to fix it, so this is largely going
to clear itself down the road.
^ permalink raw reply
* Re: [PATCH] iomap: avoid memset iomap when iter is done
From: Dave Chinner @ 2026-04-16 22:42 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Brian Foster, Fengnan Chang, brauner, hch, linux-xfs,
linux-fsdevel, linux-ext4, lidiangang, Fengnan Chang
In-Reply-To: <20260416152705.GC114239@frogsfrogsfrogs>
On Thu, Apr 16, 2026 at 08:27:05AM -0700, Darrick J. Wong wrote:
> On Thu, Apr 16, 2026 at 09:27:22AM -0400, Brian Foster wrote:
> > On Thu, Apr 16, 2026 at 11:06:42AM +0800, Fengnan Chang wrote:
> > > When iomap_iter() finishes its iteration (returns <= 0), it is no longer
> > > necessary to memset the entire iomap and srcmap structures.
> > >
> > > In high-IOPS scenarios (like 4k randread NVMe polling with io_uring),
> > > where the majority of I/Os complete in a single extent map, this wasted
> > > memory write bandwidth, as the caller will just discard the iterator.
> > >
> > > Use this command to test:
> > > taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1
> > > -n1 -P1 /mnt/testfile
> > > IOPS improve about 5% on ext4 and XFS.
> > >
> > > However, we MUST still call iomap_iter_reset_iomap() to release the
> > > folio_batch if IOMAP_F_FOLIO_BATCH is set, otherwise we leak page
> > > references. Therefore, split the cleanup logic: always release the
> > > folio_batch, but skip the memset() when ret <= 0.
> > >
> > > Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
> > > ---
> > > fs/iomap/iter.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
> > > index c04796f6e57f..91eb5e6165ff 100644
> > > --- a/fs/iomap/iter.c
> > > +++ b/fs/iomap/iter.c
> > > @@ -15,8 +15,6 @@ static inline void iomap_iter_reset_iomap(struct iomap_iter *iter)
> > > }
> > >
> > > iter->status = 0;
> > > - memset(&iter->iomap, 0, sizeof(iter->iomap));
> > > - memset(&iter->srcmap, 0, sizeof(iter->srcmap));
> > > }
> > >
> > > /* Advance the current iterator position and decrement the remaining length */
> > > @@ -106,6 +104,9 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
> > > if (ret <= 0)
> > > return ret;
> > >
> > > + memset(&iter->iomap, 0, sizeof(iter->iomap));
> > > + memset(&iter->srcmap, 0, sizeof(iter->srcmap));
> > > +
> >
> > This seems reasonable to me in principle, but it feels a little odd to
> > leave a reset helper that doesn't really do a "reset." I wonder if this
> > should be refactored into an iomap_iter_complete() (i.e. "complete an
> > iteration") helper that includes the ret assignment logic just above the
> > reset call and returns it, and then maybe leave a oneline comment above
> > the memset so somebody doesn't blindly fold it back in the future. So
> > for example:
> >
> > ret = iomap_iter_complete(iter);
> > if (ret <= 0)
> > return ret;
> >
> > /* save cycles and only clear the mappings if we plan to iterate */
> > memset(..);
> > ...
> >
> > We'd probably have to recheck some of the iter state within the new
> > helper, but that doesn't seem like a big deal to me. Thoughts?
>
> What kind of computer is this where there's a 5% hit to iops from a
> memset of ~150 bytes?
Even small costs can have a big impact when you have to pay it many
times.
i.e. 2 million IOPS * 2 * 72 bytes per IO = 288MB/s of memory being
zeroed unnecessarily in very small (inefficient) chunks.
That's definitely enough to cause a 5% drop in IOPS when the
workload is CPU or memory bandwidth bound....
-Dave.
--
Dave Chinner
dgc@kernel.org
^ permalink raw reply
* Re: [patch 07/38] treewide: Consolidate cycles_t
From: Thomas Gleixner @ 2026-04-16 19:32 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <0758843e-8f75-4c82-b9c0-25fab502e62f@kernel.org>
On Wed, Apr 15 2026 at 08:43, Christophe Leroy wrote:
>> -typedef unsigned long cycles_t;
>> -
>> -static inline cycles_t get_cycles(void)
>> +ostatic inline cycles_t get_cycles(void)
>
> What is 'ostatic' ?
That's a really good question :)
^ permalink raw reply
* Re: [patch 35/38] s390: Select ARCH_HAS_RANDOM_ENTROPY
From: Thomas Gleixner @ 2026-04-16 19:29 UTC (permalink / raw)
To: Heiko Carstens
Cc: LKML, linux-s390, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, David S. Miller,
sparclinux
In-Reply-To: <20260416134238.9230Ba6-hca@linux.ibm.com>
On Thu, Apr 16 2026 at 15:42, Heiko Carstens wrote:
> On Fri, Apr 10, 2026 at 02:21:19PM +0200, Thomas Gleixner wrote:
>> The only remaining non-architecture usage of get_cycles() is to provide
>> random_get_entropy().
>>
>> Switch s390 over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY and
>> providing random_get_entropy() in asm/random.h.
>>
>> Add 'asm/timex.h' includes to the relevant files, so the global include can
>> be removed once all architectures are converted over.
>>
>> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
>> Cc: Heiko Carstens <hca@linux.ibm.com>
>> Cc: linux-s390@vger.kernel.org
>> ---
>> arch/s390/Kconfig | 1 +
>> arch/s390/include/asm/random.h | 12 ++++++++++++
>> arch/s390/include/asm/timex.h | 6 ------
>> arch/s390/kernel/time.c | 1 +
>> arch/s390/kernel/vtime.c | 1 +
>> 5 files changed, 15 insertions(+), 6 deletions(-)
>
> Acked-by: Heiko Carstens <hca@linux.ibm.com>
>
> Thomas, would you mind adding the below as minor improvement to this
> series?
Sure. I'll respin it next week.
^ permalink raw reply
* Re: [PATCH 4/6] generic/765: Ignore mkfs warning
From: Zorro Lang @ 2026-04-16 15:55 UTC (permalink / raw)
To: Theodore Tso
Cc: Darrick J. Wong, Ojaswin Mujoo, Zorro Lang, fstests, fdmanana,
ritesh.list, naohiro.aota, wqu, Disha Goel, linux-ext4
In-Reply-To: <20260413204215.GA5461@macsyma-wired.lan>
On Mon, Apr 13, 2026 at 04:42:15PM -0400, Theodore Tso wrote:
> > > > > > The output can get corrupted with warnings like below because clustersize
> > > > > > more than 16xbs is experimental:
> > > > > >
> > > > > > + 16 times the block size is considered experimental
> > > > > >
> > > > > > Hence pipe these to seqres.full to avoid false negatives.
>
> You could also suppress the warnings using the -q option, for example:
>
> mke2fs -Fq -t ext4 -O bigalloc,quota -b 4096 -C 131072 /tmp/foo.img 4G
>
> > > Futher, mke2fs has multiple instances where we print warnings to stderr,
> > > should we go and fix all of them as well?
> >
> > "stderr" meaning "standard error", I'd say that errors are anything that
> > prohibits the format from completing, and only errors should go there.
>
> Sure, I'll accept those changes. But adding -q will allow the test to
> pass using older versions of e2fsprogs, while still allowing stderr to
> go out the expected output.
Aha, good point! Thanks Ted :)
>
> - Ted
>
^ permalink raw reply
* Re: [PATCH] iomap: avoid memset iomap when iter is done
From: Darrick J. Wong @ 2026-04-16 15:27 UTC (permalink / raw)
To: Brian Foster
Cc: Fengnan Chang, brauner, hch, linux-xfs, linux-fsdevel, linux-ext4,
lidiangang, Fengnan Chang
In-Reply-To: <aeDjui2LGSidEHcJ@bfoster>
On Thu, Apr 16, 2026 at 09:27:22AM -0400, Brian Foster wrote:
> On Thu, Apr 16, 2026 at 11:06:42AM +0800, Fengnan Chang wrote:
> > When iomap_iter() finishes its iteration (returns <= 0), it is no longer
> > necessary to memset the entire iomap and srcmap structures.
> >
> > In high-IOPS scenarios (like 4k randread NVMe polling with io_uring),
> > where the majority of I/Os complete in a single extent map, this wasted
> > memory write bandwidth, as the caller will just discard the iterator.
> >
> > Use this command to test:
> > taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1
> > -n1 -P1 /mnt/testfile
> > IOPS improve about 5% on ext4 and XFS.
> >
> > However, we MUST still call iomap_iter_reset_iomap() to release the
> > folio_batch if IOMAP_F_FOLIO_BATCH is set, otherwise we leak page
> > references. Therefore, split the cleanup logic: always release the
> > folio_batch, but skip the memset() when ret <= 0.
> >
> > Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
> > ---
> > fs/iomap/iter.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
> > index c04796f6e57f..91eb5e6165ff 100644
> > --- a/fs/iomap/iter.c
> > +++ b/fs/iomap/iter.c
> > @@ -15,8 +15,6 @@ static inline void iomap_iter_reset_iomap(struct iomap_iter *iter)
> > }
> >
> > iter->status = 0;
> > - memset(&iter->iomap, 0, sizeof(iter->iomap));
> > - memset(&iter->srcmap, 0, sizeof(iter->srcmap));
> > }
> >
> > /* Advance the current iterator position and decrement the remaining length */
> > @@ -106,6 +104,9 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
> > if (ret <= 0)
> > return ret;
> >
> > + memset(&iter->iomap, 0, sizeof(iter->iomap));
> > + memset(&iter->srcmap, 0, sizeof(iter->srcmap));
> > +
>
> This seems reasonable to me in principle, but it feels a little odd to
> leave a reset helper that doesn't really do a "reset." I wonder if this
> should be refactored into an iomap_iter_complete() (i.e. "complete an
> iteration") helper that includes the ret assignment logic just above the
> reset call and returns it, and then maybe leave a oneline comment above
> the memset so somebody doesn't blindly fold it back in the future. So
> for example:
>
> ret = iomap_iter_complete(iter);
> if (ret <= 0)
> return ret;
>
> /* save cycles and only clear the mappings if we plan to iterate */
> memset(..);
> ...
>
> We'd probably have to recheck some of the iter state within the new
> helper, but that doesn't seem like a big deal to me. Thoughts?
What kind of computer is this where there's a 5% hit to iops from a
memset of ~150 bytes?
--D
> Brian
>
> > begin:
> > ret = ops->iomap_begin(iter->inode, iter->pos, iter->len, iter->flags,
> > &iter->iomap, &iter->srcmap);
> > --
> > 2.39.5 (Apple Git-154)
> >
> >
>
^ permalink raw reply
* Re: [PATCH v2 3/3] ext4: derive f_fsid from block device to avoid collisions
From: Anand Jain @ 2026-04-16 15:21 UTC (permalink / raw)
To: Theodore Tso
Cc: Christoph Hellwig, Darrick J. Wong, linux-ext4, linux-btrfs,
linux-xfs, Anand Jain, dsterba
In-Reply-To: <20260409131238.GC18443@macsyma-wired.lan>
On 9/4/26 21:12, Theodore Tso wrote:
> On Thu, Apr 09, 2026 at 05:45:24PM +0800, Anand Jain wrote:
>>
>> Got it. Do you mean that since both filesystems are identical,
>> statfs(A) and statfs(B) can legitimately return the same values?
>
> Yes. f_Fsid can legitimately always be zero (which I believe is the
> case for FreeBSD, but I understand that there are some programs, like
> systemd, which subscribe to the heresy, "All the World's Linux", which
> is a variant of the "All the World's a Vax" or "All the World's SunOS"
> at the beginning of my career :-).
>
>> I'm not entirely sure what the correct expectation for f_fsid
>> should be.
>
> That's my point, there *is* no correct expectation, and I don't
> believe there can or should be. What we should be doing instead is
> actively discouraging people from using f_fsid. I suspect that's one
> of the reasons why FreeBSD may have chosen to just return zero.
>
> Which is why I don't think we should be testing this in xfstests's
> generic/791, either. (Unless we get consensus across file system
> developers abnd willing to make it be a documented behavior as of a
> particular kernel version, and we then adjust the test to skip it if
> it's older than that kernel version, so it doesn't break LTS kernel
> tests. See below....)
>
Yes, the idea for generic/79[0-5] was really just to make sure
we don't accidentally change s_uuid or f_fsid behavior without
realizing it. It gives us a baseline for current and LTS kernels
if f_fsid/s_uuid is changed. (Some of the submitted test cases
may still need revision).
>> My initial idea was to make f_fsid behavior consistent across
>> major filesystems so that user space benefits from predictable
>> semantics.
>
> I'm OK with that, so long as it's unconditional across all file system
> types (ideally) or unconditionally across all major file systems (xfs,
> btrfs, ext4, f2fs) as of a particular kernel version (which is
> probably much more realistic), *and* it is documented in the Linux man
> pages as this is the standard behavior starting with 7.1 (or
> whatever), and that the man page further cautions that programs that
> expect to be portable to other OS's (MacOS, FreeBSD, Solaris, etc.)
> should not count on this behavior.
>
On second thought, we should perhaps consider a more robust ID,
let's call it `f_fsid_v2`. More on `f_fsid_v2` below.
> But given that you originally stumbled across this with Overlayfs,
> because it was originally using s_uuid, and that didn't work well for
> btrfs, why not change overlayfs to just use s_uuid plus kdev_t in its
> xattr, and just fix the problem for overlayfs? That has the benefit
> that it will work for all file system types in Linux, not just for
> those where we have changed what f_fsid does.
Using `kdev_t` (or any derivation of it) for persistent storage, such
as Overlayfs xattrs, is problematic. Since `kdev_t` is transient and
inconsistent across reboots or device re-discovery, it could lead to
broken associations.
It seems we've reached the functional limits of f_fsid.
If we want to solve this properly for Overlayfs, NFS handles, or a
complex system monitoring..etc, we need a new identifier let's call
it f_fsid_v2, that meets the following requirements:
System-wide Uniqueness: Must distinguish between cloned filesystems.
Persistence: Must remain consistent across reboots/HW re-enumeration.
Non-On-Disk: Must not be stored on-disk.
One possible implementation for f_fsid_v2 could be:
f_fsid_v2 = hash(s_uuid, block_device_serial, [subvol_id])
For pseudo block devices (virtio-blk, loop, nbd, brd,..),
the serial could be derived recursively:
serial_number = hash(backing_file.f_fsid_v2, backing_file.ino)
Note on Hardware Serials:
Standard storage protocols (T10, NVMe, SAS) mandate unique,
persistent serials per LUN. While I've seen T10 protocol
violations during my time authoring Solaris HBA drivers, I
believe these outliers shouldn't dictate the design.
This approach provides a system-wide unique ID that is persistent
without being stored on-disk. Effectively solving the cloned
filesystem identity crisis.
Thoughts ?
Thanks, Anand
^ permalink raw reply
* Re: [patch 35/38] s390: Select ARCH_HAS_RANDOM_ENTROPY
From: Heiko Carstens @ 2026-04-16 13:42 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, linux-s390, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.924028412@kernel.org>
On Fri, Apr 10, 2026 at 02:21:19PM +0200, Thomas Gleixner wrote:
> The only remaining non-architecture usage of get_cycles() is to provide
> random_get_entropy().
>
> Switch s390 over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY and
> providing random_get_entropy() in asm/random.h.
>
> Add 'asm/timex.h' includes to the relevant files, so the global include can
> be removed once all architectures are converted over.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: linux-s390@vger.kernel.org
> ---
> arch/s390/Kconfig | 1 +
> arch/s390/include/asm/random.h | 12 ++++++++++++
> arch/s390/include/asm/timex.h | 6 ------
> arch/s390/kernel/time.c | 1 +
> arch/s390/kernel/vtime.c | 1 +
> 5 files changed, 15 insertions(+), 6 deletions(-)
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Thomas, would you mind adding the below as minor improvement to this
series?
From 7072e5d66b99a7fa666d17c6ad8cb254f2d8f473 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <hca@linux.ibm.com>
Date: Thu, 16 Apr 2026 15:08:15 +0200
Subject: [PATCH] s390: Use get_tod_clock_fast() for random_get_entropy()
Use get_tod_clock_fast() instead of get_tod_clock_monotonic() to implement
random_get_entropy().
There is no need for random_get_entropy() to provide monotonic increasing
values, nor is there any need to provide (close to) nanosecond granularity
timestamps by shifting the result.
This slightly reduces the execution time of random_get_entropy() and adds
two bits of randomness.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
arch/s390/include/asm/random.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/random.h b/arch/s390/include/asm/random.h
index 7daf42dbed32..f6d9312efdbf 100644
--- a/arch/s390/include/asm/random.h
+++ b/arch/s390/include/asm/random.h
@@ -6,7 +6,7 @@
static inline unsigned long random_get_entropy(void)
{
- return (unsigned long)get_tod_clock_monotonic() >> 2;
+ return get_tod_clock_fast();
}
#endif
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] iomap: avoid memset iomap when iter is done
From: Brian Foster @ 2026-04-16 13:27 UTC (permalink / raw)
To: Fengnan Chang
Cc: brauner, djwong, hch, linux-xfs, linux-fsdevel, linux-ext4,
lidiangang, Fengnan Chang
In-Reply-To: <20260416030642.26744-1-changfengnan@bytedance.com>
On Thu, Apr 16, 2026 at 11:06:42AM +0800, Fengnan Chang wrote:
> When iomap_iter() finishes its iteration (returns <= 0), it is no longer
> necessary to memset the entire iomap and srcmap structures.
>
> In high-IOPS scenarios (like 4k randread NVMe polling with io_uring),
> where the majority of I/Os complete in a single extent map, this wasted
> memory write bandwidth, as the caller will just discard the iterator.
>
> Use this command to test:
> taskset -c 30 ./t/io_uring -p1 -d512 -b4096 -s32 -c32 -F1 -B1 -R1 -X1
> -n1 -P1 /mnt/testfile
> IOPS improve about 5% on ext4 and XFS.
>
> However, we MUST still call iomap_iter_reset_iomap() to release the
> folio_batch if IOMAP_F_FOLIO_BATCH is set, otherwise we leak page
> references. Therefore, split the cleanup logic: always release the
> folio_batch, but skip the memset() when ret <= 0.
>
> Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
> ---
> fs/iomap/iter.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
> index c04796f6e57f..91eb5e6165ff 100644
> --- a/fs/iomap/iter.c
> +++ b/fs/iomap/iter.c
> @@ -15,8 +15,6 @@ static inline void iomap_iter_reset_iomap(struct iomap_iter *iter)
> }
>
> iter->status = 0;
> - memset(&iter->iomap, 0, sizeof(iter->iomap));
> - memset(&iter->srcmap, 0, sizeof(iter->srcmap));
> }
>
> /* Advance the current iterator position and decrement the remaining length */
> @@ -106,6 +104,9 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
> if (ret <= 0)
> return ret;
>
> + memset(&iter->iomap, 0, sizeof(iter->iomap));
> + memset(&iter->srcmap, 0, sizeof(iter->srcmap));
> +
This seems reasonable to me in principle, but it feels a little odd to
leave a reset helper that doesn't really do a "reset." I wonder if this
should be refactored into an iomap_iter_complete() (i.e. "complete an
iteration") helper that includes the ret assignment logic just above the
reset call and returns it, and then maybe leave a oneline comment above
the memset so somebody doesn't blindly fold it back in the future. So
for example:
ret = iomap_iter_complete(iter);
if (ret <= 0)
return ret;
/* save cycles and only clear the mappings if we plan to iterate */
memset(..);
...
We'd probably have to recheck some of the iter state within the new
helper, but that doesn't seem like a big deal to me. Thoughts?
Brian
> begin:
> ret = ops->iomap_begin(iter->inode, iter->pos, iter->len, iter->flags,
> &iter->iomap, &iter->srcmap);
> --
> 2.39.5 (Apple Git-154)
>
>
^ permalink raw reply
* Re: [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Krzysztof Kozlowski @ 2026-04-16 12:30 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
Cc: Julia Lawall, Nicolas Palix
In-Reply-To: <20260310-b4-is_err_or_null-v1-1-bd63b656022d@avm.de>
On 10/03/2026 12:48, Philipp Hahn wrote:
> Find and convert uses of IS_ERR() plus NULL check to IS_ERR_OR_NULL().
>
> There are several cases where `!ptr && WARN_ON[_ONCE](IS_ERR(ptr))` is
> used:
> - arch/x86/kernel/callthunks.c:215 WARN_ON_ONCE
> - drivers/clk/clk.c:4561 WARN_ON_ONCE
> - drivers/interconnect/core.c:793 WARN_ON
> - drivers/reset/core.c:718 WARN_ON
> The change is not 100% semantical equivalent as the warning will now
> also happen when the pointer is NULL.
>
> To: Julia Lawall <Julia.Lawall@inria.fr>
> To: Nicolas Palix <nicolas.palix@imag.fr>
> Cc: cocci@inria.fr
> Cc: linux-kernel@vger.kernel.org
>
> ---
> drivers/clocksource/mips-gic-timer.c:283 looks suspicious: ret != clk,
> but Daniel Lezcano verified it as cottect.
>
> There are some cases where the checks are part of a larger expression:
> - mm/kmemleak.c:1095
> - mm/kmemleak.c:1155
> - mm/kmemleak.c:1173
> - mm/kmemleak.c:1290
> - mm/kmemleak.c:1328
> - mm/kmemleak.c:1241
> - mm/kmemleak.c:1310
> - mm/kmemleak.c:1258
> - net/netlink/af_netlink.c:2670
> Thanks to Julia Lawall for the help to also handle them.
>
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> scripts/coccinelle/api/is_err_or_null.cocci | 125 ++++++++++++++++++++++++++++
> 1 file changed, 125 insertions(+)
>
Neither this, nor try from 2011, nor any future try should be accepted,
because it creates impression IS_ERR_OR_NULL is somehow okay. No, it is
not okay, it is a discouraged pattern leading to less readable and
maintainable code. We should not have therefore any tools suggesting
usage of IS_ERR_OR_NULL, because people will be converting poor code
into that, instead of fixing that poor code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 55/61] interconnect: Prefer IS_ERR_OR_NULL over manual NULL check
From: Krzysztof Kozlowski @ 2026-04-16 12:24 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
Cc: Georgi Djakov
In-Reply-To: <20260310-b4-is_err_or_null-v1-55-bd63b656022d@avm.de>
On 10/03/2026 12:49, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Semantich change: Previously the code only printed the warning on error,
> but not when the pointer was NULL. Now the warning is printed in both
> cases!
NAK, read the code
>
> Change found with coccinelle.
>
> To: Georgi Djakov <djakov@kernel.org>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/interconnect/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 8569b78a18517b33abeafac091978b25cbc1acc7..22e92b30f73853d5bd2e05b4f52cb5aa22556468 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -790,7 +790,7 @@ void icc_put(struct icc_path *path)
> size_t i;
> int ret;
>
> - if (!path || WARN_ON(IS_ERR(path)))
> + if (WARN_ON(IS_ERR_OR_NULL(path)))
IS_ERR_OR_NULL is simply discouraged, but beside of code preference, you
just added bug here. This is clearly not equivalent and you emit warn on
perfectly valid case!
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] jbd2: enforce power-of-two default revoke hash size at compile time
From: Theodore Tso @ 2026-04-16 11:54 UTC (permalink / raw)
To: Jan Kara; +Cc: Andreas Dilger, Milos Nikic, linux-ext4, linux-kernel
In-Reply-To: <gq6n6m75h47lcr2hvmtlun7revnyf3bx3aanndglbh6djmrjcp@jmxhl7kf7bwu>
On Thu, Apr 16, 2026 at 12:16:05PM +0200, Jan Kara wrote:
>
> Yes, I know. But there is already a runtime assertion in
> jbd2_journal_init_revoke() making sure the passed value is a power of two
> which is verifying also other callers that aren't using
> JOURNAL_REVOKE_DEFAULT_HASH value. I don't see a value in the *additional*
> BUILD_BUG_ON when we already have that runtime check.
... and if a developer doesn't run regression tests before bothering
the list with a patch... that's not a developer we want to cater to.
Milos, my recommended to workflow is to use kvm-xfstests[1], and just do:
% install-kconfig
% kbuild
% kvm-xfstests smoke
[1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
For a successful run, "kvm-xfstests smoke" will run take 15-20
minutes. In the case of screwing up the default power-of-two default
revoke hash size, "kvm-xfstests smoke" will report a failure in less
than a minute.
- Ted
^ permalink raw reply
* Re: [patch 07/38] treewide: Consolidate cycles_t
From: Geert Uytterhoeven @ 2026-04-16 11:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik,
netdev, linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Dinh Nguyen, Jonas Bonn, linux-openrisc,
Helge Deller, linux-parisc, Michael Ellerman, linuxppc-dev,
Paul Walmsley, linux-riscv, Heiko Carstens, linux-s390,
David S. Miller, sparclinux
In-Reply-To: <20260410120318.045532623@kernel.org>
On Fri, 10 Apr 2026 at 14:19, Thomas Gleixner <tglx@kernel.org> wrote:
> Most architectures define cycles_t as unsigned long execpt:
>
> - x86 requires it to be 64-bit independent of the 32-bit/64-bit build.
>
> - parisc and mips define it as unsigned int
>
> parisc has no real reason to do so as there are only a few usage sites
> which either expand it to a 64-bit value or utilize only the lower
> 32bits.
>
> mips has no real requirement either.
>
> Move the typedef to types.h and provide a config switch to enforce the
> 64-bit type for x86.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> arch/m68k/include/asm/timex.h | 2 --
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [patch 05/38] treewide: Remove CLOCK_TICK_RATE
From: Geert Uytterhoeven @ 2026-04-16 11:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik,
netdev, linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S. Miller, sparclinux
In-Reply-To: <20260410120317.910770161@kernel.org>
On Fri, 10 Apr 2026 at 14:18, Thomas Gleixner <tglx@kernel.org> wrote:
> This has been scheduled for removal more than a decade ago and the comments
> related to it have been dutifully ignored. The last dependencies are gone.
>
> Remove it along with various now empty asm/timex.h files.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> arch/m68k/include/asm/timex.h | 15 ---------------
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [patch 27/38] m68k: Select ARCH_HAS_RANDOM_ENTROPY
From: Geert Uytterhoeven @ 2026-04-16 11:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, linux-m68k, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.397219631@kernel.org>
On Fri, 10 Apr 2026 at 14:20, Thomas Gleixner <tglx@kernel.org> wrote:
> The only remaining usage of get_cycles() is to provide
> random_get_entropy().
>
> Switch m68k over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY and
> providing random_get_entropy() in asm/random.h.
>
> Remove asm/timex.h as it has no functionality anymore.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [patch 18/38] lib/tests: Replace get_cycles() with ktime_get()
From: Geert Uytterhoeven @ 2026-04-16 10:24 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Andrew Morton, Uladzislau Rezki, linux-mm, Arnd Bergmann,
x86, Lu Baolu, iommu, Michael Grzeschik, netdev, linux-wireless,
Herbert Xu, linux-crypto, Vlastimil Babka, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S. Miller, sparclinux
In-Reply-To: <20260410120318.794680738@kernel.org>
Hi Thomas,
On Fri, 10 Apr 2026 at 14:20, Thomas Gleixner <tglx@kernel.org> wrote:
> get_cycles() is the historical access to a fine grained time source, but it
> is a suboptimal choice for two reasons:
>
> - get_cycles() is not guaranteed to be supported and functional on all
> systems/platforms. If not supported or not functional it returns 0,
> which makes benchmarking moot.
>
> - get_cycles() returns the raw counter value of whatever the
> architecture platform provides. The original x86 Time Stamp Counter
> (TSC) was despite its name tied to the actual CPU core frequency.
> That's not longer the case. So the counter value is only meaningful
> when the CPU operates at the same frequency as the TSC or the value is
> adjusted to the actual CPU frequency. Other architectures and
> platforms provide similar disjunct counters via get_cycles(), so the
> result is operations per BOGO-cycles, which is not really meaningful.
>
> Use ktime_get() instead which provides nanosecond timestamps with the
> granularity of the underlying hardware counter, which is not different to
> the variety of get_cycles() implementations.
>
> This provides at least understandable metrics, i.e. operations/nanoseconds,
> and is available on all platforms. As with get_cycles() the result might
> have to be put into relation with the CPU operating frequency, but that's
> not any different.
>
> This is part of a larger effort to remove get_cycles() usage from
> non-architecture code.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Thanks for your patch!
> --- a/lib/interval_tree_test.c
> +++ b/lib/interval_tree_test.c
> @@ -65,13 +65,13 @@ static void init(void)
> static int basic_check(void)
> {
> int i, j;
> - cycles_t time1, time2, time;
> + ktime_t time1, time2, time;
>
> printk(KERN_ALERT "interval tree insert/remove");
>
> init();
>
> - time1 = get_cycles();
> + time1 = ktime_get();
>
> for (i = 0; i < perf_loops; i++) {
> for (j = 0; j < nnodes; j++)
> @@ -80,11 +80,11 @@ static int basic_check(void)
> interval_tree_remove(nodes + j, &root);
> }
>
> - time2 = get_cycles();
> + time2 = ktime_get();
> time = time2 - time1;
>
> time = div_u64(time, perf_loops);
> - printk(" -> %llu cycles\n", (unsigned long long)time);
> + printk(" -> %llu nsecs\n", (unsigned long long)time);
While cycles_t was unsigned long or long long, ktime_t is always s64,
so "%lld", and the cast can be dropped (everywhere).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox