linux-toradex.git/fs/tracefs, branch master

Merge tag 'vfs-7.4-rc1.idmap' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

2026-10-20T03:57:49+00:00

Pull vfs idmap constification from Christian Brauner:
 "This makes struct mnt_idmap const throughout the tree.

  A mount's idmapping is immutable. The only thing modified after
  alloc_mnt_idmap() is the reference count and that is hidden behind
  mnt_idmap_get() and mnt_idmap_put(). Everything else only reads from
  it. That is the same model struct cred uses and the idmapping is
  sensitive enough to deserve it.

  The conversion goes bottom up through the vfs{g,u}id and fs{g,u}id
  helpers, the privilege checks, acl, xattr and quota and then every
  inode operation that takes an idmap, so ->permission(), ->getattr(),
  ->setattr(), ->create(), ->mkdir(), ->mknod(), ->symlink(),
  ->rename(), ->tmpfile(), ->get_acl(), ->set_acl() and ->fileattr_set()
  with their implementations in every filesystem, plus the LSM hooks.

  struct vfsmount, struct mount_kattr and struct kstatmount store a
  const pointer and nop_mnt_idmap and invalid_mnt_idmap live in rodata,
  so anything that tries to modify them faults instead of silently
  corrupting the initial idmapping"

* tag 'vfs-7.4-rc1.idmap' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (27 commits)
  fs: make nop_mnt_idmap and invalid_mnt_idmap const
  fs: port mnt_idmap() and file_mnt_idmap() to const mnt_idmap
  fs: port vfs_*() helpers to const mnt_idmap
  fs: port ->setattr() to pass const mnt_idmap
  fs: port ->getattr() to pass const mnt_idmap
  fs: port ->create() to pass const mnt_idmap
  fs: port ->symlink() to pass const mnt_idmap
  fs: port ->mkdir() to pass const mnt_idmap
  fs: port ->rename() to pass const mnt_idmap
  fs: port ->mknod() to pass const mnt_idmap
  fs: port ->tmpfile() to pass const mnt_idmap
  fs: port ->get_acl() to pass const mnt_idmap
  fs: port ->set_acl() to pass const mnt_idmap
  fs: port ->fileattr_set() to pass const mnt_idmap
  fs: port xattr to const mnt_idmap
  fs: port ->permission() to pass const mnt_idmap
  fs: port acl to const mnt_idmap
  fs: port inode_init_owner() to const mnt_idmap
  fs: port inode_owner_or_capable() to const mnt_idmap
  fs: port privilege checking helpers to const mnt_idmap
  ...

eventfs: free the eventfs_inode after an rcu grace period too

2026-10-14T20:08:03+00:00

tracefs_d_revalidate() reads ->is_freed of the eventfs_inode that
dentry->d_fsdata points to, and ->d_revalidate() is called in rcu
pathwalk mode with nothing but rcu_read_lock() held. The dentry itself
stays around for such a walker, but tracefs_d_release() drops its
reference to the eventfs_inode when the dentry is killed, and
release_ei() then frees it after a grace period of eventfs_srcu. An
SRCU grace period doesn't wait for rcu_read_lock() sections, so the
walker can read an eventfs_inode that is already gone.

With a pathwalk held up in tracefs_d_revalidate() while the dentry goes
away:

  BUG: KASAN: slab-use-after-free in tracefs_d_revalidate+0x76/0x90
  Read of size 1 at addr ff1100010152d8d0 by task walker/97
  Call Trace:
   
   tracefs_d_revalidate+0x76/0x90
   lookup_fast+0x320/0x640
   path_lookupat+0x160/0xb00
   filename_lookup+0x1f1/0x5b0
   vfs_statx+0xd7/0x3b0
   vfs_fstatat+0x4d/0x90
   __do_sys_newfstatat+0xa0/0x100
   do_syscall_64+0x10e/0x5e0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  [...]
  Allocated by task 1:
   __kmalloc_cache_noprof+0x249/0x560
   eventfs_create_dir+0x7a/0x590
   event_create_dir+0x2fb/0xcf0
   trace_add_event_call+0xbf/0x150
  [...]
  Freed by task 11:
   kfree+0x1db/0x5b0
   srcu_invoke_callbacks+0x3a3/0x620
   process_one_work+0x937/0x1810
   worker_thread+0x4f1/0xd60

Before commit 8e556432477e ("eventfs: Use SRCU for freeing
eventfs_inodes") release_ei() used call_rcu(), which covered the walker,
while eventfs_iterate() needs the SRCU grace period. Wait for both and
chain call_rcu() from the SRCU callback.

Fixes: 8e556432477e ("eventfs: Use SRCU for freeing eventfs_inodes")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-4-7446d2d335e6@kernel.org
Signed-off-by: Christian Brauner (Amutable)

fs: port ->setattr() to pass const mnt_idmap

2026-09-23T07:19:51+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-24-54ccd48e100b@kernel.org
Acked-by: Paul Moore 
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)

fs: port ->getattr() to pass const mnt_idmap

2026-09-23T07:19:51+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-23-54ccd48e100b@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)

fs: port ->mkdir() to pass const mnt_idmap

2026-09-23T07:19:50+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-20-54ccd48e100b@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)

