* [PATCH 57/61] fscrypt: update format strings for u64 i_ino
From: Jeff Layton @ 2026-02-26 15:55 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, Jeff Layton
In-Reply-To: <20260226-iino-u64-v1-0-ccceff366db9@kernel.org>
Update format strings from %lu to %llu for inode->i_ino now that
i_ino is u64 instead of unsigned long.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/crypto/crypto.c | 2 +-
fs/crypto/hooks.c | 2 +-
fs/crypto/keysetup.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c
index 07f9cbfe3ea4115b8fcc881ae5154b3c3e898c04..570a2231c945a6c649cf8dc3b457f0b55657e0c3 100644
--- a/fs/crypto/crypto.c
+++ b/fs/crypto/crypto.c
@@ -365,7 +365,7 @@ void fscrypt_msg(const struct inode *inode, const char *level,
vaf.fmt = fmt;
vaf.va = &args;
if (inode && inode->i_ino)
- printk("%sfscrypt (%s, inode %lu): %pV\n",
+ printk("%sfscrypt (%s, inode %llu): %pV\n",
level, inode->i_sb->s_id, inode->i_ino, &vaf);
else if (inode)
printk("%sfscrypt (%s): %pV\n", level, inode->i_sb->s_id, &vaf);
diff --git a/fs/crypto/hooks.c b/fs/crypto/hooks.c
index b97de0d1430fd6ec764f4a758dffe00263496118..a7a8a3f581a0460537f5ff955bc8b5d30573a033 100644
--- a/fs/crypto/hooks.c
+++ b/fs/crypto/hooks.c
@@ -62,7 +62,7 @@ int fscrypt_file_open(struct inode *inode, struct file *filp)
dentry_parent = dget_parent(dentry);
if (!fscrypt_has_permitted_context(d_inode(dentry_parent), inode)) {
fscrypt_warn(inode,
- "Inconsistent encryption context (parent directory: %lu)",
+ "Inconsistent encryption context (parent directory: %llu)",
d_inode(dentry_parent)->i_ino);
err = -EPERM;
}
diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
index 40fa05688d3a1d4aa33d29e9508441faf4bca933..df58ca4a5e3cb1df94e2f08e3f3b093c33368993 100644
--- a/fs/crypto/keysetup.c
+++ b/fs/crypto/keysetup.c
@@ -91,7 +91,7 @@ select_encryption_mode(const union fscrypt_policy *policy,
if (S_ISDIR(inode->i_mode) || S_ISLNK(inode->i_mode))
return &fscrypt_modes[fscrypt_policy_fnames_mode(policy)];
- WARN_ONCE(1, "fscrypt: filesystem tried to load encryption info for inode %lu, which is not encryptable (file type %d)\n",
+ WARN_ONCE(1, "fscrypt: filesystem tried to load encryption info for inode %llu, which is not encryptable (file type %d)\n",
inode->i_ino, (inode->i_mode & S_IFMT));
return ERR_PTR(-EINVAL);
}
--
2.53.0
^ permalink raw reply related
* [PATCH 58/61] fsverity: update format string for u64 i_ino
From: Jeff Layton @ 2026-02-26 15:56 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, Jeff Layton
In-Reply-To: <20260226-iino-u64-v1-0-ccceff366db9@kernel.org>
Update format string from %lu to %llu for inode->i_ino now that
i_ino is u64 instead of unsigned long.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/verity/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/verity/init.c b/fs/verity/init.c
index d6520660858386d3b7d69b20a459dc27d8017a5f..3aa55dec88fc919792a2cb4be476f8481ef78a9e 100644
--- a/fs/verity/init.c
+++ b/fs/verity/init.c
@@ -50,7 +50,7 @@ void fsverity_msg(const struct inode *inode, const char *level,
vaf.fmt = fmt;
vaf.va = &args;
if (inode)
- printk("%sfs-verity (%s, inode %lu): %pV\n",
+ printk("%sfs-verity (%s, inode %llu): %pV\n",
level, inode->i_sb->s_id, inode->i_ino, &vaf);
else
printk("%sfs-verity: %pV\n", level, &vaf);
--
2.53.0
^ permalink raw reply related
* [PATCH 59/61] iomap: update format string for u64 i_ino
From: Jeff Layton @ 2026-02-26 15:56 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, Jeff Layton
In-Reply-To: <20260226-iino-u64-v1-0-ccceff366db9@kernel.org>
Update format string from %lu to %llu for inode->i_ino now that
i_ino is u64 instead of unsigned long.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/iomap/ioend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/iomap/ioend.c b/fs/iomap/ioend.c
index 4d1ef8a2cee90b91591d387f8e1c3f75350c1da0..94d9a3c77bd68581d752fef4c16b88e1cb5f88da 100644
--- a/fs/iomap/ioend.c
+++ b/fs/iomap/ioend.c
@@ -48,7 +48,7 @@ static u32 iomap_finish_ioend_buffered(struct iomap_ioend *ioend)
mapping_set_error(inode->i_mapping, ioend->io_error);
if (!bio_flagged(bio, BIO_QUIET)) {
pr_err_ratelimited(
-"%s: writeback error on inode %lu, offset %lld, sector %llu",
+"%s: writeback error on inode %llu, offset %lld, sector %llu",
inode->i_sb->s_id, inode->i_ino,
ioend->io_offset, ioend->io_sector);
}
--
2.53.0
^ permalink raw reply related
* [PATCH 60/61] net: update legacy protocol format strings for u64 i_ino
From: Jeff Layton @ 2026-02-26 15:56 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, Jeff Layton
In-Reply-To: <20260226-iino-u64-v1-0-ccceff366db9@kernel.org>
Update format strings from %ld to %lld and 0L literals to 0LL in
x25, netrom, and rose proc output, now that i_ino is u64 instead
of unsigned long.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
net/netrom/af_netrom.c | 4 ++--
net/rose/af_rose.c | 4 ++--
net/x25/x25_proc.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index b816c56124ab8b7e59689e612d36007bb11aacaa..c9f12ea75f2f8f941d9bc2f3167b91608448819d 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -1305,7 +1305,7 @@ static int nr_info_show(struct seq_file *seq, void *v)
seq_printf(seq, "%-9s ", ax2asc(buf, &nr->user_addr));
seq_printf(seq, "%-9s ", ax2asc(buf, &nr->dest_addr));
seq_printf(seq,
-"%-9s %-3s %02X/%02X %02X/%02X %2d %3d %3d %3d %3lu/%03lu %2lu/%02lu %3lu/%03lu %3lu/%03lu %2d/%02d %3d %5d %5d %ld\n",
+"%-9s %-3s %02X/%02X %02X/%02X %2d %3d %3d %3d %3lu/%03lu %2lu/%02lu %3lu/%03lu %3lu/%03lu %2d/%02d %3d %5d %5d %lld\n",
ax2asc(buf, &nr->source_addr),
devname,
nr->my_index,
@@ -1329,7 +1329,7 @@ static int nr_info_show(struct seq_file *seq, void *v)
nr->window,
sk_wmem_alloc_get(s),
sk_rmem_alloc_get(s),
- s->sk_socket ? SOCK_INODE(s->sk_socket)->i_ino : 0L);
+ s->sk_socket ? SOCK_INODE(s->sk_socket)->i_ino : 0LL);
bh_unlock_sock(s);
}
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 841d62481048def8d800779efb6e4ea8cbe419fe..bbecad799c60cd74c62f2b2a01909f03547a0d4f 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -1479,7 +1479,7 @@ static int rose_info_show(struct seq_file *seq, void *v)
callsign = ax2asc(buf, &rose->source_call);
seq_printf(seq,
- "%-10s %-9s %-5s %3.3X %05d %d %d %d %d %3lu %3lu %3lu %3lu %3lu %3lu/%03lu %5d %5d %ld\n",
+ "%-10s %-9s %-5s %3.3X %05d %d %d %d %d %3lu %3lu %3lu %3lu %3lu %3lu/%03lu %5d %5d %lld\n",
rose2asc(rsbuf, &rose->source_addr),
callsign,
devname,
@@ -1498,7 +1498,7 @@ static int rose_info_show(struct seq_file *seq, void *v)
rose->idle / (60 * HZ),
sk_wmem_alloc_get(s),
sk_rmem_alloc_get(s),
- s->sk_socket ? SOCK_INODE(s->sk_socket)->i_ino : 0L);
+ s->sk_socket ? SOCK_INODE(s->sk_socket)->i_ino : 0LL);
}
return 0;
diff --git a/net/x25/x25_proc.c b/net/x25/x25_proc.c
index 0412814a2295bba5e26f4c95697ef7b7ba5fb34f..697fdfef297826e2dc267b89e34fd6a54f862a3f 100644
--- a/net/x25/x25_proc.c
+++ b/net/x25/x25_proc.c
@@ -96,7 +96,7 @@ static int x25_seq_socket_show(struct seq_file *seq, void *v)
devname = x25->neighbour->dev->name;
seq_printf(seq, "%-10s %-10s %-5s %3.3X %d %d %d %d %3lu %3lu "
- "%3lu %3lu %3lu %5d %5d %ld\n",
+ "%3lu %3lu %3lu %5d %5d %lld\n",
!x25->dest_addr.x25_addr[0] ? "*" : x25->dest_addr.x25_addr,
!x25->source_addr.x25_addr[0] ? "*" : x25->source_addr.x25_addr,
devname, x25->lci & 0x0FFF, x25->state, x25->vs, x25->vr,
@@ -104,7 +104,7 @@ static int x25_seq_socket_show(struct seq_file *seq, void *v)
x25->t21 / HZ, x25->t22 / HZ, x25->t23 / HZ,
sk_wmem_alloc_get(s),
sk_rmem_alloc_get(s),
- s->sk_socket ? SOCK_INODE(s->sk_socket)->i_ino : 0L);
+ s->sk_socket ? SOCK_INODE(s->sk_socket)->i_ino : 0LL);
out:
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 61/61] vfs: update core format strings for u64 i_ino
From: Jeff Layton @ 2026-02-26 15:56 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, Jeff Layton
In-Reply-To: <20260226-iino-u64-v1-0-ccceff366db9@kernel.org>
Update format strings from %lu/%lx to %llu/%llx and 0UL literal to
0ULL in pipe, dcache, fserror, and eventpoll, now that i_ino is u64
instead of unsigned long.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/dcache.c | 4 ++--
fs/eventpoll.c | 2 +-
fs/fserror.c | 2 +-
fs/pipe.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 24f4f3acaa8cffd6f98124eec38c1a92d6c9fd8e..9e8425ecd88955c72027d21591b1d12c87e7e8aa 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1637,11 +1637,11 @@ static enum d_walk_ret umount_check(void *_data, struct dentry *dentry)
if (dentry == _data && dentry->d_lockref.count == 1)
return D_WALK_CONTINUE;
- WARN(1, "BUG: Dentry %p{i=%lx,n=%pd} "
+ WARN(1, "BUG: Dentry %p{i=%llx,n=%pd} "
" still in use (%d) [unmount of %s %s]\n",
dentry,
dentry->d_inode ?
- dentry->d_inode->i_ino : 0UL,
+ dentry->d_inode->i_ino : 0ULL,
dentry,
dentry->d_lockref.count,
dentry->d_sb->s_type->name,
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 5714e900567c499739bb205f43bb6bf73f7ebe54..4ccd4d2e31adf571f939d2e777123e40302e565f 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1080,7 +1080,7 @@ static void ep_show_fdinfo(struct seq_file *m, struct file *f)
struct inode *inode = file_inode(epi->ffd.file);
seq_printf(m, "tfd: %8d events: %8x data: %16llx "
- " pos:%lli ino:%lx sdev:%x\n",
+ " pos:%lli ino:%llx sdev:%x\n",
epi->ffd.fd, epi->event.events,
(long long)epi->event.data,
(long long)epi->ffd.file->f_pos,
diff --git a/fs/fserror.c b/fs/fserror.c
index 06ca86adab9b769dfb72ec58b9e51627abee5152..1e4d11fd9562fd158a23b64ca60e9b7e01719cb8 100644
--- a/fs/fserror.c
+++ b/fs/fserror.c
@@ -176,7 +176,7 @@ void fserror_report(struct super_block *sb, struct inode *inode,
lost:
if (inode)
pr_err_ratelimited(
- "%s: lost file I/O error report for ino %lu type %u pos 0x%llx len 0x%llx error %d",
+ "%s: lost file I/O error report for ino %llu type %u pos 0x%llx len 0x%llx error %d",
sb->s_id, inode->i_ino, type, pos, len, error);
else
pr_err_ratelimited(
diff --git a/fs/pipe.c b/fs/pipe.c
index b44a756c0b4165edc2801b2290bf35480245d7a6..9841648c9cf3e8e569cf6ba5c792624fe92396f5 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -873,7 +873,7 @@ static struct vfsmount *pipe_mnt __ro_after_init;
*/
static char *pipefs_dname(struct dentry *dentry, char *buffer, int buflen)
{
- return dynamic_dname(buffer, buflen, "pipe:[%lu]",
+ return dynamic_dname(buffer, buflen, "pipe:[%llu]",
d_inode(dentry)->i_ino);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 59/61] iomap: update format string for u64 i_ino
From: Darrick J. Wong @ 2026-02-26 16:21 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-59-ccceff366db9@kernel.org>
On Thu, Feb 26, 2026 at 10:56:01AM -0500, Jeff Layton wrote:
> Update format string from %lu to %llu for inode->i_ino now that
> i_ino is u64 instead of unsigned long.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Looks fine to me, though I'm a bit sad there's no xfs_inode::i_ino ->
inode::i_ino conversion patch... ;)
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> fs/iomap/ioend.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/iomap/ioend.c b/fs/iomap/ioend.c
> index 4d1ef8a2cee90b91591d387f8e1c3f75350c1da0..94d9a3c77bd68581d752fef4c16b88e1cb5f88da 100644
> --- a/fs/iomap/ioend.c
> +++ b/fs/iomap/ioend.c
> @@ -48,7 +48,7 @@ static u32 iomap_finish_ioend_buffered(struct iomap_ioend *ioend)
> mapping_set_error(inode->i_mapping, ioend->io_error);
> if (!bio_flagged(bio, BIO_QUIET)) {
> pr_err_ratelimited(
> -"%s: writeback error on inode %lu, offset %lld, sector %llu",
> +"%s: writeback error on inode %llu, offset %lld, sector %llu",
> inode->i_sb->s_id, inode->i_ino,
> ioend->io_offset, ioend->io_sector);
> }
>
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH 61/61] vfs: update core format strings for u64 i_ino
From: Darrick J. Wong @ 2026-02-26 16:22 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Martin Schiller,
linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-61-ccceff366db9@kernel.org>
On Thu, Feb 26, 2026 at 10:56:03AM -0500, Jeff Layton wrote:
> Update format strings from %lu/%lx to %llu/%llx and 0UL literal to
> 0ULL in pipe, dcache, fserror, and eventpoll, now that i_ino is u64
> instead of unsigned long.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Acked-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> fs/dcache.c | 4 ++--
> fs/eventpoll.c | 2 +-
> fs/fserror.c | 2 +-
> fs/pipe.c | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 24f4f3acaa8cffd6f98124eec38c1a92d6c9fd8e..9e8425ecd88955c72027d21591b1d12c87e7e8aa 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1637,11 +1637,11 @@ static enum d_walk_ret umount_check(void *_data, struct dentry *dentry)
> if (dentry == _data && dentry->d_lockref.count == 1)
> return D_WALK_CONTINUE;
>
> - WARN(1, "BUG: Dentry %p{i=%lx,n=%pd} "
> + WARN(1, "BUG: Dentry %p{i=%llx,n=%pd} "
> " still in use (%d) [unmount of %s %s]\n",
> dentry,
> dentry->d_inode ?
> - dentry->d_inode->i_ino : 0UL,
> + dentry->d_inode->i_ino : 0ULL,
> dentry,
> dentry->d_lockref.count,
> dentry->d_sb->s_type->name,
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index 5714e900567c499739bb205f43bb6bf73f7ebe54..4ccd4d2e31adf571f939d2e777123e40302e565f 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -1080,7 +1080,7 @@ static void ep_show_fdinfo(struct seq_file *m, struct file *f)
> struct inode *inode = file_inode(epi->ffd.file);
>
> seq_printf(m, "tfd: %8d events: %8x data: %16llx "
> - " pos:%lli ino:%lx sdev:%x\n",
> + " pos:%lli ino:%llx sdev:%x\n",
> epi->ffd.fd, epi->event.events,
> (long long)epi->event.data,
> (long long)epi->ffd.file->f_pos,
> diff --git a/fs/fserror.c b/fs/fserror.c
> index 06ca86adab9b769dfb72ec58b9e51627abee5152..1e4d11fd9562fd158a23b64ca60e9b7e01719cb8 100644
> --- a/fs/fserror.c
> +++ b/fs/fserror.c
> @@ -176,7 +176,7 @@ void fserror_report(struct super_block *sb, struct inode *inode,
> lost:
> if (inode)
> pr_err_ratelimited(
> - "%s: lost file I/O error report for ino %lu type %u pos 0x%llx len 0x%llx error %d",
> + "%s: lost file I/O error report for ino %llu type %u pos 0x%llx len 0x%llx error %d",
> sb->s_id, inode->i_ino, type, pos, len, error);
> else
> pr_err_ratelimited(
> diff --git a/fs/pipe.c b/fs/pipe.c
> index b44a756c0b4165edc2801b2290bf35480245d7a6..9841648c9cf3e8e569cf6ba5c792624fe92396f5 100644
> --- a/fs/pipe.c
> +++ b/fs/pipe.c
> @@ -873,7 +873,7 @@ static struct vfsmount *pipe_mnt __ro_after_init;
> */
> static char *pipefs_dname(struct dentry *dentry, char *buffer, int buflen)
> {
> - return dynamic_dname(buffer, buflen, "pipe:[%lu]",
> + return dynamic_dname(buffer, buflen, "pipe:[%llu]",
> d_inode(dentry)->i_ino);
> }
>
>
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH 38/61] jfs: update format strings for u64 i_ino
From: Dave Kleikamp @ 2026-02-26 16:30 UTC (permalink / raw)
To: Jeff Layton, Alexander Viro, Christian Brauner, Jan Kara,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Dan Williams,
Matthew Wilcox, Eric Biggers, Theodore Y. Ts'o, Muchun Song,
Oscar Salvador, David Hildenbrand, David Howells, Paulo Alcantara,
Andreas Dilger, Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust,
Anna Schumaker, Chuck Lever, NeilBrown, Olga Kornievskaia,
Dai Ngo, Tom Talpey, Steve French, Ronnie Sahlberg,
Shyam Prasad N, Bharath SM, Alexander Aring, Ryusuke Konishi,
Viacheslav Dubeyko, Eric Van Hensbergen, Latchesar Ionkov,
Dominique Martinet, Christian Schoenebeck, David Sterba,
Marc Dionne, Ian Kent, Luis de Bethencourt, Salah Triki,
Tigran A. Aivazian, Ilya Dryomov, Alex Markuze, Jan Harkes, coda,
Nicolas Pitre, Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Konstantin Komarov,
Mark Fasheh, Joel Becker, Joseph Qi, Mike Marshall,
Martin Brandenburg, Miklos Szeredi, Anders Larsen, Zhihao Cheng,
Damien Le Moal, Naohiro Aota, Johannes Thumshirn, John Johansen,
Paul Moore, James Morris, Serge E. Hallyn, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-38-ccceff366db9@kernel.org>
On 2/26/26 9:55AM, Jeff Layton wrote:
> Update format strings and local variable types in jfs for the
> i_ino type change from unsigned long to u64.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com>
> ---
> fs/jfs/inode.c | 2 +-
> fs/jfs/jfs_imap.c | 2 +-
> fs/jfs/jfs_metapage.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/jfs/inode.c b/fs/jfs/inode.c
> index 4709762713efc5f1c6199ccfd9ecefe933e13f67..c7914dbc91ed97e200edbd114e2d4c695b46fb7e 100644
> --- a/fs/jfs/inode.c
> +++ b/fs/jfs/inode.c
> @@ -64,7 +64,7 @@ struct inode *jfs_iget(struct super_block *sb, unsigned long ino)
> inode->i_op = &jfs_file_inode_operations;
> init_special_inode(inode, inode->i_mode, inode->i_rdev);
> } else {
> - printk(KERN_DEBUG "JFS: Invalid file type 0%04o for inode %lu.\n",
> + printk(KERN_DEBUG "JFS: Invalid file type 0%04o for inode %llu.\n",
> inode->i_mode, inode->i_ino);
> iget_failed(inode);
> return ERR_PTR(-EIO);
> diff --git a/fs/jfs/jfs_imap.c b/fs/jfs/jfs_imap.c
> index 294a67327c735fb9cbe074078ed72e872862d710..3d714fff09992173dfe6c9c74980f034ba4e1a72 100644
> --- a/fs/jfs/jfs_imap.c
> +++ b/fs/jfs/jfs_imap.c
> @@ -302,7 +302,7 @@ int diRead(struct inode *ip)
> unsigned long pageno;
> int rel_inode;
>
> - jfs_info("diRead: ino = %ld", ip->i_ino);
> + jfs_info("diRead: ino = %lld", ip->i_ino);
>
> ipimap = sbi->ipimap;
> JFS_IP(ip)->ipimap = ipimap;
> diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
> index 64c6eaa7f3f264ac7c6c71ad8dd0d59b63f15414..714dbf34b7ac17f82ee9ebec2f9a5b4c5e6f7356 100644
> --- a/fs/jfs/jfs_metapage.c
> +++ b/fs/jfs/jfs_metapage.c
> @@ -692,7 +692,7 @@ struct metapage *__get_metapage(struct inode *inode, unsigned long lblock,
> unsigned long page_index;
> unsigned long page_offset;
>
> - jfs_info("__get_metapage: ino = %ld, lblock = 0x%lx, abs=%d",
> + jfs_info("__get_metapage: ino = %lld, lblock = 0x%lx, abs=%d",
> inode->i_ino, lblock, absolute);
>
> l2bsize = inode->i_blkbits;
>
^ permalink raw reply
* Re: [PATCH 19/61] affs: update format strings for u64 i_ino
From: David Sterba @ 2026-02-26 16:49 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-19-ccceff366db9@kernel.org>
On Thu, Feb 26, 2026 at 10:55:21AM -0500, Jeff Layton wrote:
> Update format strings and local variable types in affs for the
> i_ino type change from unsigned long to u64.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Acked-by: David Sterba <dsterba@suse.com>
^ permalink raw reply
* Re: [PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64
From: Matthew Wilcox @ 2026-02-26 16:49 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Eric Biggers,
Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-0-ccceff366db9@kernel.org>
On Thu, Feb 26, 2026 at 10:55:02AM -0500, Jeff Layton wrote:
> The bulk of the changes are to format strings and tracepoints, since the
> kernel itself doesn't care that much about the i_ino field. The first
> patch changes some vfs function arguments, so check that one out
> carefully.
Why are the format strings all done as separate patches? Don't we get
bisection hazards by splitting it apart this way?
^ permalink raw reply
* Re: [PATCH 13/61] smb: store full 64-bit uniqueid in i_ino
From: Paulo Alcantara @ 2026-02-26 16:57 UTC (permalink / raw)
To: Jeff Layton, Alexander Viro, Christian Brauner, Jan Kara,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Dan Williams,
Matthew Wilcox, Eric Biggers, Theodore Y. Ts'o, Muchun Song,
Oscar Salvador, David Hildenbrand, David Howells, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, Jeff Layton
In-Reply-To: <20260226-iino-u64-v1-13-ccceff366db9@kernel.org>
Jeff Layton <jlayton@kernel.org> writes:
> With i_ino now u64, CIFS/SMB can store the full 64-bit uniqueid in
> i_ino without the XOR-folding hack previously needed on 32-bit
> architectures.
>
> - Simplify cifs_uniqueid_to_ino_t() to return u64 directly
> - Update hash variable type in cifs_get_inode_info()
> - Update format strings from %lu to %llu
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/smb/client/cifsfs.h | 12 +++---------
> fs/smb/client/inode.c | 4 ++--
> 2 files changed, 5 insertions(+), 11 deletions(-)
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
^ permalink raw reply
* Re: [PATCH 14/61] smb: remove cifs_uniqueid_to_ino_t()
From: Paulo Alcantara @ 2026-02-26 16:58 UTC (permalink / raw)
To: Jeff Layton, Alexander Viro, Christian Brauner, Jan Kara,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Dan Williams,
Matthew Wilcox, Eric Biggers, Theodore Y. Ts'o, Muchun Song,
Oscar Salvador, David Hildenbrand, David Howells, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, Jeff Layton
In-Reply-To: <20260226-iino-u64-v1-14-ccceff366db9@kernel.org>
Jeff Layton <jlayton@kernel.org> writes:
> Now that i_ino is u64, cifs_uniqueid_to_ino_t() is a trivial identity
> function. Remove it and use fattr->cf_uniqueid directly at both call
> sites.
>
> Also remove the now-unused #include <linux/hash.h>, which was only
> needed for the old XOR-folding logic.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/smb/client/cifsfs.h | 11 -----------
> fs/smb/client/inode.c | 2 +-
> fs/smb/client/readdir.c | 2 +-
> 3 files changed, 2 insertions(+), 13 deletions(-)
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
^ permalink raw reply
* Re: IMA and PQC
From: Eric Biggers @ 2026-02-26 16:58 UTC (permalink / raw)
To: Simo Sorce
Cc: Stefan Berger, Coiby Xu, Johannes Wiesböck, dhowells,
dmitry.kasatkin, eric.snowberg, keyrings, linux-crypto,
linux-integrity, linux-kernel, linux-modules, roberto.sassu,
zohar, michael.weiss
In-Reply-To: <da190dbbc692b9da8464bbbfffdde7bab26b3f1c.camel@redhat.com>
On Thu, Feb 26, 2026 at 10:27:43AM -0500, Simo Sorce wrote:
> On Thu, 2026-02-26 at 09:16 -0500, Stefan Berger wrote:
> > On 2/26/26 7:42 AM, Stefan Berger wrote:
> > > On 2/25/26 7:10 PM, Eric Biggers wrote:
> > > > On Wed, Feb 25, 2026 at 09:25:43AM -0500, Stefan Berger wrote:
> > > > > To avoid duplicate work: Is either one of you planning on writing
> > > > > patches
> > > > > for IMA to use ML-DSA and convert the current ML-DSA to also support
> > > > > HashML?
> > > > > I had done the work on this before and could dig out the patches
> > > > > again...
> > > >
> > > > IMA already had to add its own digest prefixing support, since it was
> > > > needed to disambiguate between full-file digests and fsverity digests.
> > > > See 'struct ima_file_id'. Thus the message signed is at most 66 bytes.
> > >
> > > The hash there is still only a hash over a file and that hash is signed,
> > > isn't it?
> > >
> > > >
> > > > With that being the case, HashML-DSA isn't necessary. It's not even
> > > > possible to use here, since there are no OIDs assigned for the fsverity
> > > > digests, so it cannot replace the ima_file_id.
> > >
> > > For non-fsverify IMA signatures it is 'possible' to use HashML-DSA and
> > > it's 'working' (recycled old patches yesterday):
> > >
> > > Linux: https://github.com/stefanberger/linux/commits/
> > > dhmlsa%2Bima.202602025/
> > >
> > > ima-evm-utils: https://github.com/linux-integrity/ima-evm-utils/pull/19/
> > > commits
> > >
> > > >
> > > > I'll also note that HashML-DSA is controversial (e.g. see
> > > > https://keymaterial.net/2024/11/05/hashml-dsa-considered-harmful/),
> > >
> > > The problem with this is that NIST would have to react to these
> > > controversies as we race to support PQC. If something is wrong with the
> > > standard then it would be best for NIST to withdraw/modify HashML-DSA
> > > asap. Otherwise it's the best to follow the standard IMO because if you
> > > don't you get criticism otherwise.
> >
> > What I am not clear about from FIPS-204 is whether availability of
> > HashML-DSA is a "must-use" or a "may-use". What speaks against it for
> > our use case is performance. The lookup of a hash's ID (last digit of
> > OID) and the creation of the 11 byte encoding to prepend before every
> > digest for every signature takes cycles.
>
> It is a recommendation, but there are plenty of protocols (TLS,
> OpenPGP, etc...) where the decision has been made to use "pure" ML-DSA
> only, even if what you are signing is not the full data, but something
> containing a hash.
>
> Ideally you do not sign *just* a hash, but some structured data, like a
> context label that identifies the hash and some other related metadata
> for example. In order to make forgeries much harder should the hashing
> algorithm used to hash the data weaken over time. But it is not
> strictly necessary (NIST mentioned in some forum, sorry I do not have
> the message handy for quoting, that a structured packet is perfectly
> fine for use with pure ML-DSA, because it does enough to address the
> same issues that a separate internal context does with HashML-DSA).
>
> If pure-ML-DSA works better for IMA, just use pure ML-DSA.
>
> > Maybe it should explicitly state in FIPS-204 something along the lines
> > of "with a given hash either ML-DSA or HashML-DSA can be used (for as
> > long as you use it in the same way from then on)." At least this way
> > nobody can point out that HashML-DSA should have been used when you didn't.
>
> NIST will not change the standard documents any time soon, but for FIPS
> certification there are Implementation Guidelines.
>
> In any case a FIPS module cannot distinguish between data that happens
> to be 32 bytes long and a hash of larger data, so the point is kind of
> moot. From the FIPS perspective HashML-DSA is just an available
> algorithm that protocol implementations can use, or not.
>
> There are additional guidelines on what this may be useful for, but so
> far NIST has not objected to the use of pure ML-DSA even where
> theoretically HashML-DSA could be used.
I see that IMA indeed never upgraded full file hashes to use
'struct ima_file_id'. Building a new feature that relies on this seems
like a bad idea though, given that it's a security bug that makes the
IMA protocol cryptographically ambiguous. I.e., it means that in IMA,
when the contents of some file are signed, that signature is sometimes
also valid for some other file contents which the signer didn't intend.
Just fix that bug first, which has to be done anyway. Then just use
pure ML-DSA to sign and verify the 'struct ima_file_id'.
As Simo mentioned, FIPS 204 doesn't require HashML-DSA when signing a
hash. It's there as an *option* to solve a perceived problem, which is
actually solvable in better ways.
NIST doesn't plan to update FIPS 204 until 2029, and most likely the
updates will just be errata in the text (such as the ones I reported to
them), not changes or withdrawals in the algorithms themselves. But
it's irrelevant: just because HashML-DSA is an option doesn't mean it
has to be used. Pure ML-DSA supports arbitrary data, which includes
formatted hashes which allow for pre-hashing perfectly well.
- Eric
^ permalink raw reply
* Re: [PATCH 01/61] vfs: widen inode hash/lookup functions to u64
From: Jan Kara @ 2026-02-26 17:00 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-1-ccceff366db9@kernel.org>
On Thu 26-02-26 10:55:03, Jeff Layton wrote:
> Change the inode hash/lookup VFS API functions to accept u64 parameters
> instead of unsigned long for inode numbers and hash values. This is
> preparation for widening i_ino itself to u64, which will allow
> filesystems to store full 64-bit inode numbers on 32-bit architectures.
>
> Since unsigned long implicitly widens to u64 on all architectures, this
> change is backward-compatible with all existing callers.
>
> Functions updated:
> - hash(), find_inode_fast(), find_inode_by_ino_rcu(), test_inode_iunique()
> - __insert_inode_hash(), iget_locked(), iget5_locked(), iget5_locked_rcu()
> - ilookup(), ilookup5(), ilookup5_nowait()
> - find_inode_nowait(), find_inode_rcu()
> - inode_insert5(), insert_inode_locked4()
> - insert_inode_locked() (local variable)
> - dump_mapping() (local variable and format string)
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Looks good. Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/inode.c | 46 +++++++++++++++++++++++-----------------------
> include/linux/fs.h | 26 +++++++++++++-------------
> 2 files changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/fs/inode.c b/fs/inode.c
> index cc12b68e021b2c97cc88a46ddc736334ecb8edfa..2cabec9043e8176d20aecc5ce7e0f276c114f122 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -672,7 +672,7 @@ static inline void inode_sb_list_del(struct inode *inode)
> }
> }
>
> -static unsigned long hash(struct super_block *sb, unsigned long hashval)
> +static unsigned long hash(struct super_block *sb, u64 hashval)
> {
> unsigned long tmp;
>
> @@ -685,12 +685,12 @@ static unsigned long hash(struct super_block *sb, unsigned long hashval)
> /**
> * __insert_inode_hash - hash an inode
> * @inode: unhashed inode
> - * @hashval: unsigned long value used to locate this object in the
> + * @hashval: u64 value used to locate this object in the
> * inode_hashtable.
> *
> * Add an inode to the inode hash for this superblock.
> */
> -void __insert_inode_hash(struct inode *inode, unsigned long hashval)
> +void __insert_inode_hash(struct inode *inode, u64 hashval)
> {
> struct hlist_head *b = inode_hashtable + hash(inode->i_sb, hashval);
>
> @@ -726,7 +726,7 @@ void dump_mapping(const struct address_space *mapping)
> struct dentry *dentry_ptr;
> struct dentry dentry;
> char fname[64] = {};
> - unsigned long ino;
> + u64 ino;
>
> /*
> * If mapping is an invalid pointer, we don't want to crash
> @@ -750,14 +750,14 @@ void dump_mapping(const struct address_space *mapping)
> }
>
> if (!dentry_first) {
> - pr_warn("aops:%ps ino:%lx\n", a_ops, ino);
> + pr_warn("aops:%ps ino:%llx\n", a_ops, ino);
> return;
> }
>
> dentry_ptr = container_of(dentry_first, struct dentry, d_u.d_alias);
> if (get_kernel_nofault(dentry, dentry_ptr) ||
> !dentry.d_parent || !dentry.d_name.name) {
> - pr_warn("aops:%ps ino:%lx invalid dentry:%px\n",
> + pr_warn("aops:%ps ino:%llx invalid dentry:%px\n",
> a_ops, ino, dentry_ptr);
> return;
> }
> @@ -768,7 +768,7 @@ void dump_mapping(const struct address_space *mapping)
> * Even if strncpy_from_kernel_nofault() succeeded,
> * the fname could be unreliable
> */
> - pr_warn("aops:%ps ino:%lx dentry name(?):\"%s\"\n",
> + pr_warn("aops:%ps ino:%llx dentry name(?):\"%s\"\n",
> a_ops, ino, fname);
> }
>
> @@ -1087,7 +1087,7 @@ static struct inode *find_inode(struct super_block *sb,
> * iget_locked for details.
> */
> static struct inode *find_inode_fast(struct super_block *sb,
> - struct hlist_head *head, unsigned long ino,
> + struct hlist_head *head, u64 ino,
> bool hash_locked, bool *isnew)
> {
> struct inode *inode = NULL;
> @@ -1301,7 +1301,7 @@ EXPORT_SYMBOL(unlock_two_nondirectories);
> * Note that both @test and @set are called with the inode_hash_lock held, so
> * they can't sleep.
> */
> -struct inode *inode_insert5(struct inode *inode, unsigned long hashval,
> +struct inode *inode_insert5(struct inode *inode, u64 hashval,
> int (*test)(struct inode *, void *),
> int (*set)(struct inode *, void *), void *data)
> {
> @@ -1378,7 +1378,7 @@ EXPORT_SYMBOL(inode_insert5);
> * Note that both @test and @set are called with the inode_hash_lock held, so
> * they can't sleep.
> */
> -struct inode *iget5_locked(struct super_block *sb, unsigned long hashval,
> +struct inode *iget5_locked(struct super_block *sb, u64 hashval,
> int (*test)(struct inode *, void *),
> int (*set)(struct inode *, void *), void *data)
> {
> @@ -1408,7 +1408,7 @@ EXPORT_SYMBOL(iget5_locked);
> * This is equivalent to iget5_locked, except the @test callback must
> * tolerate the inode not being stable, including being mid-teardown.
> */
> -struct inode *iget5_locked_rcu(struct super_block *sb, unsigned long hashval,
> +struct inode *iget5_locked_rcu(struct super_block *sb, u64 hashval,
> int (*test)(struct inode *, void *),
> int (*set)(struct inode *, void *), void *data)
> {
> @@ -1455,7 +1455,7 @@ EXPORT_SYMBOL_GPL(iget5_locked_rcu);
> * hashed, and with the I_NEW flag set. The file system gets to fill it in
> * before unlocking it via unlock_new_inode().
> */
> -struct inode *iget_locked(struct super_block *sb, unsigned long ino)
> +struct inode *iget_locked(struct super_block *sb, u64 ino)
> {
> struct hlist_head *head = inode_hashtable + hash(sb, ino);
> struct inode *inode;
> @@ -1527,7 +1527,7 @@ EXPORT_SYMBOL(iget_locked);
> *
> * Returns 1 if the inode number is unique, 0 if it is not.
> */
> -static int test_inode_iunique(struct super_block *sb, unsigned long ino)
> +static int test_inode_iunique(struct super_block *sb, u64 ino)
> {
> struct hlist_head *b = inode_hashtable + hash(sb, ino);
> struct inode *inode;
> @@ -1616,7 +1616,7 @@ EXPORT_SYMBOL(igrab);
> *
> * Note2: @test is called with the inode_hash_lock held, so can't sleep.
> */
> -struct inode *ilookup5_nowait(struct super_block *sb, unsigned long hashval,
> +struct inode *ilookup5_nowait(struct super_block *sb, u64 hashval,
> int (*test)(struct inode *, void *), void *data, bool *isnew)
> {
> struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> @@ -1647,7 +1647,7 @@ EXPORT_SYMBOL(ilookup5_nowait);
> *
> * Note: @test is called with the inode_hash_lock held, so can't sleep.
> */
> -struct inode *ilookup5(struct super_block *sb, unsigned long hashval,
> +struct inode *ilookup5(struct super_block *sb, u64 hashval,
> int (*test)(struct inode *, void *), void *data)
> {
> struct inode *inode;
> @@ -1677,7 +1677,7 @@ EXPORT_SYMBOL(ilookup5);
> * Search for the inode @ino in the inode cache, and if the inode is in the
> * cache, the inode is returned with an incremented reference count.
> */
> -struct inode *ilookup(struct super_block *sb, unsigned long ino)
> +struct inode *ilookup(struct super_block *sb, u64 ino)
> {
> struct hlist_head *head = inode_hashtable + hash(sb, ino);
> struct inode *inode;
> @@ -1726,8 +1726,8 @@ EXPORT_SYMBOL(ilookup);
> * very carefully implemented.
> */
> struct inode *find_inode_nowait(struct super_block *sb,
> - unsigned long hashval,
> - int (*match)(struct inode *, unsigned long,
> + u64 hashval,
> + int (*match)(struct inode *, u64,
> void *),
> void *data)
> {
> @@ -1773,7 +1773,7 @@ EXPORT_SYMBOL(find_inode_nowait);
> *
> * The caller must hold the RCU read lock.
> */
> -struct inode *find_inode_rcu(struct super_block *sb, unsigned long hashval,
> +struct inode *find_inode_rcu(struct super_block *sb, u64 hashval,
> int (*test)(struct inode *, void *), void *data)
> {
> struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> @@ -1812,7 +1812,7 @@ EXPORT_SYMBOL(find_inode_rcu);
> * The caller must hold the RCU read lock.
> */
> struct inode *find_inode_by_ino_rcu(struct super_block *sb,
> - unsigned long ino)
> + u64 ino)
> {
> struct hlist_head *head = inode_hashtable + hash(sb, ino);
> struct inode *inode;
> @@ -1833,7 +1833,7 @@ EXPORT_SYMBOL(find_inode_by_ino_rcu);
> int insert_inode_locked(struct inode *inode)
> {
> struct super_block *sb = inode->i_sb;
> - ino_t ino = inode->i_ino;
> + u64 ino = inode->i_ino;
> struct hlist_head *head = inode_hashtable + hash(sb, ino);
> bool isnew;
>
> @@ -1884,7 +1884,7 @@ int insert_inode_locked(struct inode *inode)
> }
> EXPORT_SYMBOL(insert_inode_locked);
>
> -int insert_inode_locked4(struct inode *inode, unsigned long hashval,
> +int insert_inode_locked4(struct inode *inode, u64 hashval,
> int (*test)(struct inode *, void *), void *data)
> {
> struct inode *old;
> @@ -2642,7 +2642,7 @@ void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)
> break;
> default:
> printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o) for"
> - " inode %s:%lu\n", mode, inode->i_sb->s_id,
> + " inode %s:%llu\n", mode, inode->i_sb->s_id,
> inode->i_ino);
> break;
> }
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8b3dd145b25ec12b00ac1df17a952d9116b88047..dfa1f475b1c480c503ab6f00e891aa9b051607fa 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2935,32 +2935,32 @@ static inline int inode_generic_drop(struct inode *inode)
> extern void d_mark_dontcache(struct inode *inode);
>
> extern struct inode *ilookup5_nowait(struct super_block *sb,
> - unsigned long hashval, int (*test)(struct inode *, void *),
> + u64 hashval, int (*test)(struct inode *, void *),
> void *data, bool *isnew);
> -extern struct inode *ilookup5(struct super_block *sb, unsigned long hashval,
> +extern struct inode *ilookup5(struct super_block *sb, u64 hashval,
> int (*test)(struct inode *, void *), void *data);
> -extern struct inode *ilookup(struct super_block *sb, unsigned long ino);
> +extern struct inode *ilookup(struct super_block *sb, u64 ino);
>
> -extern struct inode *inode_insert5(struct inode *inode, unsigned long hashval,
> +extern struct inode *inode_insert5(struct inode *inode, u64 hashval,
> int (*test)(struct inode *, void *),
> int (*set)(struct inode *, void *),
> void *data);
> -struct inode *iget5_locked(struct super_block *, unsigned long,
> +struct inode *iget5_locked(struct super_block *, u64,
> int (*test)(struct inode *, void *),
> int (*set)(struct inode *, void *), void *);
> -struct inode *iget5_locked_rcu(struct super_block *, unsigned long,
> +struct inode *iget5_locked_rcu(struct super_block *, u64,
> int (*test)(struct inode *, void *),
> int (*set)(struct inode *, void *), void *);
> -extern struct inode * iget_locked(struct super_block *, unsigned long);
> +extern struct inode *iget_locked(struct super_block *, u64);
> extern struct inode *find_inode_nowait(struct super_block *,
> - unsigned long,
> + u64,
> int (*match)(struct inode *,
> - unsigned long, void *),
> + u64, void *),
> void *data);
> -extern struct inode *find_inode_rcu(struct super_block *, unsigned long,
> +extern struct inode *find_inode_rcu(struct super_block *, u64,
> int (*)(struct inode *, void *), void *);
> -extern struct inode *find_inode_by_ino_rcu(struct super_block *, unsigned long);
> -extern int insert_inode_locked4(struct inode *, unsigned long, int (*test)(struct inode *, void *), void *);
> +extern struct inode *find_inode_by_ino_rcu(struct super_block *, u64);
> +extern int insert_inode_locked4(struct inode *, u64, int (*test)(struct inode *, void *), void *);
> extern int insert_inode_locked(struct inode *);
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> extern void lockdep_annotate_inode_mutex_key(struct inode *inode);
> @@ -3015,7 +3015,7 @@ int setattr_should_drop_sgid(struct mnt_idmap *idmap,
> */
> #define alloc_inode_sb(_sb, _cache, _gfp) kmem_cache_alloc_lru(_cache, &_sb->s_inode_lru, _gfp)
>
> -extern void __insert_inode_hash(struct inode *, unsigned long hashval);
> +extern void __insert_inode_hash(struct inode *, u64 hashval);
> static inline void insert_inode_hash(struct inode *inode)
> {
> __insert_inode_hash(inode, inode->i_ino);
>
> --
> 2.53.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64
From: Jeff Layton @ 2026-02-26 17:01 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Eric Biggers,
Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <aaB5lgKd8FOIizPg@casper.infradead.org>
On Thu, 2026-02-26 at 16:49 +0000, Matthew Wilcox wrote:
> On Thu, Feb 26, 2026 at 10:55:02AM -0500, Jeff Layton wrote:
> > The bulk of the changes are to format strings and tracepoints, since the
> > kernel itself doesn't care that much about the i_ino field. The first
> > patch changes some vfs function arguments, so check that one out
> > carefully.
>
> Why are the format strings all done as separate patches? Don't we get
> bisection hazards by splitting it apart this way?
One big patch would be Yuuuuge. We could certainly do it that way, but
it'll be nightmare if we ever do have to revert part of it. What do you
suggest?
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH 03/61] trace: update VFS-layer trace events for u64 i_ino
From: Jan Kara @ 2026-02-26 17:11 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-3-ccceff366db9@kernel.org>
On Thu 26-02-26 10:55:05, Jeff Layton wrote:
> Update trace event definitions in VFS-layer trace headers to use u64
> instead of ino_t/unsigned long for inode number fields, and change
> format strings from %lu/%lx to %llu/%llx to match.
>
> This is needed because i_ino is now u64. Changing trace event field
> types changes the binary trace format, but the self-describing format
> metadata handles this transparently for modern trace-cmd and perf.
>
> Files updated:
> - cachefiles.h, filelock.h, filemap.h, fs_dax.h, fsverity.h,
> hugetlbfs.h, netfs.h, readahead.h, timestamp.h, writeback.h
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
...
> diff --git a/include/trace/events/writeback.h b/include/trace/events/writeback.h
> index 4d3d8c8f3a1bc3e5ef10fc96e3c6dbbd0cf00c98..cc7651749eb3ce1123cb3ea9496f0803a0f4c1a0 100644
> --- a/include/trace/events/writeback.h
> +++ b/include/trace/events/writeback.h
> @@ -67,7 +67,7 @@ DECLARE_EVENT_CLASS(writeback_folio_template,
>
> TP_STRUCT__entry (
> __array(char, name, 32)
> - __field(ino_t, ino)
> + __field(u64, ino)
> __field(pgoff_t, index)
> ),
>
> @@ -79,9 +79,9 @@ DECLARE_EVENT_CLASS(writeback_folio_template,
> __entry->index = folio->index;
> ),
>
> - TP_printk("bdi %s: ino=%lu index=%lu",
> + TP_printk("bdi %s: ino=%llu index=%lu",
> __entry->name,
> - (unsigned long)__entry->ino,
> + (unsigned long long)__entry->ino,
No need for explicit typing to ULL?
> __entry->index
> )
> );
> @@ -108,7 +108,7 @@ DECLARE_EVENT_CLASS(writeback_dirty_inode_template,
>
> TP_STRUCT__entry (
> __array(char, name, 32)
> - __field(ino_t, ino)
> + __field(u64, ino)
> __field(unsigned long, state)
> __field(unsigned long, flags)
> ),
> @@ -123,9 +123,9 @@ DECLARE_EVENT_CLASS(writeback_dirty_inode_template,
> __entry->flags = flags;
> ),
>
> - TP_printk("bdi %s: ino=%lu state=%s flags=%s",
> + TP_printk("bdi %s: ino=%llu state=%s flags=%s",
> __entry->name,
> - (unsigned long)__entry->ino,
> + (unsigned long long)__entry->ino,
And here as well? And many times below as well...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH 57/61] fscrypt: update format strings for u64 i_ino
From: Eric Biggers @ 2026-02-26 17:10 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-57-ccceff366db9@kernel.org>
On Thu, Feb 26, 2026 at 10:55:59AM -0500, Jeff Layton wrote:
> Update format strings from %lu to %llu for inode->i_ino now that
> i_ino is u64 instead of unsigned long.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/crypto/crypto.c | 2 +-
> fs/crypto/hooks.c | 2 +-
> fs/crypto/keysetup.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
check_for_busy_inodes() needs to be updated too. It copies i_ino to a
local variable of type 'unsigned long', then prints it with %lu.
Seems that there needs to be a search for other code that copies i_ino
to a local variable, as this issue is unlikely to be unique to here.
- Eric
^ permalink raw reply
* Re: [PATCH 01/61] vfs: widen inode hash/lookup functions to u64
From: Jan Kara @ 2026-02-26 17:14 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <cmxf6pu3xuwvbhg3alu725hd4b3dheowoumd6drolde7pypwor@eplss6764uuf>
On Thu 26-02-26 18:00:36, Jan Kara wrote:
> On Thu 26-02-26 10:55:03, Jeff Layton wrote:
> > Change the inode hash/lookup VFS API functions to accept u64 parameters
> > instead of unsigned long for inode numbers and hash values. This is
> > preparation for widening i_ino itself to u64, which will allow
> > filesystems to store full 64-bit inode numbers on 32-bit architectures.
> >
> > Since unsigned long implicitly widens to u64 on all architectures, this
> > change is backward-compatible with all existing callers.
> >
> > Functions updated:
> > - hash(), find_inode_fast(), find_inode_by_ino_rcu(), test_inode_iunique()
> > - __insert_inode_hash(), iget_locked(), iget5_locked(), iget5_locked_rcu()
> > - ilookup(), ilookup5(), ilookup5_nowait()
> > - find_inode_nowait(), find_inode_rcu()
> > - inode_insert5(), insert_inode_locked4()
> > - insert_inode_locked() (local variable)
> > - dump_mapping() (local variable and format string)
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
>
> Looks good. Feel free to add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
Thinking some more about this (and also seeing the discussion about patch
2) - maybe instead of using explicit u64 we should typedef kino_t as u64
and use that?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: IMA and PQC
From: Stefan Berger @ 2026-02-26 17:22 UTC (permalink / raw)
To: Eric Biggers, Simo Sorce
Cc: Coiby Xu, Johannes Wiesböck, dhowells, dmitry.kasatkin,
eric.snowberg, keyrings, linux-crypto, linux-integrity,
linux-kernel, linux-modules, roberto.sassu, zohar, michael.weiss
In-Reply-To: <20260226165819.GA2251@sol>
On 2/26/26 11:58 AM, Eric Biggers wrote:
> On Thu, Feb 26, 2026 at 10:27:43AM -0500, Simo Sorce wrote:
>> On Thu, 2026-02-26 at 09:16 -0500, Stefan Berger wrote:
>>> On 2/26/26 7:42 AM, Stefan Berger wrote:
>>>> On 2/25/26 7:10 PM, Eric Biggers wrote:
>>>>> On Wed, Feb 25, 2026 at 09:25:43AM -0500, Stefan Berger wrote:
>>>>>> To avoid duplicate work: Is either one of you planning on writing
>>>>>> patches
>>>>>> for IMA to use ML-DSA and convert the current ML-DSA to also support
>>>>>> HashML?
>>>>>> I had done the work on this before and could dig out the patches
>>>>>> again...
>>>>>
>>>>> IMA already had to add its own digest prefixing support, since it was
>>>>> needed to disambiguate between full-file digests and fsverity digests.
>>>>> See 'struct ima_file_id'. Thus the message signed is at most 66 bytes.
>>>>
>>>> The hash there is still only a hash over a file and that hash is signed,
>>>> isn't it?
>>>>
>>>>>
>>>>> With that being the case, HashML-DSA isn't necessary. It's not even
>>>>> possible to use here, since there are no OIDs assigned for the fsverity
>>>>> digests, so it cannot replace the ima_file_id.
>>>>
>>>> For non-fsverify IMA signatures it is 'possible' to use HashML-DSA and
>>>> it's 'working' (recycled old patches yesterday):
>>>>
>>>> Linux: https://github.com/stefanberger/linux/commits/
>>>> dhmlsa%2Bima.202602025/
>>>>
>>>> ima-evm-utils: https://github.com/linux-integrity/ima-evm-utils/pull/19/
>>>> commits
>>>>
>>>>>
>>>>> I'll also note that HashML-DSA is controversial (e.g. see
>>>>> https://keymaterial.net/2024/11/05/hashml-dsa-considered-harmful/),
>>>>
>>>> The problem with this is that NIST would have to react to these
>>>> controversies as we race to support PQC. If something is wrong with the
>>>> standard then it would be best for NIST to withdraw/modify HashML-DSA
>>>> asap. Otherwise it's the best to follow the standard IMO because if you
>>>> don't you get criticism otherwise.
>>>
>>> What I am not clear about from FIPS-204 is whether availability of
>>> HashML-DSA is a "must-use" or a "may-use". What speaks against it for
>>> our use case is performance. The lookup of a hash's ID (last digit of
>>> OID) and the creation of the 11 byte encoding to prepend before every
>>> digest for every signature takes cycles.
>>
>> It is a recommendation, but there are plenty of protocols (TLS,
>> OpenPGP, etc...) where the decision has been made to use "pure" ML-DSA
>> only, even if what you are signing is not the full data, but something
>> containing a hash.
>>
>> Ideally you do not sign *just* a hash, but some structured data, like a
>> context label that identifies the hash and some other related metadata
>> for example. In order to make forgeries much harder should the hashing
>> algorithm used to hash the data weaken over time. But it is not
>> strictly necessary (NIST mentioned in some forum, sorry I do not have
>> the message handy for quoting, that a structured packet is perfectly
>> fine for use with pure ML-DSA, because it does enough to address the
>> same issues that a separate internal context does with HashML-DSA).
>>
>> If pure-ML-DSA works better for IMA, just use pure ML-DSA.
>>
>>> Maybe it should explicitly state in FIPS-204 something along the lines
>>> of "with a given hash either ML-DSA or HashML-DSA can be used (for as
>>> long as you use it in the same way from then on)." At least this way
>>> nobody can point out that HashML-DSA should have been used when you didn't.
>>
>> NIST will not change the standard documents any time soon, but for FIPS
>> certification there are Implementation Guidelines.
>>
>> In any case a FIPS module cannot distinguish between data that happens
>> to be 32 bytes long and a hash of larger data, so the point is kind of
>> moot. From the FIPS perspective HashML-DSA is just an available
>> algorithm that protocol implementations can use, or not.
>>
>> There are additional guidelines on what this may be useful for, but so
>> far NIST has not objected to the use of pure ML-DSA even where
>> theoretically HashML-DSA could be used.
>
> I see that IMA indeed never upgraded full file hashes to use
> 'struct ima_file_id'. Building a new feature that relies on this seems
> like a bad idea though, given that it's a security bug that makes
the> IMA protocol cryptographically ambiguous. I.e., it means that in IMA,
> when the contents of some file are signed, that signature is sometimes
> also valid for some other file contents which the signer didn't intend.
You mean IMA should not sign the digest in the ima_file_id structure but
hash the ima_file_id structure in which this file digest is written into
(that we currently sign) and sign/verify this digest? And we would do
this to avoid two different files (with presumably different content)
from having the same hashes leading to the same signature? Which hashes
(besides the non-recommended ones) are so weak now that you must not
merely sign a file's hash?
The problem with this is that older kernels (without patching) won't be
able to handle newer signatures.
>
> Just fix that bug first, which has to be done anyway. Then just use
> pure ML-DSA to sign and verify the 'struct ima_file_id'.
> > As Simo mentioned, FIPS 204 doesn't require HashML-DSA when signing a
> hash. It's there as an *option* to solve a perceived problem, which is
> actually solvable in better ways.
>
> NIST doesn't plan to update FIPS 204 until 2029, and most likely the
> updates will just be errata in the text (such as the ones I reported to
> them), not changes or withdrawals in the algorithms themselves. But
> it's irrelevant: just because HashML-DSA is an option doesn't mean it
> has to be used. Pure ML-DSA supports arbitrary data, which includes
And I was sure whether it was merely an 'option'. Who would use it then
if it takes more cycles to hash the prepended 11 byte oid in HashML-DSA?
> formatted hashes which allow for pre-hashing perfectly well.
>
> - Eric
^ permalink raw reply
* Re: [PATCH 03/61] trace: update VFS-layer trace events for u64 i_ino
From: Steven Rostedt @ 2026-02-26 17:48 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Matthew Wilcox, Eric Biggers,
Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-3-ccceff366db9@kernel.org>
On Thu, 26 Feb 2026 10:55:05 -0500
Jeff Layton <jlayton@kernel.org> wrote:
> Update trace event definitions in VFS-layer trace headers to use u64
> instead of ino_t/unsigned long for inode number fields, and change
> format strings from %lu/%lx to %llu/%llx to match.
>
> This is needed because i_ino is now u64. Changing trace event field
> types changes the binary trace format, but the self-describing format
> metadata handles this transparently for modern trace-cmd and perf.
>
> Files updated:
> - cachefiles.h, filelock.h, filemap.h, fs_dax.h, fsverity.h,
> hugetlbfs.h, netfs.h, readahead.h, timestamp.h, writeback.h
>
Hmm, on 32 bit systems, this will likely cause "holes" in a lot of these
events.
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> include/trace/events/cachefiles.h | 18 ++---
> include/trace/events/filelock.h | 16 ++---
> include/trace/events/filemap.h | 20 +++---
> include/trace/events/fs_dax.h | 20 +++---
> include/trace/events/fsverity.h | 30 ++++----
> include/trace/events/hugetlbfs.h | 28 ++++----
> include/trace/events/netfs.h | 4 +-
> include/trace/events/readahead.h | 12 ++--
> include/trace/events/timestamp.h | 12 ++--
> include/trace/events/writeback.h | 148 +++++++++++++++++++-------------------
> 10 files changed, 154 insertions(+), 154 deletions(-)
>
> diff --git a/include/trace/events/cachefiles.h b/include/trace/events/cachefiles.h
> index a743b2a35ea7001447b3e05d41539cb88013bc7f..f967027711ee823f224abc1b8ab03f63da06ae6f 100644
> --- a/include/trace/events/cachefiles.h
> +++ b/include/trace/events/cachefiles.h
> @@ -251,8 +251,8 @@ TRACE_EVENT(cachefiles_lookup,
> TP_STRUCT__entry(
> __field(unsigned int, obj)
> __field(short, error)
There was already a 2 byte hole here, but that's not a big deal.
> - __field(unsigned long, dino)
> - __field(unsigned long, ino)
> + __field(u64, dino)
> + __field(u64, ino)
> ),
>
> TP_fast_assign(
> @@ -263,7 +263,7 @@ TRACE_EVENT(cachefiles_lookup,
> __entry->error = IS_ERR(de) ? PTR_ERR(de) : 0;
> ),
>
> - TP_printk("o=%08x dB=%lx B=%lx e=%d",
> + TP_printk("o=%08x dB=%llx B=%llx e=%d",
> __entry->obj, __entry->dino, __entry->ino, __entry->error)
> );
>
> @@ -579,7 +579,7 @@ TRACE_EVENT(cachefiles_mark_active,
> /* Note that obj may be NULL */
> TP_STRUCT__entry(
> __field(unsigned int, obj)
> - __field(ino_t, inode)
> + __field(u64, inode)
Might be better to reorder any of these that have int first.
u64 inode;
int obj;
Will be packed tighter than:
int obj
u64 inode;
Probably should have changed that before anyway.
> ),
>
> TP_fast_assign(
> @@ -587,7 +587,7 @@ TRACE_EVENT(cachefiles_mark_active,
> __entry->inode = inode->i_ino;
> ),
>
> - TP_printk("o=%08x B=%lx",
> + TP_printk("o=%08x B=%llx",
> __entry->obj, __entry->inode)
> );
>
> @@ -600,7 +600,7 @@ TRACE_EVENT(cachefiles_mark_failed,
> /* Note that obj may be NULL */
> TP_STRUCT__entry(
> __field(unsigned int, obj)
> - __field(ino_t, inode)
> + __field(u64, inode)
Is ino_t being changed? Why the update here?
> ),
>
> TP_fast_assign(
> @@ -608,7 +608,7 @@ TRACE_EVENT(cachefiles_mark_failed,
> __entry->inode = inode->i_ino;
> ),
>
> - TP_printk("o=%08x B=%lx",
> + TP_printk("o=%08x B=%llx",
> __entry->obj, __entry->inode)
> );
>
> @@ -621,7 +621,7 @@ TRACE_EVENT(cachefiles_mark_inactive,
> /* Note that obj may be NULL */
> TP_STRUCT__entry(
> __field(unsigned int, obj)
> - __field(ino_t, inode)
> + __field(u64, inode)
Ditto.
> ),
>
> TP_fast_assign(
> @@ -629,7 +629,7 @@ TRACE_EVENT(cachefiles_mark_inactive,
> __entry->inode = inode->i_ino;
> ),
>
> - TP_printk("o=%08x B=%lx",
> + TP_printk("o=%08x B=%llx",
> __entry->obj, __entry->inode)
> );
>
> diff --git a/include/trace/events/filelock.h b/include/trace/events/filelock.h
> index 370016c38a5bbc07d5ba6c102030b49c9eb6424d..41bc752616b25d6cd7955203e2c604029d0b440c 100644
> --- a/include/trace/events/filelock.h
> +++ b/include/trace/events/filelock.h
> @@ -42,7 +42,7 @@ TRACE_EVENT(locks_get_lock_context,
> TP_ARGS(inode, type, ctx),
>
> TP_STRUCT__entry(
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
> __field(dev_t, s_dev)
> __field(unsigned char, type)
> __field(struct file_lock_context *, ctx)
> @@ -55,7 +55,7 @@ TRACE_EVENT(locks_get_lock_context,
> __entry->ctx = ctx;
> ),
>
> - TP_printk("dev=0x%x:0x%x ino=0x%lx type=%s ctx=%p",
> + TP_printk("dev=0x%x:0x%x ino=0x%llx type=%s ctx=%p",
> MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> __entry->i_ino, show_fl_type(__entry->type), __entry->ctx)
> );
> @@ -67,7 +67,7 @@ DECLARE_EVENT_CLASS(filelock_lock,
>
> TP_STRUCT__entry(
> __field(struct file_lock *, fl)
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
Having u64 before a pointer would be tighter on 32 bit systems, and leaves
out any holes in the trace.
> __field(dev_t, s_dev)
> __field(struct file_lock_core *, blocker)
> __field(fl_owner_t, owner)
> @@ -93,7 +93,7 @@ DECLARE_EVENT_CLASS(filelock_lock,
> __entry->ret = ret;
> ),
>
> - TP_printk("fl=%p dev=0x%x:0x%x ino=0x%lx fl_blocker=%p fl_owner=%p fl_pid=%u fl_flags=%s fl_type=%s fl_start=%lld fl_end=%lld ret=%d",
> + TP_printk("fl=%p dev=0x%x:0x%x ino=0x%llx fl_blocker=%p fl_owner=%p fl_pid=%u fl_flags=%s fl_type=%s fl_start=%lld fl_end=%lld ret=%d",
> __entry->fl, MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> __entry->i_ino, __entry->blocker, __entry->owner,
> __entry->pid, show_fl_flags(__entry->flags),
> @@ -124,7 +124,7 @@ DECLARE_EVENT_CLASS(filelock_lease,
>
> TP_STRUCT__entry(
> __field(struct file_lease *, fl)
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
Same here.
> __field(dev_t, s_dev)
> __field(struct file_lock_core *, blocker)
> __field(fl_owner_t, owner)
> @@ -146,7 +146,7 @@ DECLARE_EVENT_CLASS(filelock_lease,
> __entry->downgrade_time = fl ? fl->fl_downgrade_time : 0;
> ),
>
> - TP_printk("fl=%p dev=0x%x:0x%x ino=0x%lx fl_blocker=%p fl_owner=%p fl_flags=%s fl_type=%s fl_break_time=%lu fl_downgrade_time=%lu",
> + TP_printk("fl=%p dev=0x%x:0x%x ino=0x%llx fl_blocker=%p fl_owner=%p fl_flags=%s fl_type=%s fl_break_time=%lu fl_downgrade_time=%lu",
> __entry->fl, MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> __entry->i_ino, __entry->blocker, __entry->owner,
> show_fl_flags(__entry->flags),
> @@ -175,7 +175,7 @@ TRACE_EVENT(generic_add_lease,
> TP_ARGS(inode, fl),
>
> TP_STRUCT__entry(
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
> __field(int, wcount)
> __field(int, rcount)
> __field(int, icount)
> @@ -196,7 +196,7 @@ TRACE_EVENT(generic_add_lease,
> __entry->type = fl->c.flc_type;
> ),
>
> - TP_printk("dev=0x%x:0x%x ino=0x%lx wcount=%d rcount=%d icount=%d fl_owner=%p fl_flags=%s fl_type=%s",
> + TP_printk("dev=0x%x:0x%x ino=0x%llx wcount=%d rcount=%d icount=%d fl_owner=%p fl_flags=%s fl_type=%s",
> MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> __entry->i_ino, __entry->wcount, __entry->rcount,
> __entry->icount, __entry->owner,
> diff --git a/include/trace/events/filemap.h b/include/trace/events/filemap.h
> index f48fe637bfd25885dc6daaf09336ab60626b4944..153491e57cce6df73e30ddee60a52ed7d8923c24 100644
> --- a/include/trace/events/filemap.h
> +++ b/include/trace/events/filemap.h
> @@ -21,7 +21,7 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
>
> TP_STRUCT__entry(
> __field(unsigned long, pfn)
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
Again, this would cause a 32 bit hole.
> __field(unsigned long, index)
> __field(dev_t, s_dev)
> __field(unsigned char, order)
> @@ -38,7 +38,7 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
> __entry->order = folio_order(folio);
> ),
>
> - TP_printk("dev %d:%d ino %lx pfn=0x%lx ofs=%lu order=%u",
> + TP_printk("dev %d:%d ino %llx pfn=0x%lx ofs=%lu order=%u",
> MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> __entry->i_ino,
> __entry->pfn,
> @@ -67,7 +67,7 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache_range,
> TP_ARGS(mapping, index, last_index),
>
> TP_STRUCT__entry(
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
> __field(dev_t, s_dev)
> __field(unsigned long, index)
> __field(unsigned long, last_index)
> @@ -85,7 +85,7 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache_range,
> ),
>
> TP_printk(
> - "dev=%d:%d ino=%lx ofs=%lld-%lld",
> + "dev=%d:%d ino=%llx ofs=%lld-%lld",
> MAJOR(__entry->s_dev),
> MINOR(__entry->s_dev), __entry->i_ino,
> ((loff_t)__entry->index) << PAGE_SHIFT,
> @@ -117,7 +117,7 @@ TRACE_EVENT(mm_filemap_fault,
> TP_ARGS(mapping, index),
>
> TP_STRUCT__entry(
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
> __field(dev_t, s_dev)
> __field(unsigned long, index)
> ),
> @@ -133,7 +133,7 @@ TRACE_EVENT(mm_filemap_fault,
> ),
>
> TP_printk(
> - "dev=%d:%d ino=%lx ofs=%lld",
> + "dev=%d:%d ino=%llx ofs=%lld",
> MAJOR(__entry->s_dev),
> MINOR(__entry->s_dev), __entry->i_ino,
> ((loff_t)__entry->index) << PAGE_SHIFT
> @@ -146,7 +146,7 @@ TRACE_EVENT(filemap_set_wb_err,
> TP_ARGS(mapping, eseq),
>
> TP_STRUCT__entry(
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
> __field(dev_t, s_dev)
> __field(errseq_t, errseq)
> ),
> @@ -160,7 +160,7 @@ TRACE_EVENT(filemap_set_wb_err,
> __entry->s_dev = mapping->host->i_rdev;
> ),
>
> - TP_printk("dev=%d:%d ino=0x%lx errseq=0x%x",
> + TP_printk("dev=%d:%d ino=0x%llx errseq=0x%x",
> MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> __entry->i_ino, __entry->errseq)
> );
> @@ -172,7 +172,7 @@ TRACE_EVENT(file_check_and_advance_wb_err,
>
> TP_STRUCT__entry(
> __field(struct file *, file)
> - __field(unsigned long, i_ino)
> + __field(u64, i_ino)
Having a pointer after the u64 is better.
> __field(dev_t, s_dev)
> __field(errseq_t, old)
> __field(errseq_t, new)
> @@ -191,7 +191,7 @@ TRACE_EVENT(file_check_and_advance_wb_err,
> __entry->new = file->f_wb_err;
> ),
>
> - TP_printk("file=%p dev=%d:%d ino=0x%lx old=0x%x new=0x%x",
> + TP_printk("file=%p dev=%d:%d ino=0x%llx old=0x%x new=0x%x",
> __entry->file, MAJOR(__entry->s_dev),
> MINOR(__entry->s_dev), __entry->i_ino, __entry->old,
> __entry->new)
> diff --git a/include/trace/events/fs_dax.h b/include/trace/events/fs_dax.h
> index 50ebc1290ab062a9c30ab00049fb96691f9a0f23..11121baa8ece7928c653b4f874fb10ffbdd02fd0 100644
> --- a/include/trace/events/fs_dax.h
> +++ b/include/trace/events/fs_dax.h
> @@ -12,7 +12,7 @@ DECLARE_EVENT_CLASS(dax_pmd_fault_class,
> pgoff_t max_pgoff, int result),
> TP_ARGS(inode, vmf, max_pgoff, result),
> TP_STRUCT__entry(
> - __field(unsigned long, ino)
> + __field(u64, ino)
> __field(unsigned long, vm_start)
> __field(unsigned long, vm_end)
> __field(vm_flags_t, vm_flags)
> @@ -35,7 +35,7 @@ DECLARE_EVENT_CLASS(dax_pmd_fault_class,
> __entry->max_pgoff = max_pgoff;
> __entry->result = result;
> ),
> - TP_printk("dev %d:%d ino %#lx %s %s address %#lx vm_start "
> + TP_printk("dev %d:%d ino %#llx %s %s address %#lx vm_start "
> "%#lx vm_end %#lx pgoff %#lx max_pgoff %#lx %s",
> MAJOR(__entry->dev),
> MINOR(__entry->dev),
> @@ -66,7 +66,7 @@ DECLARE_EVENT_CLASS(dax_pmd_load_hole_class,
> void *radix_entry),
> TP_ARGS(inode, vmf, zero_folio, radix_entry),
> TP_STRUCT__entry(
> - __field(unsigned long, ino)
> + __field(u64, ino)
> __field(vm_flags_t, vm_flags)
> __field(unsigned long, address)
> __field(struct folio *, zero_folio)
> @@ -81,7 +81,7 @@ DECLARE_EVENT_CLASS(dax_pmd_load_hole_class,
> __entry->zero_folio = zero_folio;
> __entry->radix_entry = radix_entry;
> ),
> - TP_printk("dev %d:%d ino %#lx %s address %#lx zero_folio %p "
> + TP_printk("dev %d:%d ino %#llx %s address %#lx zero_folio %p "
> "radix_entry %#lx",
> MAJOR(__entry->dev),
> MINOR(__entry->dev),
> @@ -106,7 +106,7 @@ DECLARE_EVENT_CLASS(dax_pte_fault_class,
> TP_PROTO(struct inode *inode, struct vm_fault *vmf, int result),
> TP_ARGS(inode, vmf, result),
> TP_STRUCT__entry(
> - __field(unsigned long, ino)
> + __field(u64, ino)
> __field(vm_flags_t, vm_flags)
> __field(unsigned long, address)
> __field(pgoff_t, pgoff)
> @@ -123,7 +123,7 @@ DECLARE_EVENT_CLASS(dax_pte_fault_class,
> __entry->pgoff = vmf->pgoff;
> __entry->result = result;
> ),
> - TP_printk("dev %d:%d ino %#lx %s %s address %#lx pgoff %#lx %s",
> + TP_printk("dev %d:%d ino %#llx %s %s address %#lx pgoff %#lx %s",
> MAJOR(__entry->dev),
> MINOR(__entry->dev),
> __entry->ino,
> @@ -150,7 +150,7 @@ DECLARE_EVENT_CLASS(dax_writeback_range_class,
> TP_PROTO(struct inode *inode, pgoff_t start_index, pgoff_t end_index),
> TP_ARGS(inode, start_index, end_index),
> TP_STRUCT__entry(
> - __field(unsigned long, ino)
> + __field(u64, ino)
> __field(pgoff_t, start_index)
> __field(pgoff_t, end_index)
> __field(dev_t, dev)
> @@ -161,7 +161,7 @@ DECLARE_EVENT_CLASS(dax_writeback_range_class,
> __entry->start_index = start_index;
> __entry->end_index = end_index;
> ),
> - TP_printk("dev %d:%d ino %#lx pgoff %#lx-%#lx",
> + TP_printk("dev %d:%d ino %#llx pgoff %#lx-%#lx",
> MAJOR(__entry->dev),
> MINOR(__entry->dev),
> __entry->ino,
> @@ -182,7 +182,7 @@ TRACE_EVENT(dax_writeback_one,
> TP_PROTO(struct inode *inode, pgoff_t pgoff, pgoff_t pglen),
> TP_ARGS(inode, pgoff, pglen),
> TP_STRUCT__entry(
> - __field(unsigned long, ino)
> + __field(u64, ino)
> __field(pgoff_t, pgoff)
> __field(pgoff_t, pglen)
> __field(dev_t, dev)
> @@ -193,7 +193,7 @@ TRACE_EVENT(dax_writeback_one,
> __entry->pgoff = pgoff;
> __entry->pglen = pglen;
> ),
> - TP_printk("dev %d:%d ino %#lx pgoff %#lx pglen %#lx",
> + TP_printk("dev %d:%d ino %#llx pgoff %#lx pglen %#lx",
> MAJOR(__entry->dev),
> MINOR(__entry->dev),
> __entry->ino,
> diff --git a/include/trace/events/fsverity.h b/include/trace/events/fsverity.h
> index a8c52f21cbd5eb010c7e7b2fdb8f9de49c8ea326..4477c17e05748360965c4e1840590efe96d6335e 100644
> --- a/include/trace/events/fsverity.h
> +++ b/include/trace/events/fsverity.h
> @@ -16,7 +16,7 @@ TRACE_EVENT(fsverity_enable,
> const struct merkle_tree_params *params),
> TP_ARGS(inode, params),
> TP_STRUCT__entry(
> - __field(ino_t, ino)
> + __field(u64, ino)
Do you need to convert all these ino_t's?
> __field(u64, data_size)
> __field(u64, tree_size)
> __field(unsigned int, merkle_block)
> @@ -29,8 +29,8 @@ TRACE_EVENT(fsverity_enable,
> __entry->merkle_block = params->block_size;
> __entry->num_levels = params->num_levels;
> ),
> - TP_printk("ino %lu data_size %llu tree_size %llu merkle_block %u levels %u",
> - (unsigned long) __entry->ino,
> + TP_printk("ino %llu data_size %llu tree_size %llu merkle_block %u levels %u",
> + __entry->ino,
> __entry->data_size,
> __entry->tree_size,
> __entry->merkle_block,
> @@ -42,7 +42,7 @@ TRACE_EVENT(fsverity_tree_done,
> const struct merkle_tree_params *params),
> TP_ARGS(inode, vi, params),
> TP_STRUCT__entry(
> - __field(ino_t, ino)
> + __field(u64, ino)
> __field(u64, data_size)
> __field(u64, tree_size)
> __field(unsigned int, merkle_block)
> @@ -59,8 +59,8 @@ TRACE_EVENT(fsverity_tree_done,
> memcpy(__get_dynamic_array(root_hash), vi->root_hash, __get_dynamic_array_len(root_hash));
> memcpy(__get_dynamic_array(file_digest), vi->file_digest, __get_dynamic_array_len(file_digest));
> ),
> - TP_printk("ino %lu data_size %llu tree_size %lld merkle_block %u levels %u root_hash %s digest %s",
> - (unsigned long) __entry->ino,
> + TP_printk("ino %llu data_size %llu tree_size %lld merkle_block %u levels %u root_hash %s digest %s",
> + __entry->ino,
> __entry->data_size,
> __entry->tree_size,
> __entry->merkle_block,
> @@ -75,7 +75,7 @@ TRACE_EVENT(fsverity_verify_data_block,
> u64 data_pos),
> TP_ARGS(inode, params, data_pos),
> TP_STRUCT__entry(
> - __field(ino_t, ino)
> + __field(u64, ino)
> __field(u64, data_pos)
> __field(unsigned int, merkle_block)
> ),
> @@ -84,8 +84,8 @@ TRACE_EVENT(fsverity_verify_data_block,
> __entry->data_pos = data_pos;
> __entry->merkle_block = params->block_size;
> ),
> - TP_printk("ino %lu data_pos %llu merkle_block %u",
> - (unsigned long) __entry->ino,
> + TP_printk("ino %llu data_pos %llu merkle_block %u",
> + __entry->ino,
> __entry->data_pos,
> __entry->merkle_block)
> );
> @@ -96,7 +96,7 @@ TRACE_EVENT(fsverity_merkle_hit,
> unsigned int hidx),
> TP_ARGS(inode, data_pos, hblock_idx, level, hidx),
> TP_STRUCT__entry(
> - __field(ino_t, ino)
> + __field(u64, ino)
> __field(u64, data_pos)
Heh, this actually removed a hole, but again, why convert ino_t?
Anyway, I stopped here. But you get the idea.
-- Steve
> __field(unsigned long, hblock_idx)
> __field(unsigned int, level)
^ permalink raw reply
* Re: [PATCH 03/61] trace: update VFS-layer trace events for u64 i_ino
From: Jeff Layton @ 2026-02-26 17:53 UTC (permalink / raw)
To: Jan Kara
Cc: Alexander Viro, Christian Brauner, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <6exhq5gjvef5obfsqwkxfcpl2sjqmlv7klrzolodzpcjolgrmd@ds42ulhod7pw>
On Thu, 2026-02-26 at 18:11 +0100, Jan Kara wrote:
> On Thu 26-02-26 10:55:05, Jeff Layton wrote:
> > Update trace event definitions in VFS-layer trace headers to use u64
> > instead of ino_t/unsigned long for inode number fields, and change
> > format strings from %lu/%lx to %llu/%llx to match.
> >
> > This is needed because i_ino is now u64. Changing trace event field
> > types changes the binary trace format, but the self-describing format
> > metadata handles this transparently for modern trace-cmd and perf.
> >
> > Files updated:
> > - cachefiles.h, filelock.h, filemap.h, fs_dax.h, fsverity.h,
> > hugetlbfs.h, netfs.h, readahead.h, timestamp.h, writeback.h
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
>
> ...
>
> > diff --git a/include/trace/events/writeback.h b/include/trace/events/writeback.h
> > index 4d3d8c8f3a1bc3e5ef10fc96e3c6dbbd0cf00c98..cc7651749eb3ce1123cb3ea9496f0803a0f4c1a0 100644
> > --- a/include/trace/events/writeback.h
> > +++ b/include/trace/events/writeback.h
> > @@ -67,7 +67,7 @@ DECLARE_EVENT_CLASS(writeback_folio_template,
> >
> > TP_STRUCT__entry (
> > __array(char, name, 32)
> > - __field(ino_t, ino)
> > + __field(u64, ino)
> > __field(pgoff_t, index)
> > ),
> >
> > @@ -79,9 +79,9 @@ DECLARE_EVENT_CLASS(writeback_folio_template,
> > __entry->index = folio->index;
> > ),
> >
> > - TP_printk("bdi %s: ino=%lu index=%lu",
> > + TP_printk("bdi %s: ino=%llu index=%lu",
> > __entry->name,
> > - (unsigned long)__entry->ino,
> > + (unsigned long long)__entry->ino,
>
> No need for explicit typing to ULL?
>
> > __entry->index
> > )
> > );
> > @@ -108,7 +108,7 @@ DECLARE_EVENT_CLASS(writeback_dirty_inode_template,
> >
> > TP_STRUCT__entry (
> > __array(char, name, 32)
> > - __field(ino_t, ino)
> > + __field(u64, ino)
> > __field(unsigned long, state)
> > __field(unsigned long, flags)
> > ),
> > @@ -123,9 +123,9 @@ DECLARE_EVENT_CLASS(writeback_dirty_inode_template,
> > __entry->flags = flags;
> > ),
> >
> > - TP_printk("bdi %s: ino=%lu state=%s flags=%s",
> > + TP_printk("bdi %s: ino=%llu state=%s flags=%s",
> > __entry->name,
> > - (unsigned long)__entry->ino,
> > + (unsigned long long)__entry->ino,
>
> And here as well? And many times below as well...
>
> Honza
Good catch. I'll clean those up.
Thanks,
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH 28/61] ecryptfs: update format strings for u64 i_ino
From: Tyler Hicks @ 2026-02-26 18:21 UTC (permalink / raw)
To: Jeff Layton
Cc: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Dan Williams, Matthew Wilcox,
Eric Biggers, Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Amir Goldstein, Christoph Hellwig, John Paul Adrian Glaubitz,
Yangtao Li, Mikulas Patocka, David Woodhouse, Richard Weinberger,
Dave Kleikamp, Konstantin Komarov, Mark Fasheh, Joel Becker,
Joseph Qi, Mike Marshall, Martin Brandenburg, Miklos Szeredi,
Anders Larsen, Zhihao Cheng, Damien Le Moal, Naohiro Aota,
Johannes Thumshirn, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Fan Wu, Stephen Smalley, Ondrej Mosnacek,
Casey Schaufler, Alex Deucher, Christian König, David Airlie,
Simona Vetter, Sumit Semwal, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, David S. Miller, Jakub Kicinski,
Simon Horman, Oleg Nesterov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Darrick J. Wong, Martin Schiller, linux-fsdevel,
linux-kernel, linux-trace-kernel, nvdimm, fsverity, linux-mm,
netfs, linux-ext4, linux-f2fs-devel, linux-nfs, linux-cifs,
samba-technical, linux-nilfs, v9fs, linux-afs, autofs, ceph-devel,
codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3, ocfs2-devel,
devel, linux-unionfs, apparmor, linux-security-module,
linux-integrity, selinux, amd-gfx, dri-devel, linux-media,
linaro-mm-sig, netdev, linux-perf-users, linux-fscrypt, linux-xfs,
linux-hams, linux-x25
In-Reply-To: <20260226-iino-u64-v1-28-ccceff366db9@kernel.org>
On 2026-02-26 10:55:30, Jeff Layton wrote:
> Update format strings and local variable types in ecryptfs for the
> i_ino type change from unsigned long to u64.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Acked-by: Tyler Hicks <code@tyhicks.com>
Tyler
> ---
> fs/ecryptfs/crypto.c | 6 +++---
> fs/ecryptfs/file.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index 3b59346d68c594fcd7e27bae87849d3e19eff56e..f25c9a49e251a591695a143f64d1a81c5211ec18 100644
> --- a/fs/ecryptfs/crypto.c
> +++ b/fs/ecryptfs/crypto.c
> @@ -1313,7 +1313,7 @@ int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
> rc = ecryptfs_read_xattr_region(page_virt, ecryptfs_inode);
> if (rc) {
> printk(KERN_DEBUG "Valid eCryptfs headers not found in "
> - "file header region or xattr region, inode %lu\n",
> + "file header region or xattr region, inode %llu\n",
> ecryptfs_inode->i_ino);
> rc = -EINVAL;
> goto out;
> @@ -1323,7 +1323,7 @@ int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
> ECRYPTFS_DONT_VALIDATE_HEADER_SIZE);
> if (rc) {
> printk(KERN_DEBUG "Valid eCryptfs headers not found in "
> - "file xattr region either, inode %lu\n",
> + "file xattr region either, inode %llu\n",
> ecryptfs_inode->i_ino);
> rc = -EINVAL;
> }
> @@ -1335,7 +1335,7 @@ int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
> "crypto metadata only in the extended attribute "
> "region, but eCryptfs was mounted without "
> "xattr support enabled. eCryptfs will not treat "
> - "this like an encrypted file, inode %lu\n",
> + "this like an encrypted file, inode %llu\n",
> ecryptfs_inode->i_ino);
> rc = -EINVAL;
> }
> diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c
> index 7929411837cf5b2e98e1d4288791d2e07c44a4eb..49b0fbe0428a2d202434ce4b5fd7d82d2a63cf58 100644
> --- a/fs/ecryptfs/file.c
> +++ b/fs/ecryptfs/file.c
> @@ -253,7 +253,7 @@ static int ecryptfs_open(struct inode *inode, struct file *file)
> if (rc)
> goto out_put;
> ecryptfs_printk(KERN_DEBUG, "inode w/ addr = [0x%p], i_ino = "
> - "[0x%.16lx] size: [0x%.16llx]\n", inode, inode->i_ino,
> + "[0x%.16llx] size: [0x%.16llx]\n", inode, inode->i_ino,
> (unsigned long long)i_size_read(inode));
> goto out;
> out_put:
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v15 00/28] x86: Secure Launch support for Intel TXT
From: ross.philipson @ 2026-02-26 18:31 UTC (permalink / raw)
To: Ard Biesheuvel, Daniel P. Smith, linux-kernel, x86,
linux-integrity, linux-doc, linux-crypto, kexec, linux-efi, iommu,
dave.hansen, H . Peter Anvin
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, mjg59,
James.Bottomley, peterhuewe, Jarkko Sakkinen, jgg, luto, nivedita,
Herbert Xu, davem, corbet, ebiederm, dwmw2, baolu.lu,
kanth.ghatraju, andrew.cooper3, trenchboot-devel
In-Reply-To: <242a0462-7fc5-4902-b71d-22cf8360239e@app.fastmail.com>
On 2/18/26 9:30 AM, 'Ard Biesheuvel' via trenchboot-devel wrote:
> On Thu, 12 Feb 2026, at 21:39, Ard Biesheuvel wrote:
>> On Thu, 12 Feb 2026, at 20:49, Daniel P. Smith wrote:
>>> On 2/9/26 09:04, Ard Biesheuvel wrote:
>> ...
>>>> I've had a stab at implementing all of this in a manner that is more idiomatic for EFI boot:
>>>>
>>>> - GRUB does minimal TXT related preparation upfront, and exposes the remaining functionality via a protocol that is attached to the loaded image by GRUB
>>>> - The SL stub is moved to the core kernel, with some startup code added to pivot to long mode
>>>> - the EFI stub executes and decompresses the kernel as usual
>>>> - if the protocol is present, the EFI stub calls it to pass the bootparams pointer, the base and size of the MLE and the header offset back to the GRUB code
>>>> - after calling ExitBootServices(), it calls another protocol method to trigger the secure launch.
>>>>
>> ...
>>>
>>> I think this is a great approach for UEFI, though we need to reconcile
>>> this with non-UEFI situations such as booting under coreboot.
>>
>> There are two approaches that I think are feasible for coreboot in this model:
>>
>> - just unpack the ELF and boot that - there is already prior art for
>> that with Xen. We can stick the MLE header offset in an ELF note where
>> any loader can find it.
>>
>> - stick with the current approach as much as possible, i.e., disable
>> physical KASLR so that the decompressed kernel will end up right where
>> the decompressor was loaded, which allows much of the secure launch
>> preparation to be done as before. Only the final bits (including the
>> call into the ACM itself) need to be deferred, and we can propose a
>> generic mechanism for that via boot_params.
>>
>> I'm working on a prototype of the latter, but GRUB is an odd beast and
>> my x86 fu is weak.
>>
>
> I've managed to get a working implementation of the legacy entrypoint, by repurposing the dl_handler() entrypoint you added for EFI [which no longer needs it in my version] as a callback for the legacy boot flow. This /should/ work for i386-coreboot too, but I have no way of testing it (I only tried 'slaunch --legacy-linux' using the x86_64-efi build).
>
> I've pushed the changes to the branches I mentioned previously in this thread.
Hello Ard,
I am working on incorporating the changes we have been discussing. So far everything has been rather smooth. I noticed in the legacy support you did here, you introduce a new boot_param. This is something that we tried to do early on but changes to the boot_params layout is rather frowned upon. We worked with Peter A. on the kernel_info scheme but this parameter you introduced is not used that way (kernel_info is meant to be RO after the kernel is built). I guess my first questions are whether this will be an acceptable approach (per the x86 maintainers) to add a boot_param and, if so, whether the spot you chose is reasonable. E.g. will it survive the sanitize boot params step.
Thanks
Ross
>
>
>
>
>
^ permalink raw reply
* Re: IMA and PQC
From: Eric Biggers @ 2026-02-26 18:32 UTC (permalink / raw)
To: Stefan Berger
Cc: Simo Sorce, Coiby Xu, Johannes Wiesböck, dhowells,
dmitry.kasatkin, eric.snowberg, keyrings, linux-crypto,
linux-integrity, linux-kernel, linux-modules, roberto.sassu,
zohar, michael.weiss
In-Reply-To: <969c74f3-81ed-442c-87dd-381274a642a7@linux.ibm.com>
On Thu, Feb 26, 2026 at 12:22:32PM -0500, Stefan Berger wrote:
> > I see that IMA indeed never upgraded full file hashes to use
> > 'struct ima_file_id'. Building a new feature that relies on this seems
> > like a bad idea though, given that it's a security bug that makes the> IMA
> protocol cryptographically ambiguous. I.e., it means that in IMA,
> > when the contents of some file are signed, that signature is sometimes
> > also valid for some other file contents which the signer didn't intend.
>
> You mean IMA should not sign the digest in the ima_file_id structure but
> hash the ima_file_id structure in which this file digest is written into
> (that we currently sign) and sign/verify this digest? And we would do this
> to avoid two different files (with presumably different content) from having
> the same hashes leading to the same signature? Which hashes (besides the
> non-recommended ones) are so weak now that you must not merely sign a file's
> hash?
>
> The problem with this is that older kernels (without patching) won't be able
> to handle newer signatures.
IMA needs to sign the entire ima_file_id structure, which is indeed what
IMA already does when it uses that structure. (Well, actually it signs
a hash of the struct, but that's best thought of an implementation
detail of legacy signature algorithms that can only sign hashes. For a
modern algorithm the whole struct should be passed instead.) Just IMA
uses that structure only for fsverity hashes, which is a bug that makes
the IMA protocol ambiguous. It needs to use ima_file_id consistently,
otherwise a signed message sometimes corresponds to multiple unique file
contents even without a break in the cryptographic hash function.
Sure, when that bug is fixed, old kernels won't support the new
signatures for files that use a full-file hash. But the same applies to
starting to use a new signature algorithm, such as ML-DSA.
- Eric
^ permalink raw reply
* Re: IMA and PQC
From: Simo Sorce @ 2026-02-26 18:42 UTC (permalink / raw)
To: Stefan Berger, Eric Biggers
Cc: Coiby Xu, Johannes Wiesböck, dhowells, dmitry.kasatkin,
eric.snowberg, keyrings, linux-crypto, linux-integrity,
linux-kernel, linux-modules, roberto.sassu, zohar, michael.weiss
In-Reply-To: <969c74f3-81ed-442c-87dd-381274a642a7@linux.ibm.com>
On Thu, 2026-02-26 at 12:22 -0500, Stefan Berger wrote:
>
> On 2/26/26 11:58 AM, Eric Biggers wrote:
> > On Thu, Feb 26, 2026 at 10:27:43AM -0500, Simo Sorce wrote:
> > > On Thu, 2026-02-26 at 09:16 -0500, Stefan Berger wrote:
> > > > On 2/26/26 7:42 AM, Stefan Berger wrote:
> > > > > On 2/25/26 7:10 PM, Eric Biggers wrote:
> > > > > > On Wed, Feb 25, 2026 at 09:25:43AM -0500, Stefan Berger wrote:
> > > > > > > To avoid duplicate work: Is either one of you planning on writing
> > > > > > > patches
> > > > > > > for IMA to use ML-DSA and convert the current ML-DSA to also support
> > > > > > > HashML?
> > > > > > > I had done the work on this before and could dig out the patches
> > > > > > > again...
> > > > > >
> > > > > > IMA already had to add its own digest prefixing support, since it was
> > > > > > needed to disambiguate between full-file digests and fsverity digests.
> > > > > > See 'struct ima_file_id'. Thus the message signed is at most 66 bytes.
> > > > >
> > > > > The hash there is still only a hash over a file and that hash is signed,
> > > > > isn't it?
> > > > >
> > > > > >
> > > > > > With that being the case, HashML-DSA isn't necessary. It's not even
> > > > > > possible to use here, since there are no OIDs assigned for the fsverity
> > > > > > digests, so it cannot replace the ima_file_id.
> > > > >
> > > > > For non-fsverify IMA signatures it is 'possible' to use HashML-DSA and
> > > > > it's 'working' (recycled old patches yesterday):
> > > > >
> > > > > Linux: https://github.com/stefanberger/linux/commits/
> > > > > dhmlsa%2Bima.202602025/
> > > > >
> > > > > ima-evm-utils: https://github.com/linux-integrity/ima-evm-utils/pull/19/
> > > > > commits
> > > > >
> > > > > >
> > > > > > I'll also note that HashML-DSA is controversial (e.g. see
> > > > > > https://keymaterial.net/2024/11/05/hashml-dsa-considered-harmful/),
> > > > >
> > > > > The problem with this is that NIST would have to react to these
> > > > > controversies as we race to support PQC. If something is wrong with the
> > > > > standard then it would be best for NIST to withdraw/modify HashML-DSA
> > > > > asap. Otherwise it's the best to follow the standard IMO because if you
> > > > > don't you get criticism otherwise.
> > > >
> > > > What I am not clear about from FIPS-204 is whether availability of
> > > > HashML-DSA is a "must-use" or a "may-use". What speaks against it for
> > > > our use case is performance. The lookup of a hash's ID (last digit of
> > > > OID) and the creation of the 11 byte encoding to prepend before every
> > > > digest for every signature takes cycles.
> > >
> > > It is a recommendation, but there are plenty of protocols (TLS,
> > > OpenPGP, etc...) where the decision has been made to use "pure" ML-DSA
> > > only, even if what you are signing is not the full data, but something
> > > containing a hash.
> > >
> > > Ideally you do not sign *just* a hash, but some structured data, like a
> > > context label that identifies the hash and some other related metadata
> > > for example. In order to make forgeries much harder should the hashing
> > > algorithm used to hash the data weaken over time. But it is not
> > > strictly necessary (NIST mentioned in some forum, sorry I do not have
> > > the message handy for quoting, that a structured packet is perfectly
> > > fine for use with pure ML-DSA, because it does enough to address the
> > > same issues that a separate internal context does with HashML-DSA).
> > >
> > > If pure-ML-DSA works better for IMA, just use pure ML-DSA.
> > >
> > > > Maybe it should explicitly state in FIPS-204 something along the lines
> > > > of "with a given hash either ML-DSA or HashML-DSA can be used (for as
> > > > long as you use it in the same way from then on)." At least this way
> > > > nobody can point out that HashML-DSA should have been used when you didn't.
> > >
> > > NIST will not change the standard documents any time soon, but for FIPS
> > > certification there are Implementation Guidelines.
> > >
> > > In any case a FIPS module cannot distinguish between data that happens
> > > to be 32 bytes long and a hash of larger data, so the point is kind of
> > > moot. From the FIPS perspective HashML-DSA is just an available
> > > algorithm that protocol implementations can use, or not.
> > >
> > > There are additional guidelines on what this may be useful for, but so
> > > far NIST has not objected to the use of pure ML-DSA even where
> > > theoretically HashML-DSA could be used.
> >
> > I see that IMA indeed never upgraded full file hashes to use
> > 'struct ima_file_id'. Building a new feature that relies on this seems
> > like a bad idea though, given that it's a security bug that makes
> the> IMA protocol cryptographically ambiguous. I.e., it means that in IMA,
> > when the contents of some file are signed, that signature is sometimes
> > also valid for some other file contents which the signer didn't intend.
>
> You mean IMA should not sign the digest in the ima_file_id structure but
> hash the ima_file_id structure in which this file digest is written into
> (that we currently sign) and sign/verify this digest?
You should not (need to) hash it, just format it and the use ML-DSA to
sign it.
> And we would do
> this to avoid two different files (with presumably different content)
> from having the same hashes leading to the same signature? Which hashes
> (besides the non-recommended ones) are so weak now that you must not
> merely sign a file's hash?
>
> The problem with this is that older kernels (without patching) won't be
> able to handle newer signatures.
Ad a kernel option to use the new format? Old kernels won't be able to
deal with ML-DSA IMA either.
> >
> > Just fix that bug first, which has to be done anyway. Then just use
> > pure ML-DSA to sign and verify the 'struct ima_file_id'.
> > > As Simo mentioned, FIPS 204 doesn't require HashML-DSA when signing a
> > hash. It's there as an *option* to solve a perceived problem, which is
> > actually solvable in better ways.
> >
> > NIST doesn't plan to update FIPS 204 until 2029, and most likely the
> > updates will just be errata in the text (such as the ones I reported to
> > them), not changes or withdrawals in the algorithms themselves. But
> > it's irrelevant: just because HashML-DSA is an option doesn't mean it
> > has to be used. Pure ML-DSA supports arbitrary data, which includes
>
> And I was sure whether it was merely an 'option'. Who would use it then
> if it takes more cycles to hash the prepended 11 byte oid in HashML-DSA?
Nobody is using HashML-DSA at the moment.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
^ 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