* Re: [PATCH v3 0/2] landlock: Fix TSYNC deadlock and clean up error path
From: Mickaël Salaün @ 2026-03-03 17:31 UTC (permalink / raw)
To: Yihan Ding
Cc: Günther Noack, Paul Moore, Jann Horn, linux-security-module,
linux-kernel, syzbot+7ea2f5e9dfd468201817
In-Reply-To: <20260226015903.3158620-1-dingyihan@uniontech.com>
Thanks! It's been in -next since last week and I'll send a PR with it
soon.
On Thu, Feb 26, 2026 at 09:59:01AM +0800, Yihan Ding wrote:
> Hello,
>
> This patch series fixes a deadlock in the Landlock TSYNC multithreading
> support, originally reported by syzbot, and cleans up the associated
> interrupt recovery path.
>
> The deadlock occurs when multiple threads concurrently call
> landlock_restrict_self() with sibling thread restriction enabled,
> causing them to mutually queue task_works on each other and block
> indefinitely.
>
> * Patch 1 fixes the root cause by serializing the TSYNC operations
> within the same process using the exec_update_lock.
> * Patch 2 cleans up the interrupt recovery path by replacing an
> unnecessary wait_for_completion() with a straightforward loop break,
> avoiding Use-After-Free while unblocking remaining task_works.
>
> Changes in v3:
> - Patch 1: Changed down_write_killable() to down_write_trylock() and
> return -ERESTARTNOINTR on failure. This avoids a secondary deadlock
> where a blocking wait prevents a sibling thread from waking up to
> execute the requested TSYNC task_work. (Noted by Günther Noack.
> down_write_interruptible() was also suggested but is not implemented
> for rw_semaphores in the kernel).
> - Patch 2: No changes.
>
> Changes in v2:
> - Split the changes into a 2-patch series.
> - Patch 1: Adopted down_write_killable() instead of down_write().
> - Patch 2: Removed wait_for_completion(&shared_ctx.all_prepared) and
> replaced it with a `break` to prevent UAF.
>
> Link to v2: https://lore.kernel.org/all/20260225024734.3024732-1-dingyihan@uniontech.com/
> Link to v1: https://lore.kernel.org/all/20260224062729.2908692-1-dingyihan@uniontech.com/
>
> Yihan Ding (2):
> landlock: Serialize TSYNC thread restriction
> landlock: Clean up interrupted thread logic in TSYNC
>
> security/landlock/tsync.c | 20 ++++++++++++++------
> 1 file changed, 14 insertions(+), 6 deletions(-)
> --
> 2.51.0
^ permalink raw reply
* [PATCH v1] landlock: Fix formatting
From: Mickaël Salaün @ 2026-03-03 17:36 UTC (permalink / raw)
To: Günther Noack
Cc: Mickaël Salaün, linux-security-module, Kees Cook
Auto-format with clang-format -i security/landlock/*.[ch]
Cc: Günther Noack <gnoack@google.com>
Cc: Kees Cook <kees@kernel.org>
Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
Signed-off-by: Mickaël Salaün <mic@digikod.net>
---
security/landlock/domain.c | 3 +--
security/landlock/ruleset.c | 9 ++++-----
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/security/landlock/domain.c b/security/landlock/domain.c
index f5b78d4766cd..f0d83f43afa1 100644
--- a/security/landlock/domain.c
+++ b/security/landlock/domain.c
@@ -94,8 +94,7 @@ static struct landlock_details *get_current_details(void)
* allocate with GFP_KERNEL_ACCOUNT because it is independent from the
* caller.
*/
- details =
- kzalloc_flex(*details, exe_path, path_size);
+ details = kzalloc_flex(*details, exe_path, path_size);
if (!details)
return ERR_PTR(-ENOMEM);
diff --git a/security/landlock/ruleset.c b/security/landlock/ruleset.c
index 319873586385..73018dc8d6c7 100644
--- a/security/landlock/ruleset.c
+++ b/security/landlock/ruleset.c
@@ -32,9 +32,8 @@ static struct landlock_ruleset *create_ruleset(const u32 num_layers)
{
struct landlock_ruleset *new_ruleset;
- new_ruleset =
- kzalloc_flex(*new_ruleset, access_masks, num_layers,
- GFP_KERNEL_ACCOUNT);
+ new_ruleset = kzalloc_flex(*new_ruleset, access_masks, num_layers,
+ GFP_KERNEL_ACCOUNT);
if (!new_ruleset)
return ERR_PTR(-ENOMEM);
refcount_set(&new_ruleset->usage, 1);
@@ -559,8 +558,8 @@ landlock_merge_ruleset(struct landlock_ruleset *const parent,
if (IS_ERR(new_dom))
return new_dom;
- new_dom->hierarchy = kzalloc_obj(*new_dom->hierarchy,
- GFP_KERNEL_ACCOUNT);
+ new_dom->hierarchy =
+ kzalloc_obj(*new_dom->hierarchy, GFP_KERNEL_ACCOUNT);
if (!new_dom->hierarchy)
return ERR_PTR(-ENOMEM);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] landlock: Serialize TSYNC thread restriction
From: Mickaël Salaün @ 2026-03-03 17:47 UTC (permalink / raw)
To: Justin Suess
Cc: Yihan Ding, Günther Noack, Paul Moore, Jann Horn,
linux-security-module, linux-kernel, syzbot+7ea2f5e9dfd468201817
In-Reply-To: <aacKOr1wywSSOAVv@suesslenovo>
On Tue, Mar 03, 2026 at 11:20:10AM -0500, Justin Suess wrote:
> On Thu, Feb 26, 2026 at 09:59:02AM +0800, Yihan Ding wrote:
> > syzbot found a deadlock in landlock_restrict_sibling_threads().
> > When multiple threads concurrently call landlock_restrict_self() with
> > sibling thread restriction enabled, they can deadlock by mutually
> > queueing task_works on each other and then blocking in kernel space
> > (waiting for the other to finish).
> >
> > Fix this by serializing the TSYNC operations within the same process
> > using the exec_update_lock. This prevents concurrent invocations
> > from deadlocking.
> >
> > We use down_write_trylock() and return -ERESTARTNOINTR if the lock
> > cannot be acquired immediately. This ensures that if a thread fails
> > to get the lock, it will return to userspace, allowing it to process
> > any pending TSYNC task_works from the lock holder, and then
> > transparently restart the syscall.
> >
> > Fixes: 42fc7e6543f6 ("landlock: Multithreading support for landlock_restrict_self()")
> > Reported-by: syzbot+7ea2f5e9dfd468201817@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=7ea2f5e9dfd468201817
> > Suggested-by: Günther Noack <gnoack3000@gmail.com>
> > Signed-off-by: Yihan Ding <dingyihan@uniontech.com>
> > ---
> > Changes in v3:
> > - Replaced down_write_killable() with down_write_trylock() and
> > returned -ERESTARTNOINTR to avoid a secondary deadlock caused by
> > blocking the execution of task_works. (Caught by Günther Noack).
> >
> > Changes in v2:
> > - Use down_write_killable() instead of down_write().
> > - Split the interrupt path cleanup into a separate patch.
> > ---
> > security/landlock/tsync.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
> > index de01aa899751..xxxxxxxxxxxx 100644
> > --- a/security/landlock/tsync.c
> > +++ b/security/landlock/tsync.c
> > @@ -447,6 +447,13 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
> > shared_ctx.new_cred = new_cred;
> > shared_ctx.set_no_new_privs = task_no_new_privs(current);
> >
> > + /*
> > + * Serialize concurrent TSYNC operations to prevent deadlocks
> > + * when multiple threads call landlock_restrict_self() simultaneously.
> > + */
> > + if (!down_write_trylock(¤t->signal->exec_update_lock))
> > + return -ERESTARTNOINTR;
> These two lines above introduced a test failure in tsync_test
> completing_enablement.
>
> The commit that introduced the bug is 3d6327c306b3e1356ab868bf27a0854669295a4f
> (this patch) and is currently in the mic/next branch.
>
> I noticed the test failure while testing an unrelated patch.
>
> The bug is because this code never actually yields or restarts the syscall.
>
> This is the test output I observed:
>
> [+] Running tsync_test:
> TAP version 13
> 1..4
> # Starting 4 tests from 1 test cases.
> # RUN global.single_threaded_success ...
> # OK global.single_threaded_success
> ok 1 global.single_threaded_success
> # RUN global.multi_threaded_success ...
> # OK global.multi_threaded_success
> ok 2 global.multi_threaded_success
> # RUN global.multi_threaded_success_despite_diverging_domains ...
> # OK global.multi_threaded_success_despite_diverging_domains
> ok 3 global.multi_threaded_success_despite_diverging_domains
> # RUN global.competing_enablement ...
> # tsync_test.c:156:competing_enablement:Expected 0 (0) == d[1].result (-1)
> # competing_enablement: Test failed
> # FAIL global.competing_enablement
> not ok 4 global.competing_enablement
> # FAILED: 3 / 4 tests passed.
>
>
> Brief investigation and the additions of these pr_warn lines:
>
>
> diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
> index 0d66a68677b7..84909232b220 100644
> --- a/security/landlock/syscalls.c
> +++ b/security/landlock/syscalls.c
> @@ -574,6 +574,9 @@ SYSCALL_DEFINE2(landlock_restrict_self, const int, ruleset_fd, const __u32,
> const int err = landlock_restrict_sibling_threads(
> current_cred(), new_cred);
> if (err) {
> + pr_warn("landlock: restrict_self tsync err pid=%d tgid=%d err=%d flags=0x%x ruleset_fd=%d\n",
> + task_pid_nr(current), task_tgid_nr(current), err,
> + flags, ruleset_fd);
> abort_creds(new_cred);
> return err;
> }
> diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
> index 5afc5d639b8f..deb0f0b1f081 100644
> --- a/security/landlock/tsync.c
> +++ b/security/landlock/tsync.c
> @@ -489,8 +489,11 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
> * Serialize concurrent TSYNC operations to prevent deadlocks when multiple
> * threads call landlock_restrict_self() simultaneously.
> */
> - if (!down_write_trylock(¤t->signal->exec_update_lock))
> + if (!down_write_trylock(¤t->signal->exec_update_lock)) {
> + pr_warn("landlock: tsync trylock busy pid=%d tgid=%d\n",
> + task_pid_nr(current), task_tgid_nr(current));
> return -ERESTARTNOINTR;
> + }
>
> /*
> * We schedule a pseudo-signal task_work for each of the calling task's
> @@ -602,6 +605,10 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
>
> tsync_works_release(&works);
> up_write(¤t->signal->exec_update_lock);
> + if (atomic_read(&shared_ctx.preparation_error))
> + pr_warn("landlock: tsync preparation_error pid=%d tgid=%d err=%d\n",
> + task_pid_nr(current), task_tgid_nr(current),
> + atomic_read(&shared_ctx.preparation_error));
>
> return atomic_read(&shared_ctx.preparation_error);
> }
>
> Resulted in the following output:
>
> landlock: tsync trylock busy pid=1263 tgid=1261
> landlock: landlock: restrict_self tsync err pid=1263 tgid=1261 err=-513 flags=0x8 ruleset_fd=6
> # tsync_test.c:156:competing_enablement:Expected 0 (0) == d[1].result (-1)
> # competing_enablement: Test failed
> # FAIL global.competing_enablement
> not ok 4 global.competing_enablement
You're right, I have the same issue, not sure how I missed it last time.
>
> I have a fix that I will send as a patch.
I'll need to squash your fix to this fix to only have one non-buggy
patch. So, either you send a new patch and I'll squash it with
Co-developed-by, or Yihan takes your patch and send a new version with
your contribution (I'll prefer the later to make it easier to follow
this series).
>
> Kind Regards,
> Justin Suess
>
^ permalink raw reply
* Re: [PATCH v3 1/2] landlock: Serialize TSYNC thread restriction
From: Mickaël Salaün @ 2026-03-03 17:51 UTC (permalink / raw)
To: Yihan Ding
Cc: Günther Noack, Paul Moore, Jann Horn, linux-security-module,
linux-kernel, syzbot+7ea2f5e9dfd468201817
In-Reply-To: <20260226015903.3158620-2-dingyihan@uniontech.com>
On Thu, Feb 26, 2026 at 09:59:02AM +0800, Yihan Ding wrote:
> syzbot found a deadlock in landlock_restrict_sibling_threads().
> When multiple threads concurrently call landlock_restrict_self() with
> sibling thread restriction enabled, they can deadlock by mutually
> queueing task_works on each other and then blocking in kernel space
> (waiting for the other to finish).
>
> Fix this by serializing the TSYNC operations within the same process
> using the exec_update_lock. This prevents concurrent invocations
> from deadlocking.
>
> We use down_write_trylock() and return -ERESTARTNOINTR if the lock
> cannot be acquired immediately. This ensures that if a thread fails
> to get the lock, it will return to userspace, allowing it to process
> any pending TSYNC task_works from the lock holder, and then
> transparently restart the syscall.
>
> Fixes: 42fc7e6543f6 ("landlock: Multithreading support for landlock_restrict_self()")
> Reported-by: syzbot+7ea2f5e9dfd468201817@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=7ea2f5e9dfd468201817
> Suggested-by: Günther Noack <gnoack3000@gmail.com>
> Signed-off-by: Yihan Ding <dingyihan@uniontech.com>
> ---
> Changes in v3:
> - Replaced down_write_killable() with down_write_trylock() and
> returned -ERESTARTNOINTR to avoid a secondary deadlock caused by
> blocking the execution of task_works. (Caught by Günther Noack).
>
> Changes in v2:
> - Use down_write_killable() instead of down_write().
> - Split the interrupt path cleanup into a separate patch.
> ---
> security/landlock/tsync.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
> index de01aa899751..xxxxxxxxxxxx 100644
> --- a/security/landlock/tsync.c
> +++ b/security/landlock/tsync.c
> @@ -447,6 +447,13 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
> shared_ctx.new_cred = new_cred;
> shared_ctx.set_no_new_privs = task_no_new_privs(current);
>
> + /*
> + * Serialize concurrent TSYNC operations to prevent deadlocks
> + * when multiple threads call landlock_restrict_self() simultaneously.
Please format this comment and the next patch ones to fit (and fill) in
80 columns.
> + */
> + if (!down_write_trylock(¤t->signal->exec_update_lock))
> + return -ERESTARTNOINTR;
> +
> /*
> * We schedule a pseudo-signal task_work for each of the calling task's
> * sibling threads. In the task work, each thread:
> @@ -556,6 +563,7 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
> wait_for_completion(&shared_ctx.all_finished);
>
> tsync_works_release(&works);
> + up_write(¤t->signal->exec_update_lock);
>
> return atomic_read(&shared_ctx.preparation_error);
> }
> --
> 2.51.0
>
^ permalink raw reply
* [PATCH] landlock: Yield if unable to acquire exec_update_lock
From: Justin Suess @ 2026-03-03 17:43 UTC (permalink / raw)
To: linux-security-module, Yihan Ding
Cc: Mickaël Salaün, Günther Noack, Tingmao Wang,
Justin Suess, Günther Noack
Instead of returning -ERESTARTNOINTR when there is no pending
signal, run the pending tasks in the current thread and yield
until the exec_update_lock can be acquired.
This allows other tasks to run and allows the lock contention
to resolve in the kernel's task scheduler.
Cc: Yihan Ding <dingyihan@uniontech.com>
Cc: Günther Noack <gnoack3000@gmail.com>
Fixes: 3d6327c306b3 ("landlock: Serialize TSYNC thread restriction")
Closes: https://lore.kernel.org/linux-security-module/aacKOr1wywSSOAVv@suesslenovo/
Signed-off-by: Justin Suess <utilityemal77@gmail.com>
---
Notes:
This fixes the failure in tsync_test.competing_enablement:
landlock: tsync trylock busy pid=1263 tgid=1261
landlock: landlock: restrict_self tsync err pid=1263 tgid=1261 err=-513 flags=0x8 ruleset_fd=6
# tsync_test.c:156:competing_enablement:Expected 0 (0) == d[1].result (-1)
# competing_enablement: Test failed
# FAIL global.competing_enablement
not ok 4 global.competing_enablement
The test passes after applying this patch.
security/landlock/tsync.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
index 956a64cb6945..83938849620f 100644
--- a/security/landlock/tsync.c
+++ b/security/landlock/tsync.c
@@ -487,10 +487,14 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
/*
* Serialize concurrent TSYNC operations to prevent deadlocks when multiple
- * threads call landlock_restrict_self() simultaneously.
+ * threads call landlock_restrict_self() simultaneously. If we are unable to
+ * acquire the lock, we yield nicely and retry.
*/
- if (!down_write_trylock(¤t->signal->exec_update_lock))
- return -ERESTARTNOINTR;
+ while (!down_write_trylock(¤t->signal->exec_update_lock)) {
+ if (task_work_pending(current))
+ task_work_run();
+ cond_resched();
+ }
/*
* We schedule a pseudo-signal task_work for each of the calling task's
base-commit: 8ff74a72b8af3672beca7f6b6b72557a9db94382
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Matthew Wilcox @ 2026-03-03 17:18 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, Darrick J. Wong, Theodore Tso, Alexander Viro,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Eric Biggers, 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,
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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <1310fc5c09cce52ec00344b936275fe584c88dea.camel@kernel.org>
On Tue, Mar 03, 2026 at 09:19:42AM -0500, Jeff Layton wrote:
> There are really only three options here:
>
> 1/ Do (almost) all of the changes in one giant patch
>
> 2/ Accept that the build may break during the interim stages
>
> 3/ This series: using a typedef and macro to work around the breakage
> until the type can be changed, at the expense of some extra churn in
> the codebase
4/ Don't do anything, drop the patch series (I'm not in favour of this,
but it is an option)
5/ Do the conversion(s) _once_ per filesystem. Here's one way to do
it:
- unsigned long i_ino;
+ union {
+ u64 i_ino64;
+ struct {
+#if defined(CONFIG_64BIT)
+ unsigned long i_ino;
+#elif defined(CONFIG_CPU_BIG_ENDIAN)
+ unsigned long i_ino;
+ unsigned long i_ino_pad;
+#else
+ unsigned long i_ino_pad;
+ unsigned long i_ino;
+#endif
+ };
+ };
[...]
#define i_ino(inode) (inode)->i_ino64
So that's patch one. All plain references to i_ino access the lower
bits of i_ino64, so everything will continue to work as it does today.
Once you've got the VFS core in shape, you can convert filesystems one
at a time to use i_ino(inode). Once you're done you can delete the
scaffolding from the core and go back to calling i_ino64 just i_ino.
You could delete the i_ino() uses from filesystems at that point, but
why bother?
I'm sure there are other ways to do it, this is just the one I came up
with. But for the love of god stop spamming hundreds of people on the
cc of this patchset. In fact, take me off for next time -- I get each
one of these fucking patches four times.
^ permalink raw reply
* Re: LSM namespacing API
From: Paul Moore @ 2026-03-03 16:46 UTC (permalink / raw)
To: Stephen Smalley
Cc: Ondrej Mosnacek, linux-security-module, selinux, John Johansen
In-Reply-To: <CAEjxPJ4urh7mUbDJEi-DbdiAifMM_uDH3m35tLeTdx6z+qhPyg@mail.gmail.com>
On Tue, Mar 3, 2026 at 8:30 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Wed, Feb 25, 2026 at 7:05 PM Paul Moore <paul@paul-moore.com> wrote:
> > I spent a few hours this afternoon re-reading this thread and tweaking
> > the original proposal to address everything discussed. The revised
> > proposal is below, with a bit more detail than before, please take a
> > look and let us all know what you think ...
[Yet another reminder to please consider trimming your replies.]
> I think my only caveat here is that your proposal is quite a bit more
> complex than what I implemented here:
> [1] https://lore.kernel.org/selinux/20251003190959.3288-2-stephen.smalley.work@gmail.com/
> [2] https://lore.kernel.org/selinux/20251003191328.3605-1-stephen.smalley.work@gmail.com/
> and I'm not sure the extra complexity is worth it.
>
> In particular:
> 1. Immediately unsharing the namespace upon lsm_set_self_attr() allows
> the caller to immediately and unambiguously know if the operation is
> supported and allowed ...
Performing the unshare operation immediately looks much less like a
LSM attribute and more like its own syscall. That isn't a problem in
my eyes, it just means if this is the direction we want to go we
should implement a lsm_unshare(2) API, or something similar.
> 3. We don't need to introduce a new CLONE_* flag at all or introduce
> new or changed LSM hooks to clone/unshare,
While I think we could get away with a new lsm_unshare(2) syscall, I
have zero interest in an lsm_clone(2) syscall. If we do away with the
namespace related LSM attributes and rely entirely on a lsm_unshare(2)
syscall, would everyone be okay with that?
(I think we would still want/need the procfs API)
> All that said, I'm willing to wire up the SELinux namespaces
> implementation to the proposed interface if someone implements the
> necessary plumbing, but I'm not sure it's better.
I'd really like to hear from some of the other LSMs before we start
diving into the code. It may sound funny, but from my perspective
doing the work to get the API definition "right" is far more important
than implementing it.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 1/2] landlock: Serialize TSYNC thread restriction
From: Justin Suess @ 2026-03-03 16:20 UTC (permalink / raw)
To: Yihan Ding
Cc: Mickaël Salaün, Günther Noack, Paul Moore,
Jann Horn, linux-security-module, linux-kernel,
syzbot+7ea2f5e9dfd468201817
In-Reply-To: <20260226015903.3158620-2-dingyihan@uniontech.com>
On Thu, Feb 26, 2026 at 09:59:02AM +0800, Yihan Ding wrote:
> syzbot found a deadlock in landlock_restrict_sibling_threads().
> When multiple threads concurrently call landlock_restrict_self() with
> sibling thread restriction enabled, they can deadlock by mutually
> queueing task_works on each other and then blocking in kernel space
> (waiting for the other to finish).
>
> Fix this by serializing the TSYNC operations within the same process
> using the exec_update_lock. This prevents concurrent invocations
> from deadlocking.
>
> We use down_write_trylock() and return -ERESTARTNOINTR if the lock
> cannot be acquired immediately. This ensures that if a thread fails
> to get the lock, it will return to userspace, allowing it to process
> any pending TSYNC task_works from the lock holder, and then
> transparently restart the syscall.
>
> Fixes: 42fc7e6543f6 ("landlock: Multithreading support for landlock_restrict_self()")
> Reported-by: syzbot+7ea2f5e9dfd468201817@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=7ea2f5e9dfd468201817
> Suggested-by: Günther Noack <gnoack3000@gmail.com>
> Signed-off-by: Yihan Ding <dingyihan@uniontech.com>
> ---
> Changes in v3:
> - Replaced down_write_killable() with down_write_trylock() and
> returned -ERESTARTNOINTR to avoid a secondary deadlock caused by
> blocking the execution of task_works. (Caught by Günther Noack).
>
> Changes in v2:
> - Use down_write_killable() instead of down_write().
> - Split the interrupt path cleanup into a separate patch.
> ---
> security/landlock/tsync.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
> index de01aa899751..xxxxxxxxxxxx 100644
> --- a/security/landlock/tsync.c
> +++ b/security/landlock/tsync.c
> @@ -447,6 +447,13 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
> shared_ctx.new_cred = new_cred;
> shared_ctx.set_no_new_privs = task_no_new_privs(current);
>
> + /*
> + * Serialize concurrent TSYNC operations to prevent deadlocks
> + * when multiple threads call landlock_restrict_self() simultaneously.
> + */
> + if (!down_write_trylock(¤t->signal->exec_update_lock))
> + return -ERESTARTNOINTR;
These two lines above introduced a test failure in tsync_test
completing_enablement.
The commit that introduced the bug is 3d6327c306b3e1356ab868bf27a0854669295a4f
(this patch) and is currently in the mic/next branch.
I noticed the test failure while testing an unrelated patch.
The bug is because this code never actually yields or restarts the syscall.
This is the test output I observed:
[+] Running tsync_test:
TAP version 13
1..4
# Starting 4 tests from 1 test cases.
# RUN global.single_threaded_success ...
# OK global.single_threaded_success
ok 1 global.single_threaded_success
# RUN global.multi_threaded_success ...
# OK global.multi_threaded_success
ok 2 global.multi_threaded_success
# RUN global.multi_threaded_success_despite_diverging_domains ...
# OK global.multi_threaded_success_despite_diverging_domains
ok 3 global.multi_threaded_success_despite_diverging_domains
# RUN global.competing_enablement ...
# tsync_test.c:156:competing_enablement:Expected 0 (0) == d[1].result (-1)
# competing_enablement: Test failed
# FAIL global.competing_enablement
not ok 4 global.competing_enablement
# FAILED: 3 / 4 tests passed.
Brief investigation and the additions of these pr_warn lines:
diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
index 0d66a68677b7..84909232b220 100644
--- a/security/landlock/syscalls.c
+++ b/security/landlock/syscalls.c
@@ -574,6 +574,9 @@ SYSCALL_DEFINE2(landlock_restrict_self, const int, ruleset_fd, const __u32,
const int err = landlock_restrict_sibling_threads(
current_cred(), new_cred);
if (err) {
+ pr_warn("landlock: restrict_self tsync err pid=%d tgid=%d err=%d flags=0x%x ruleset_fd=%d\n",
+ task_pid_nr(current), task_tgid_nr(current), err,
+ flags, ruleset_fd);
abort_creds(new_cred);
return err;
}
diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
index 5afc5d639b8f..deb0f0b1f081 100644
--- a/security/landlock/tsync.c
+++ b/security/landlock/tsync.c
@@ -489,8 +489,11 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
* Serialize concurrent TSYNC operations to prevent deadlocks when multiple
* threads call landlock_restrict_self() simultaneously.
*/
- if (!down_write_trylock(¤t->signal->exec_update_lock))
+ if (!down_write_trylock(¤t->signal->exec_update_lock)) {
+ pr_warn("landlock: tsync trylock busy pid=%d tgid=%d\n",
+ task_pid_nr(current), task_tgid_nr(current));
return -ERESTARTNOINTR;
+ }
/*
* We schedule a pseudo-signal task_work for each of the calling task's
@@ -602,6 +605,10 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
tsync_works_release(&works);
up_write(¤t->signal->exec_update_lock);
+ if (atomic_read(&shared_ctx.preparation_error))
+ pr_warn("landlock: tsync preparation_error pid=%d tgid=%d err=%d\n",
+ task_pid_nr(current), task_tgid_nr(current),
+ atomic_read(&shared_ctx.preparation_error));
return atomic_read(&shared_ctx.preparation_error);
}
Resulted in the following output:
landlock: tsync trylock busy pid=1263 tgid=1261
landlock: landlock: restrict_self tsync err pid=1263 tgid=1261 err=-513 flags=0x8 ruleset_fd=6
# tsync_test.c:156:competing_enablement:Expected 0 (0) == d[1].result (-1)
# competing_enablement: Test failed
# FAIL global.competing_enablement
not ok 4 global.competing_enablement
I have a fix that I will send as a patch.
Kind Regards,
Justin Suess
^ permalink raw reply related
* Re: [PATCH v2 003/110] audit: widen ino fields to u64
From: Paul Moore @ 2026-03-03 16:17 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, 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, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <add39953250a4a1b2fe2b09deb3373c2a7482b88.camel@kernel.org>
On Tue, Mar 3, 2026 at 11:12 AM Jeff Layton <jlayton@kernel.org> wrote:
> On Tue, 2026-03-03 at 11:03 -0500, Paul Moore wrote:
> > On Tue, Mar 3, 2026 at 6:05 AM Jeff Layton <jlayton@kernel.org> wrote:
> > > On Mon, 2026-03-02 at 18:44 -0500, Paul Moore wrote:
> > > > On Mon, Mar 2, 2026 at 3:25 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > >
> > > > > inode->i_ino is being widened from unsigned long to u64. The audit
> > > > > subsystem uses unsigned long ino in struct fields, function parameters,
> > > > > and local variables that store inode numbers from arbitrary filesystems.
> > > > > On 32-bit platforms this truncates inode numbers that exceed 32 bits,
> > > > > which will cause incorrect audit log entries and broken watch/mark
> > > > > comparisons.
> > > > >
> > > > > Widen all audit ino fields, parameters, and locals to u64, and update
> > > > > the inode format string from %lu to %llu to match.
> > > > >
> > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > > ---
> > > > > include/linux/audit.h | 2 +-
> > > > > kernel/audit.h | 9 ++++-----
> > > > > kernel/audit_fsnotify.c | 4 ++--
> > > > > kernel/audit_watch.c | 8 ++++----
> > > > > kernel/auditsc.c | 2 +-
> > > > > 5 files changed, 12 insertions(+), 13 deletions(-)
> > > >
> > > > We should also update audit_hash_ino() in kernel/audit.h. It is a
> > > > *very* basic hash function, so I think leaving the function as-is and
> > > > just changing the inode parameter from u32 to u64 should be fine.
> >
> > ...
> >
> > > It doesn't look like changing the argument type will make any material
> > > difference. Given that it should still work without that change, can we
> > > leave this cleanup for you to do in a follow-on patchset?
> >
> > I would prefer if you made the change as part of the patch, mainly to
> > keep a patch record of this being related.
>
> Ok, I'll see about factoring that in.
Thanks.
> > Ideally I'd really like to see kino_t used in the audit code instead
> > of u64, but perhaps that is done in a later patch that I didn't see.
>
> I think I didn't make this clear enough in the cover letter, but kino_t
> is removed at the end of the series. It's just there to support the
> change during the interim.
Ah, gotcha, thanks for the education :)
> If HCH gets his way to do the changes as one big patch, it'll go away
> entirely.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 003/110] audit: widen ino fields to u64
From: Jeff Layton @ 2026-03-03 16:12 UTC (permalink / raw)
To: Paul Moore
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, 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, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <CAHC9VhTyhnG7-ojnTnVdh_m1x=rKxw9YEH9g7Xp9m4F78aA5cA@mail.gmail.com>
On Tue, 2026-03-03 at 11:03 -0500, Paul Moore wrote:
> On Tue, Mar 3, 2026 at 6:05 AM Jeff Layton <jlayton@kernel.org> wrote:
> > On Mon, 2026-03-02 at 18:44 -0500, Paul Moore wrote:
> > > On Mon, Mar 2, 2026 at 3:25 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > >
> > > > inode->i_ino is being widened from unsigned long to u64. The audit
> > > > subsystem uses unsigned long ino in struct fields, function parameters,
> > > > and local variables that store inode numbers from arbitrary filesystems.
> > > > On 32-bit platforms this truncates inode numbers that exceed 32 bits,
> > > > which will cause incorrect audit log entries and broken watch/mark
> > > > comparisons.
> > > >
> > > > Widen all audit ino fields, parameters, and locals to u64, and update
> > > > the inode format string from %lu to %llu to match.
> > > >
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > ---
> > > > include/linux/audit.h | 2 +-
> > > > kernel/audit.h | 9 ++++-----
> > > > kernel/audit_fsnotify.c | 4 ++--
> > > > kernel/audit_watch.c | 8 ++++----
> > > > kernel/auditsc.c | 2 +-
> > > > 5 files changed, 12 insertions(+), 13 deletions(-)
> > >
> > > We should also update audit_hash_ino() in kernel/audit.h. It is a
> > > *very* basic hash function, so I think leaving the function as-is and
> > > just changing the inode parameter from u32 to u64 should be fine.
>
> ...
>
> > It doesn't look like changing the argument type will make any material
> > difference. Given that it should still work without that change, can we
> > leave this cleanup for you to do in a follow-on patchset?
>
> I would prefer if you made the change as part of the patch, mainly to
> keep a patch record of this being related.
>
Ok, I'll see about factoring that in.
> Ideally I'd really like to see kino_t used in the audit code instead
> of u64, but perhaps that is done in a later patch that I didn't see.
I think I didn't make this clear enough in the cover letter, but kino_t
is removed at the end of the series. It's just there to support the
change during the interim.
If HCH gets his way to do the changes as one big patch, it'll go away
entirely.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 003/110] audit: widen ino fields to u64
From: Paul Moore @ 2026-03-03 16:03 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, 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, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <7a0165fe39e82a1effd8cce5c2c4e82d6a42cb3a.camel@kernel.org>
On Tue, Mar 3, 2026 at 6:05 AM Jeff Layton <jlayton@kernel.org> wrote:
> On Mon, 2026-03-02 at 18:44 -0500, Paul Moore wrote:
> > On Mon, Mar 2, 2026 at 3:25 PM Jeff Layton <jlayton@kernel.org> wrote:
> > >
> > > inode->i_ino is being widened from unsigned long to u64. The audit
> > > subsystem uses unsigned long ino in struct fields, function parameters,
> > > and local variables that store inode numbers from arbitrary filesystems.
> > > On 32-bit platforms this truncates inode numbers that exceed 32 bits,
> > > which will cause incorrect audit log entries and broken watch/mark
> > > comparisons.
> > >
> > > Widen all audit ino fields, parameters, and locals to u64, and update
> > > the inode format string from %lu to %llu to match.
> > >
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > > include/linux/audit.h | 2 +-
> > > kernel/audit.h | 9 ++++-----
> > > kernel/audit_fsnotify.c | 4 ++--
> > > kernel/audit_watch.c | 8 ++++----
> > > kernel/auditsc.c | 2 +-
> > > 5 files changed, 12 insertions(+), 13 deletions(-)
> >
> > We should also update audit_hash_ino() in kernel/audit.h. It is a
> > *very* basic hash function, so I think leaving the function as-is and
> > just changing the inode parameter from u32 to u64 should be fine.
...
> It doesn't look like changing the argument type will make any material
> difference. Given that it should still work without that change, can we
> leave this cleanup for you to do in a follow-on patchset?
I would prefer if you made the change as part of the patch, mainly to
keep a patch record of this being related.
Ideally I'd really like to see kino_t used in the audit code instead
of u64, but perhaps that is done in a later patch that I didn't see.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-03 15:25 UTC (permalink / raw)
To: Theodore Tso
Cc: Darrick J. Wong, Alexander Viro, Christian Brauner, Jan Kara,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Dan Williams,
Matthew Wilcox, Eric Biggers, 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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <20260303151617.GD6520@macsyma-wired.lan>
On Tue, 2026-03-03 at 10:16 -0500, Theodore Tso wrote:
> On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> >
> > Like I said to Ted, this is just temporary scaffolding for the change.
> > The PRIino macro is removed in the end. Given that, perhaps you can
> > overlook the bikeshed's color in this instance?
>
> I didn't realize that this was going to disappear in the end. That
> makes me feel much better about the change. I'd suggest changing the
> commit description where it claims that we're using something that
> follows the inttypes.h convention and making it clear that this is
> temporary and only to preserve bisectability.
>
> One question though --- are there *really* places that are using
> signed inode numbers and trying to print them? If people are trying
> to use negative inodes to signal an error or some such, the it implies
> that at least for some file systems, an inode number larger than 2**63
> might be problematic. If there is core VFS code that uses a negative
> inode number then this could be a real potential trap.
>
> So are there really code which is doing a printf of 'PRIino "d"'? Or
> was this to allow the use of of 'PRiino "x"'?
>
Mostly it's to allow 'PRIino "x"'. There are a number of places that
(for whatever reason) print the inode number in hex. I don't want to
change those.
There are also some places that print it as a signed value (PRIino
"d"). I suspect most of those are bugs, or just holdovers from a
simpler time when we didn't worry so much about the signedness of inode
numbers. I fixed a few of those in the context of this series, fwiw.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 15:23 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, Darrick J. Wong, Theodore Tso, Alexander Viro,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Matthew Wilcox, Eric Biggers,
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,
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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <4d3b9b92da613ad329b822f3f6043fa08f534451.camel@kernel.org>
On Tue, Mar 03, 2026 at 10:14:27AM -0500, Jeff Layton wrote:
> I think we'll be looking at close to a 1000 line patch that touches
> nearly 200 files if go that route. Roughly:
>
> 182 files changed, 910 insertions(+), 912 deletions(-)
That's not actually a lot, especially for a patch that should be
scriped and mechnanical.
I also really don't understand the backport argument. It's not like
you could backport any of the split out patches individually anyway.
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Theodore Tso @ 2026-03-03 15:16 UTC (permalink / raw)
To: Jeff Layton
Cc: Darrick J. Wong, Alexander Viro, Christian Brauner, Jan Kara,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Dan Williams,
Matthew Wilcox, Eric Biggers, 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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <33228005140684201de2ca0c157441d3b6a06413.camel@kernel.org>
On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
>
> Like I said to Ted, this is just temporary scaffolding for the change.
> The PRIino macro is removed in the end. Given that, perhaps you can
> overlook the bikeshed's color in this instance?
I didn't realize that this was going to disappear in the end. That
makes me feel much better about the change. I'd suggest changing the
commit description where it claims that we're using something that
follows the inttypes.h convention and making it clear that this is
temporary and only to preserve bisectability.
One question though --- are there *really* places that are using
signed inode numbers and trying to print them? If people are trying
to use negative inodes to signal an error or some such, the it implies
that at least for some file systems, an inode number larger than 2**63
might be problematic. If there is core VFS code that uses a negative
inode number then this could be a real potential trap.
So are there really code which is doing a printf of 'PRIino "d"'? Or
was this to allow the use of of 'PRiino "x"'?
- Ted
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-03 15:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, Theodore Tso, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, 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,
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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <aabwflLfe2HcGv7X@infradead.org>
On Tue, 2026-03-03 at 06:30 -0800, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 09:19:42AM -0500, Jeff Layton wrote:
> > On Tue, 2026-03-03 at 05:59 -0800, Christoph Hellwig wrote:
> > > On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> > > > On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > > > > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > > > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > > > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > > > > overlook the bikeshed's color in this instance?
> > > > >
> > > > > So why add it in the first place?
> > > >
> > > > Bisectability. The first version I did of this would have broken the
> > > > ability to bisect properly across these changes. I don't love the
> > > > "churn" here either, but this should be cleanly bisectable.
> > >
> > > What do you need to bisect in format string changes? Splitting
> > > every variable type change outside of the main i_ino out - sure.
> > > But bisecting that "change to u64 in ext4" really broke ext4 and
> > > not "change to u64" is not very useful. Commits should do one
> > > well defined thing. Adding a weird transition layer for a format
> > > thing that just gets dropped is not one well defined thing.
> >
> > In the middle stages of the series, you will get warnings or errors on
> > 32-bit hosts when i_ino's type doesn't match what the format string
> > expects.
> >
> > There are really only three options here:
> >
> > 1/ Do (almost) all of the changes in one giant patch
> >
> > 2/ Accept that the build may break during the interim stages
> >
> > 3/ This series: using a typedef and macro to work around the breakage
> > until the type can be changed, at the expense of some extra churn in
> > the codebase
> >
> > 3 seems like the lesser evil.
>
> No, 1 is by far the least evil. Note that it's not really almost all,
> as all the local variables can easily and sanely be split out. It's
> all of the format strings, and that makes sense. The only "regressions"
> there are incorrect format strings which have good warnings and can
> be fixed easily.
Well, I've done 2 and 3 already. Why not 1? :)
It's not so much the regressions that are a problem here, but the merge
conflicts for anyone wanting to backport later patches that are near
these format changes. Having that change broken up by subsystem makes
it easier to handle that piecemeal later.
I think we'll be looking at close to a 1000 line patch that touches
nearly 200 files if go that route. Roughly:
182 files changed, 910 insertions(+), 912 deletions(-)
There are some tracepoint changes in some of the per-subsystem patches
that will need to be split out, so the count isn't exact, but it'll be
fairly close.
Since Christian will probably end up taking this series, I'd like to
get his opinion before I respin anything.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 14:30 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, Darrick J. Wong, Theodore Tso, Alexander Viro,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Matthew Wilcox, Eric Biggers,
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,
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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <1310fc5c09cce52ec00344b936275fe584c88dea.camel@kernel.org>
On Tue, Mar 03, 2026 at 09:19:42AM -0500, Jeff Layton wrote:
> On Tue, 2026-03-03 at 05:59 -0800, Christoph Hellwig wrote:
> > On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> > > On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > > > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > > > overlook the bikeshed's color in this instance?
> > > >
> > > > So why add it in the first place?
> > >
> > > Bisectability. The first version I did of this would have broken the
> > > ability to bisect properly across these changes. I don't love the
> > > "churn" here either, but this should be cleanly bisectable.
> >
> > What do you need to bisect in format string changes? Splitting
> > every variable type change outside of the main i_ino out - sure.
> > But bisecting that "change to u64 in ext4" really broke ext4 and
> > not "change to u64" is not very useful. Commits should do one
> > well defined thing. Adding a weird transition layer for a format
> > thing that just gets dropped is not one well defined thing.
>
> In the middle stages of the series, you will get warnings or errors on
> 32-bit hosts when i_ino's type doesn't match what the format string
> expects.
>
> There are really only three options here:
>
> 1/ Do (almost) all of the changes in one giant patch
>
> 2/ Accept that the build may break during the interim stages
>
> 3/ This series: using a typedef and macro to work around the breakage
> until the type can be changed, at the expense of some extra churn in
> the codebase
>
> 3 seems like the lesser evil.
No, 1 is by far the least evil. Note that it's not really almost all,
as all the local variables can easily and sanely be split out. It's
all of the format strings, and that makes sense. The only "regressions"
there are incorrect format strings which have good warnings and can
be fixed easily.
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-03 14:19 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, Theodore Tso, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, 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,
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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <aabpPQxCTweoTp8Z@infradead.org>
On Tue, 2026-03-03 at 05:59 -0800, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> > On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > > overlook the bikeshed's color in this instance?
> > >
> > > So why add it in the first place?
> >
> > Bisectability. The first version I did of this would have broken the
> > ability to bisect properly across these changes. I don't love the
> > "churn" here either, but this should be cleanly bisectable.
>
> What do you need to bisect in format string changes? Splitting
> every variable type change outside of the main i_ino out - sure.
> But bisecting that "change to u64 in ext4" really broke ext4 and
> not "change to u64" is not very useful. Commits should do one
> well defined thing. Adding a weird transition layer for a format
> thing that just gets dropped is not one well defined thing.
In the middle stages of the series, you will get warnings or errors on
32-bit hosts when i_ino's type doesn't match what the format string
expects.
There are really only three options here:
1/ Do (almost) all of the changes in one giant patch
2/ Accept that the build may break during the interim stages
3/ This series: using a typedef and macro to work around the breakage
until the type can be changed, at the expense of some extra churn in
the codebase
3 seems like the lesser evil.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 13:59 UTC (permalink / raw)
To: Jeff Layton
Cc: Christoph Hellwig, Darrick J. Wong, Theodore Tso, Alexander Viro,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Matthew Wilcox, Eric Biggers,
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,
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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <19e4e79a59dcfc4c61c8cf263af345d0d7026fc8.camel@kernel.org>
On Tue, Mar 03, 2026 at 08:43:15AM -0500, Jeff Layton wrote:
> On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> > On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > > Like I said to Ted, this is just temporary scaffolding for the change.
> > > The PRIino macro is removed in the end. Given that, perhaps you can
> > > overlook the bikeshed's color in this instance?
> >
> > So why add it in the first place?
>
> Bisectability. The first version I did of this would have broken the
> ability to bisect properly across these changes. I don't love the
> "churn" here either, but this should be cleanly bisectable.
What do you need to bisect in format string changes? Splitting
every variable type change outside of the main i_ino out - sure.
But bisecting that "change to u64 in ext4" really broke ext4 and
not "change to u64" is not very useful. Commits should do one
well defined thing. Adding a weird transition layer for a format
thing that just gets dropped is not one well defined thing.
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-03 13:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, Theodore Tso, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, 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,
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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <aabkBadGzo7IZpSU@infradead.org>
On Tue, 2026-03-03 at 05:37 -0800, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> > Like I said to Ted, this is just temporary scaffolding for the change.
> > The PRIino macro is removed in the end. Given that, perhaps you can
> > overlook the bikeshed's color in this instance?
>
> So why add it in the first place?
Bisectability. The first version I did of this would have broken the
ability to bisect properly across these changes. I don't love the
"churn" here either, but this should be cleanly bisectable.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 13:37 UTC (permalink / raw)
To: Jeff Layton
Cc: Darrick J. Wong, Theodore Tso, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, 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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <33228005140684201de2ca0c157441d3b6a06413.camel@kernel.org>
On Tue, Mar 03, 2026 at 05:53:39AM -0500, Jeff Layton wrote:
> Like I said to Ted, this is just temporary scaffolding for the change.
> The PRIino macro is removed in the end. Given that, perhaps you can
> overlook the bikeshed's color in this instance?
So why add it in the first place?
^ permalink raw reply
* Re: [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Christoph Hellwig @ 2026-03-03 13:36 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Theodore Tso, Jeff Layton, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dan Williams, Matthew Wilcox, Eric Biggers, 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,
Eric Paris, Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <20260303042546.GF13868@frogsfrogsfrogs>
On Mon, Mar 02, 2026 at 08:25:46PM -0800, Darrick J. Wong wrote:
> > That being said, the userspace PRIu64, et. al macros are complete
> > format specifiers, not just a length modifier. And I think this
> > results in less ugly format specifiers in our kernel code.
>
> Yeah, I don't like "ino=%" PRIino "u, lolz\n" either. I'd rather have
> the whole format in the PRIino definition -- it /is/ unsigned long
> after all.
Just drop the bloody macro and the pointless micro-splitting of the
change. After this the inode is always 64-bit and we can just use
normal ll specifiers without messing things up.
^ permalink raw reply
* Re: LSM namespacing API
From: Stephen Smalley @ 2026-03-03 13:30 UTC (permalink / raw)
To: Paul Moore, Ondrej Mosnacek; +Cc: linux-security-module, selinux, John Johansen
In-Reply-To: <CAHC9VhTeVs7kS9hzukukZRfGu6CC6=Dq4KP69tpEtiFpBJ+jOQ@mail.gmail.com>
On Wed, Feb 25, 2026 at 7:05 PM Paul Moore <paul@paul-moore.com> wrote:
> I spent a few hours this afternoon re-reading this thread and tweaking
> the original proposal to address everything discussed. The revised
> proposal is below, with a bit more detail than before, please take a
> look and let us all know what you think ...
>
> * lsm_set_self_attr(LSM_ATTR_CLONE_NEWLSM) and clone(CLONE_NEWLSM)
>
> We would define a new LSM_ATTR flag, LSM_ATTR_CLONE_NEWLSM, which
> could be used with lsm_set_self_attr() to request that an individual
> LSM create a new LSM specific namespace on the next
> clone(CLONE_NEWLSM) call. LSMs may choose to perform various sanity
> and authorization checks at lsm_set_self_attr() time, but they must
> refrain from creating a new LSM namespace until clone() is called.
> LSMs may also want to ensure that any state associated with an
> lsm_set_self_attr(LSM_ATTR_CLONE_NEWLSM) request is not carried across
> an exec() boundary, however, that decision is left to the individual
> LSMs.
>
> We would define a new clone() flag, CLONE_NEWLSM, which would trigger
> a call into the LSM framework to invoke LSM specific callbacks to
> perform namespace actions specified either by the LSM's policy or an
> explicit lsm_set_self_attr(LSM_ATTR_CLONE_NEWLSM) request.
>
> As with the existing LSM_ATTR support, this is strictly an opt-in
> mechanism and individual LSMs are left to handle this request as they
> see fit.
>
> The lsm_get_self_attr() syscall could be used to get the
> LSM_ATTR_CLONE_NEWLSM value(s) for the current process just like any
> other LSM_ATTR flag.
>
> * lsm_set_self_attr(LSM_ATTR_UNSHARE_NEWLSM) and unshare(CLONE_NEWLSM)
>
> This would behave similarly to LSM_ATTR_CLONE_NEWLSM, but the LSM
> namespace changes would take place during an unshare() call as opposed
> to a clone() call. This is kept separate from the
> LSM_ATTR_CLONE_NEWLSM flag because the behaviors are quite different:
> one creates a process with a new LSM namespace set, while the other
> changes the LSM namespace set of a running process.
>
> LSMs are free to implement support for either LSM_ATTR flag, both, or
> none at all.
I think my only caveat here is that your proposal is quite a bit more
complex than what I implemented here:
[1] https://lore.kernel.org/selinux/20251003190959.3288-2-stephen.smalley.work@gmail.com/
[2] https://lore.kernel.org/selinux/20251003191328.3605-1-stephen.smalley.work@gmail.com/
and I'm not sure the extra complexity is worth it.
In particular:
1. Immediately unsharing the namespace upon lsm_set_self_attr() allows
the caller to immediately and unambiguously know if the operation is
supported and allowed, versus having to wait until a later
clone/unshare call and decipher whether any failure is due to the
unsharing of the LSM namespace or something else,
2. Immediately unsharing the namespace upon lsm_set_self_attr() allows
the caller to perform the operation in any desired order relative to
creating a new process or unsharing other namespaces via explicit
ordering of the call with other clone or unshare calls, providing
maximal flexibility/control,
3. We don't need to introduce a new CLONE_* flag at all or introduce
new or changed LSM hooks to clone/unshare,
4. Implementing unshare-like behavior was in fact quite simple for
SELinux namespaces and no more complex than doing so at clone time,
4. Any perceived atomicity benefits of delaying the operation until
the next clone/unshare system call and doing it at the same time as
creating a new process or unsharing another namespace are unclear -
unless we were to change unshare/clone to completely rollback all
changes if any of them fail, they won't actually be atomic and
unshare/clone could fail with an intermediate state left behind.
All that said, I'm willing to wire up the SELinux namespaces
implementation to the proposed interface if someone implements the
necessary plumbing, but I'm not sure it's better.
> * /proc/pid/ns/lsm and setns(CLONE_NEWLSM)
>
> The /proc/pid/ns/lsm file serves as a link/handle to the specific LSM
> namespace set in use for the given process. A process wishing to move
> into the same LSM namespace set as another process can use this
> link/handle (or a pidfd) and setns(CLONE_NEWLSM) to change its own LSM
> namespace set. It is important to note that using setns() it should
> not be possible to change the individual LSMs that are part of the LSM
> namespace set, the calling process' LSM namespace is set to the exact
> same LSM namespace set as the specified process.
>
> Affected LSMs may choose to enforce access controls on the
> setns(CLONE_NEWLSM) operation according to their own policy.
>
> * Policy considerations
>
> The mechanisms above provide for three different scenarios: a new
> process creating a new LSM namespace set (the clone case), an existing
> process creating a new LSM namespace set (the unshare case), and an
> existing process joining an existing LSM namespace set (the setns
> case).
>
> In the clone case a new LSM namespace set will be created when the
> process itself is created. It is up to the individual LSMs to
> properly initialize their own namespaces and load any required
> policies. Since the new LSM namespaces are created at clone() time
> and before exec(), the calling process, or another trusted process
> using a new yet-to-be-finalized API, should be able to configure the
> newly created LSM namespace before exec().
>
> The unshare case is similar to clone because a new LSM namespace set
> is created, but it is a bit more challenging because unshare()
> modifies the calling process's LSM namespace set, not a newly created
> child process'. For simpler LSMs this might not pose a problem, but
> for more complex LSMs, developing meaningful applications that use
> unshare(CLONE_NEWLSM) and properly initialize/setup the new LSM
> namespace set may prove challenging. Developing applications that use
> clone(CLONE_NEWLSM) will likely be much easier.
>
> In the setns case the process joins a properly configured LSM
> namespace set with all necessary LSM policies loaded, there shouldn't
> be any additional LSM setup required (although the work to change the
> individual LSM namespaces on a running process may prove difficult).
>
> --
> paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 016/110] 9p: use PRIino format for i_ino
From: Christian Schoenebeck @ 2026-03-03 11:52 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,
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, Eric Paris,
Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Jeff Layton
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, audit,
linux-bluetooth, linux-can, linux-sctp, bpf, Jeff Layton
In-Reply-To: <20260302-iino-u64-v2-16-e5388800dae0@kernel.org>
On Monday, 2 March 2026 21:24:00 CET Jeff Layton wrote:
> Convert 9p i_ino format strings to use the PRIino format
> macro in preparation for the widening of i_ino via kino_t.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/9p/vfs_addr.c | 4 ++--
> fs/9p/vfs_inode.c | 6 +++---
> fs/9p/vfs_inode_dotl.c | 6 +++---
> 3 files changed, 8 insertions(+), 8 deletions(-)
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
^ permalink raw reply
* Re: [PATCH v2 069/110] 9p: replace PRIino with %llu/%llx format strings
From: Christian Schoenebeck @ 2026-03-03 12:12 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,
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, Eric Paris,
Joerg Reuter, Marcel Holtmann, Johan Hedberg,
Luiz Augusto von Dentz, Oliver Hartkopp, Marc Kleine-Budde,
David Ahern, Neal Cardwell, Steffen Klassert, Herbert Xu,
Remi Denis-Courmont, Marcelo Ricardo Leitner, Xin Long,
Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Jeff Layton
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, audit,
linux-bluetooth, linux-can, linux-sctp, bpf, Jeff Layton
In-Reply-To: <20260302-iino-u64-v2-69-e5388800dae0@kernel.org>
On Monday, 2 March 2026 21:24:53 CET Jeff Layton wrote:
> Now that i_ino is u64 and the PRIino format macro has been removed,
> replace all uses in 9p with the concrete format strings.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/9p/vfs_addr.c | 4 ++--
> fs/9p/vfs_inode.c | 6 +++---
> fs/9p/vfs_inode_dotl.c | 6 +++---
> 3 files changed, 8 insertions(+), 8 deletions(-)
9p uses the following macro to convert the 9p network protocol's QID path from
u64 (all platforms) to ino_t. The 32-bit path of this macro should be dropped
after this change, as it would unnecessarily truncate the value to 32-bit now
[fs/9p/v9fs_vfs.h]:
#if (BITS_PER_LONG == 32)
#define QID2INO(q) ((ino_t) (((q)->path+2) ^ (((q)->path) >> 32)))
#else
#define QID2INO(q) ((ino_t) ((q)->path+2))
#endif
You are not breaking anything, if you happen to send a v3, that would be nice
to be dropped, otherwise we'll handle that on our end later on:
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
I wonder whether that exceeded Claude's context size, or if that's in line
with the prompt specified by you.
/Christian
^ permalink raw reply
* Re: [PATCH v2 007/110] ext4: use PRIino format for i_ino
From: Jeff Layton @ 2026-03-03 11:41 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, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, 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,
audit, linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <eb56qw5rblcnlqupj5lftynq2vts2idha54xpegrfgx45znfuz@mdjzriuawmfn>
On Tue, 2026-03-03 at 12:20 +0100, Jan Kara wrote:
> On Mon 02-03-26 15:23:51, Jeff Layton wrote:
> > Convert ext4 i_ino format strings to use the PRIino format
> > macro in preparation for the widening of i_ino via kino_t.
> >
> > In trace events, change __field(ino_t, ...) to __field(u64, ...)
> > and update TP_printk format strings to %llu/%llx to match the
> > widened field type.
> >
> > Update local variables and function parameters that hold i_ino
> > values from unsigned long to kino_t.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
>
> Two small comments. Otherwise feel free to add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
>
> > diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c
> > index 96ab95167bd6e10ba86e61a60cb0be9fbafe157f..43103816b80ef4901858bcd789acb0ffb2612317 100644
> > --- a/fs/ext4/migrate.c
> > +++ b/fs/ext4/migrate.c
> > @@ -455,7 +455,7 @@ int ext4_ext_migrate(struct inode *inode)
> > * log, so disable fast commits for this transaction.
> > */
> > ext4_fc_mark_ineligible(inode->i_sb, EXT4_FC_REASON_MIGRATE, handle);
> > - goal = (((inode->i_ino - 1) / EXT4_INODES_PER_GROUP(inode->i_sb)) *
> > + goal = (div_u64(inode->i_ino - 1, EXT4_INODES_PER_GROUP(inode->i_sb)) *
>
> Ext4 doesn't support more than 2^32 inodes (due to on-disk format). Thus
> i_ino is always guaranteed to be a number that fits in 32-bits. Thus I'd
> here just type i_ino to (unsigned int) and be done with it like you've done
> it at other places.
>
> ...
>
Thanks. Fixed both places. I ended up casting the above to a u32 since
this patchset has given me a stronger affinity for explicit-width
types.
> > @@ -1823,7 +1823,7 @@ TRACE_EVENT(ext4_journal_start_inode,
> > TP_ARGS(inode, blocks, rsv_blocks, revoke_creds, type, IP),
> >
> > TP_STRUCT__entry(
> > - __field( unsigned long, ino )
> > + __field( u64, ino )
> > __field( dev_t, dev )
> > __field( unsigned long, ip )
> > __field( int, blocks )
> > @@ -1843,9 +1843,10 @@ TRACE_EVENT(ext4_journal_start_inode,
> > ),
> >
> > TP_printk("dev %d,%d blocks %d, rsv_blocks %d, revoke_creds %d,"
> > - " type %d, ino %lu, caller %pS", MAJOR(__entry->dev),
> > + " type %d, ino %llu, caller %pS", MAJOR(__entry->dev),
> > MINOR(__entry->dev), __entry->blocks, __entry->rsv_blocks,
> > - __entry->revoke_creds, __entry->type, __entry->ino,
> > + __entry->revoke_creds, __entry->type,
> > + (unsigned long long) __entry->ino,
>
> Not point in the type cast?
>
> Honza
--
Jeff Layton <jlayton@kernel.org>
^ 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