fs: port ->permission() to pass const mnt_idmap

2026-09-23T07:19:49+00:00

Convert to const struct mnt_idmap.

A mount's idmapping is immutable. The only thing that is allowed to be
modified afterwards is the reference count and that is hidden behind
mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads
from the idmapping. This is the same model that struct cred uses and the
idmapping is also rather sensitive.

So make the idmap argument const wherever we can. The conversion is done
from the bottom up so callers can continue to pass a non-const pointer
to a const parameter until the conversion is finished.

No functional changes.

Link: https://patch.msgid.link/20260901-work-idmap-const-v1-12-54ccd48e100b@kernel.org
Acked-by: Paul Moore 
Reviewed-by: Jan Kara 
Reviewed-by: Seth Forshee 
Signed-off-by: Christian Brauner (Amutable)

eventfs: Initialize ei->children and ei->list in init_ei()

2026-08-24T20:42:57+00:00

eventfs_create_dir() allocates the eventfs_inode and initializes it with
init_ei(). But this does not initialize the eventfs_inode list_heads. If
the eventfs_create_dir() fails due to memory pressure, it will call
free_ei() before it initialized the lists, and that checks to make sure
the eventfs_inode has no children. But because the list wasn't
initialized, it will give a false warning.

Fix it by moving the list initialization into init_ei().

Cc: stable@vger.kernel.org
Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use eventfs_inode")
Reported-by: syzbot+3ef80b4ed02226d04a06@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3ef80b4ed02226d04a06
Link: https://patch.msgid.link/20260824144653.54044-1-kartikey406@gmail.com
Signed-off-by: Deepanshu Kartikey 
[ Rewrote change log ]
Signed-off-by: Steven Rostedt

Merge tag 'tracefs-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

2026-08-19T21:18:45+00:00

Pull tracefs updates from Steven Rostedt:

 - Define event fields before directory creation

   Move the event_define_fields() call in event_create_dir() before the
   eventfs directory creation. Previously, a failure after directory
   creation wouldn't clean up eventfs_inode because the error path
   didn't call eventfs_remove_dir(). This eliminates the need to clean
   up the eventfs directories if event_define_fields() fails.

 - Add warning for out of bounds pos in __eventfs_iterate()

   Sashiko complains about the ctx->pos causing issues if it is less
   than 2 or greater than MAX_INT in __eventfs_iterate(). The thing is,
   the logic prevents that from happening. But to make Sashiko happy,
   add a WARN_ON() and exit safely if the function ever does get input
   that is out of the range the function expects.

* tag 'tracefs-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  eventfs: Add warning for out of bounds pos in __eventfs_iterate()
  eventfs: Define event fields before directory creation

eventfs: Add warning for out of bounds pos in __eventfs_iterate()

2026-08-14T14:09:27+00:00

Sashiko has complained about out of bounds issues if ctx->pos isn't what
is expected in __eventfs_iterate()[1]. This would be an issue if the logic
that calls __eventfs_iterate() didn't already prevent the code from going
out of bounds.

The issue Sashiko brings up is if a user uses lseek64() to put in a
position like 0x100000000 which will overflow the integer used to iterate
the files. This should never be an issue because both tracefs and eventfs
uses the default "maxbytes" for its superblock "s_maxbytes" field which is
defined as:

  fs/super.c:     s->s_maxbytes = MAX_NON_LFS;
  include/linux/fs.h:#define      MAX_NON_LFS     ((1UL<<31) - 1)

Where MAX_NON_LFS turns into 0x7fffffff.

Testing this with code to try to pass 0x100000000 to lseek64() to a
eventfs directory returns -EINVAL.

But relying on logic for the integrity of a function is not very robust.
Add a WARN_ON_ONCE() in case the ctx->pos is out of the expected range.

[1] https://sashiko.dev/#/patchset/20260810160708.3460a2fd%40gandalf.local.home

Link: https://patch.msgid.link/20260810175928.5f4d9d5c@gandalf.local.home
Signed-off-by: Steven Rostedt

eventfs: Use children field for rcu head and add memory barriers

2026-08-08T14:36:05+00:00

When an eventfs inode is freed, it sets ei->is_freed and then uses its
ei->list to add it to the srcu link list as the list field is a union with
the rcu list head. As the ei->list is used to iterate over an SRCU
protected list without taking the eventfs_mutex, there's nothing stopping
the iteration over that list to see the ei->rcu instead of the ei->list
and it will read a corrupt target.

To fix this, change the union of the rcu list head with the children list.
On freeing the eventfs inode, set the is_free and execute a smp_wmb()
before adding the eventfs inode to the SRCU list.

On iteration of the ei->children list, at the start, execute a smp_rmb()
and then read the is_freed of the ei to see if the children list is still
valid. If is_freed is set, then the ei_child read is not valid and the
loop should exit immediately.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260808094215.4252430d@robin
Fixes: 704f960dbee2f ("eventfs: Read ei->entries before ei->children in eventfs_iterate()")
Reported-by: Sashiko 
Closes: https://sashiko.dev/#/patchset/20260806022719.375354-1-shuangpeng.kernel%40gmail.com
Reviewed-by: Masami Hiramatsu (Google) 
Signed-off-by: Steven Rostedt