<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/tracefs/internal.h, branch v6.19.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-08-08T00:27:49+00:00</updated>
<entry>
<title>tracefs: Use generic inode RCU for synchronizing freeing</title>
<updated>2024-08-08T00:27:49+00:00</updated>
<author>
<name>Steven Rostedt</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2024-08-07T22:54:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0b6743bd60a56a701070b89fb80c327a44b7b3e2'/>
<id>urn:sha1:0b6743bd60a56a701070b89fb80c327a44b7b3e2</id>
<content type='text'>
With structure layout randomization enabled for 'struct inode' we need to
avoid overlapping any of the RCU-used / initialized-only-once members,
e.g. i_lru or i_sb_list to not corrupt related list traversals when making
use of the rcu_head.

For an unlucky structure layout of 'struct inode' we may end up with the
following splat when running the ftrace selftests:

[&lt;...&gt;] list_del corruption, ffff888103ee2cb0-&gt;next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])
[&lt;...&gt;] ------------[ cut here ]------------
[&lt;...&gt;] kernel BUG at lib/list_debug.c:54!
[&lt;...&gt;] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[&lt;...&gt;] CPU: 3 PID: 2550 Comm: mount Tainted: G                 N  6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65
[&lt;...&gt;] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
[&lt;...&gt;] RIP: 0010:[&lt;ffffffff84656018&gt;] __list_del_entry_valid_or_report+0x138/0x3e0
[&lt;...&gt;] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff &lt;0f&gt; 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f
[&lt;...&gt;] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283
[&lt;...&gt;] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000
[&lt;...&gt;] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001
[&lt;...&gt;] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25
[&lt;...&gt;] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d
[&lt;...&gt;] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000
[&lt;...&gt;] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]
[&lt;...&gt;] RDX: __list_del_entry_valid_or_report+0x108/0x3e0
[&lt;...&gt;] RSI: __func__.47+0x4340/0x4400
[&lt;...&gt;] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]
[&lt;...&gt;] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]
[&lt;...&gt;] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]
[&lt;...&gt;] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]
[&lt;...&gt;] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]
[&lt;...&gt;] FS:  00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000
[&lt;...&gt;] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[&lt;...&gt;] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0
[&lt;...&gt;] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[&lt;...&gt;] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[&lt;...&gt;] ASID: 0003
[&lt;...&gt;] Stack:
[&lt;...&gt;]  ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0
[&lt;...&gt;]  ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f
[&lt;...&gt;]  0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392
[&lt;...&gt;] Call Trace:
[&lt;...&gt;]  &lt;TASK&gt;
[&lt;...&gt;]  [&lt;ffffffff818a2315&gt;] ? lock_release+0x175/0x380 fffffe80416afaf0
[&lt;...&gt;]  [&lt;ffffffff8248b392&gt;] list_lru_del+0x152/0x740 fffffe80416afb48
[&lt;...&gt;]  [&lt;ffffffff8248ba93&gt;] list_lru_del_obj+0x113/0x280 fffffe80416afb88
[&lt;...&gt;]  [&lt;ffffffff8940fd19&gt;] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90
[&lt;...&gt;]  [&lt;ffffffff8295b244&gt;] iput_final+0x1c4/0x9a0 fffffe80416afbb8
[&lt;...&gt;]  [&lt;ffffffff8293a52b&gt;] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8
[&lt;...&gt;]  [&lt;ffffffff8293fefc&gt;] __dentry_kill+0x23c/0xf00 fffffe80416afc40
[&lt;...&gt;]  [&lt;ffffffff8953a85f&gt;] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48
[&lt;...&gt;]  [&lt;ffffffff82949ce5&gt;] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70
[&lt;...&gt;]  [&lt;ffffffff82949b71&gt;] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78
[&lt;...&gt;]  [&lt;ffffffff82949da8&gt;] shrink_dentry_list+0x288/0x760 fffffe80416afc80
[&lt;...&gt;]  [&lt;ffffffff8294ae75&gt;] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8
[&lt;...&gt;]  [&lt;ffffffff8953a7c3&gt;] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0
[&lt;...&gt;]  [&lt;ffffffff8294ad20&gt;] ? do_one_tree+0x140/0x140 fffffe80416afcf8
[&lt;...&gt;]  [&lt;ffffffff82997349&gt;] ? do_remount+0x329/0xa00 fffffe80416afd18
[&lt;...&gt;]  [&lt;ffffffff83ebf7a1&gt;] ? security_sb_remount+0x81/0x1c0 fffffe80416afd38
[&lt;...&gt;]  [&lt;ffffffff82892096&gt;] reconfigure_super+0x856/0x14e0 fffffe80416afd70
[&lt;...&gt;]  [&lt;ffffffff815d1327&gt;] ? ns_capable_common+0xe7/0x2a0 fffffe80416afd90
[&lt;...&gt;]  [&lt;ffffffff82997436&gt;] do_remount+0x416/0xa00 fffffe80416afdd0
[&lt;...&gt;]  [&lt;ffffffff829b2ba4&gt;] path_mount+0x5c4/0x900 fffffe80416afe28
[&lt;...&gt;]  [&lt;ffffffff829b25e0&gt;] ? finish_automount+0x13a0/0x13a0 fffffe80416afe60
[&lt;...&gt;]  [&lt;ffffffff82903812&gt;] ? user_path_at_empty+0xb2/0x140 fffffe80416afe88
[&lt;...&gt;]  [&lt;ffffffff829b2ff5&gt;] do_mount+0x115/0x1c0 fffffe80416afeb8
[&lt;...&gt;]  [&lt;ffffffff829b2ee0&gt;] ? path_mount+0x900/0x900 fffffe80416afed8
[&lt;...&gt;]  [&lt;ffffffff8272461c&gt;] ? __kasan_check_write+0x1c/0xa0 fffffe80416afee0
[&lt;...&gt;]  [&lt;ffffffff829b31cf&gt;] __do_sys_mount+0x12f/0x280 fffffe80416aff30
[&lt;...&gt;]  [&lt;ffffffff829b36cd&gt;] __x64_sys_mount+0xcd/0x2e0 fffffe80416aff70
[&lt;...&gt;]  [&lt;ffffffff819f8818&gt;] ? syscall_trace_enter+0x218/0x380 fffffe80416aff88
[&lt;...&gt;]  [&lt;ffffffff8111655e&gt;] x64_sys_call+0x5d5e/0x6720 fffffe80416affa8
[&lt;...&gt;]  [&lt;ffffffff8952756d&gt;] do_syscall_64+0xcd/0x3c0 fffffe80416affb8
[&lt;...&gt;]  [&lt;ffffffff8100119b&gt;] entry_SYSCALL_64_safe_stack+0x4c/0x87 fffffe80416affe8
[&lt;...&gt;]  &lt;/TASK&gt;
[&lt;...&gt;]  &lt;PTREGS&gt;
[&lt;...&gt;] RIP: 0033:[&lt;00006dcb382ff66a&gt;] vm_area_struct[mount 2550 2550 file 6dcb38225000-6dcb3837e000 22 55(read|exec|mayread|mayexec)]+0x0/0xb8 [userland map]
[&lt;...&gt;] Code: 48 8b 0d 29 18 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d f6 17 0d 00 f7 d8 64 89 01 48
[&lt;...&gt;] RSP: 002b:0000763d68192558 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
[&lt;...&gt;] RAX: ffffffffffffffda RBX: 00006dcb38433264 RCX: 00006dcb382ff66a
[&lt;...&gt;] RDX: 000017c3e0d11210 RSI: 000017c3e0d1a5a0 RDI: 000017c3e0d1ae70
[&lt;...&gt;] RBP: 000017c3e0d10fb0 R08: 000017c3e0d11260 R09: 00006dcb383d1be0
[&lt;...&gt;] R10: 000000000020002e R11: 0000000000000246 R12: 0000000000000000
[&lt;...&gt;] R13: 000017c3e0d1ae70 R14: 000017c3e0d11210 R15: 000017c3e0d10fb0
[&lt;...&gt;] RBX: vm_area_struct[mount 2550 2550 file 6dcb38433000-6dcb38434000 5b 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] RCX: vm_area_struct[mount 2550 2550 file 6dcb38225000-6dcb3837e000 22 55(read|exec|mayread|mayexec)]+0x0/0xb8 [userland map]
[&lt;...&gt;] RDX: vm_area_struct[mount 2550 2550 anon 17c3e0d0f000-17c3e0d31000 17c3e0d0f 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] RSI: vm_area_struct[mount 2550 2550 anon 17c3e0d0f000-17c3e0d31000 17c3e0d0f 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] RDI: vm_area_struct[mount 2550 2550 anon 17c3e0d0f000-17c3e0d31000 17c3e0d0f 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] RBP: vm_area_struct[mount 2550 2550 anon 17c3e0d0f000-17c3e0d31000 17c3e0d0f 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] RSP: vm_area_struct[mount 2550 2550 anon 763d68173000-763d68195000 7ffffffdd 100133(read|write|mayread|maywrite|growsdown|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] R08: vm_area_struct[mount 2550 2550 anon 17c3e0d0f000-17c3e0d31000 17c3e0d0f 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] R09: vm_area_struct[mount 2550 2550 file 6dcb383d1000-6dcb383d3000 1cd 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] R13: vm_area_struct[mount 2550 2550 anon 17c3e0d0f000-17c3e0d31000 17c3e0d0f 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] R14: vm_area_struct[mount 2550 2550 anon 17c3e0d0f000-17c3e0d31000 17c3e0d0f 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;] R15: vm_area_struct[mount 2550 2550 anon 17c3e0d0f000-17c3e0d31000 17c3e0d0f 100033(read|write|mayread|maywrite|account)]+0x0/0xb8 [userland map]
[&lt;...&gt;]  &lt;/PTREGS&gt;
[&lt;...&gt;] Modules linked in:
[&lt;...&gt;] ---[ end trace 0000000000000000 ]---

The list debug message as well as RBX's symbolic value point out that the
object in question was allocated from 'tracefs_inode_cache' and that the
list's '-&gt;next' member is at offset 0. Dumping the layout of the relevant
parts of 'struct tracefs_inode' gives the following:

  struct tracefs_inode {
    union {
      struct inode {
        struct list_head {
          struct list_head * next;                    /*     0     8 */
          struct list_head * prev;                    /*     8     8 */
        } i_lru;
        [...]
      } vfs_inode;
      struct callback_head {
        void (*func)(struct callback_head *);         /*     0     8 */
        struct callback_head * next;                  /*     8     8 */
      } rcu;
    };
    [...]
  };

Above shows that 'vfs_inode.i_lru' overlaps with 'rcu' which will
destroy the 'i_lru' list as soon as the 'rcu' member gets used, e.g. in
call_rcu() or later when calling the RCU callback. This will disturb
concurrent list traversals as well as object reuse which assumes these
list heads will keep their integrity.

For reproduction, the following diff manually overlays 'i_lru' with
'rcu' as, otherwise, one would require some good portion of luck for
gambling an unlucky RANDSTRUCT seed:

  --- a/include/linux/fs.h
  +++ b/include/linux/fs.h
  @@ -629,6 +629,7 @@ struct inode {
   	umode_t			i_mode;
   	unsigned short		i_opflags;
   	kuid_t			i_uid;
  +	struct list_head	i_lru;		/* inode LRU list */
   	kgid_t			i_gid;
   	unsigned int		i_flags;

  @@ -690,7 +691,6 @@ struct inode {
   	u16			i_wb_frn_avg_time;
   	u16			i_wb_frn_history;
   #endif
  -	struct list_head	i_lru;		/* inode LRU list */
   	struct list_head	i_sb_list;
   	struct list_head	i_wb_list;	/* backing dev writeback list */
   	union {

The tracefs inode does not need to supply its own RCU delayed destruction
of its inode. The inode code itself offers both a "destroy_inode()"
callback that gets called when the last reference of the inode is
released, and the "free_inode()" which is called after a RCU
synchronization period from the "destroy_inode()".

The tracefs code can unlink the inode from its list in the destroy_inode()
callback, and the simply free it from the free_inode() callback. This
should provide the same protection.

Link: https://lore.kernel.org/all/20240807115143.45927-3-minipli@grsecurity.net/

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Ajay Kaher &lt;ajay.kaher@broadcom.com&gt;
Cc: Ilkka =?utf-8?b?TmF1bGFww6TDpA==?= &lt;digirigawa@gmail.com&gt;
Link: https://lore.kernel.org/20240807185402.61410544@gandalf.local.home
Fixes: baa23a8d4360 ("tracefs: Reset permissions on remount if permissions are options")
Reported-by: Mathias Krause &lt;minipli@grsecurity.net&gt;
Reported-by: Brad Spengler &lt;spender@grsecurity.net&gt;
Suggested-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>eventfs: Do not differentiate the toplevel events directory</title>
<updated>2024-05-04T08:25:37+00:00</updated>
<author>
<name>Steven Rostedt (Google)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2024-05-02T20:08:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d53891d348ac3eceaf48f4732a1f4f5c0e0a55ce'/>
<id>urn:sha1:d53891d348ac3eceaf48f4732a1f4f5c0e0a55ce</id>
<content type='text'>
The toplevel events directory is really no different than the events
directory of instances. Having the two be different caused
inconsistencies and made it harder to fix the permissions bugs.

Make all events directories act the same.

Link: https://lore.kernel.org/linux-trace-kernel/20240502200905.846448710@goodmis.org

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Fixes: 8186fff7ab649 ("tracefs/eventfs: Use root and instance inodes as default ownership")
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracefs: Reset permissions on remount if permissions are options</title>
<updated>2024-05-04T08:25:37+00:00</updated>
<author>
<name>Steven Rostedt (Google)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2024-05-02T20:08:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=baa23a8d4360d981a49913841a726edede5cdd54'/>
<id>urn:sha1:baa23a8d4360d981a49913841a726edede5cdd54</id>
<content type='text'>
There's an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode's permission if they were never set by the user. If the user
sets the permissions, then a flag is set and the permissions are saved via
the inode (for tracefs files) or an internal attribute field (for
eventfs).

But if a remount happens that specify the permissions, all the files that
were not changed by the user gets updated, but the ones that were are not.
If the user were to remount the file system with a given permission, then
all files and directories within that file system should be updated.

This can cause security issues if a file's permission was updated but the
admin forgot about it. They could incorrectly think that remounting with
permissions set would update all files, but miss some.

For example:

 # cd /sys/kernel/tracing
 # chgrp 1002 current_tracer
 # ls -l
[..]
 -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb
 -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb
 -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb
 -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer
 -rw-r-----  1 root root 0 May  1 21:25 dynamic_events
 -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info
 -r--r-----  1 root root 0 May  1 21:25 enabled_functions

Where current_tracer now has group "lkp".

 # mount -o remount,gid=1001 .
 # ls -l
 -rw-r-----  1 root tracing 0 May  1 21:25 buffer_size_kb
 -rw-r-----  1 root tracing 0 May  1 21:25 buffer_subbuf_size_kb
 -r--r-----  1 root tracing 0 May  1 21:25 buffer_total_size_kb
 -rw-r-----  1 root lkp     0 May  1 21:25 current_tracer
 -rw-r-----  1 root tracing 0 May  1 21:25 dynamic_events
 -r--r-----  1 root tracing 0 May  1 21:25 dyn_ftrace_total_info
 -r--r-----  1 root tracing 0 May  1 21:25 enabled_functions

Everything changed but the "current_tracer".

Add a new link list that keeps track of all the tracefs_inodes which has
the permission flags that tell if the file/dir should use the root inode's
permission or not. Then on remount, clear all the flags so that the
default behavior of using the root inode's permission is done for all
files and directories.

Link: https://lore.kernel.org/linux-trace-kernel/20240502200905.529542160@goodmis.org

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Fixes: 8186fff7ab649 ("tracefs/eventfs: Use root and instance inodes as default ownership")
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>eventfs: Create eventfs_root_inode to store dentry</title>
<updated>2024-03-17T11:58:52+00:00</updated>
<author>
<name>Steven Rostedt (Google)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2024-02-01T15:34:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c3137ab6318d56370dd5541ebf027ddfc0c8557c'/>
<id>urn:sha1:c3137ab6318d56370dd5541ebf027ddfc0c8557c</id>
<content type='text'>
Only the root "events" directory stores a dentry. There's no reason to
hold a dentry pointer for every eventfs_inode as it is never set except
for the root "events" eventfs_inode.

Create a eventfs_root_inode structure that holds the events_dir dentry.
The "events" eventfs_inode *is* special, let it have its own descriptor.

Link: https://lore.kernel.org/linux-trace-kernel/20240201161617.658992558@goodmis.org

Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Cc: Ajay Kaher &lt;ajay.kaher@broadcom.com&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>eventfs: Restructure eventfs_inode structure to be more condensed</title>
<updated>2024-02-01T16:53:52+00:00</updated>
<author>
<name>Steven Rostedt (Google)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2024-02-01T15:34:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=264424dfdd5cbd92bc5b5ddf93944929fc877fac'/>
<id>urn:sha1:264424dfdd5cbd92bc5b5ddf93944929fc877fac</id>
<content type='text'>
Some of the eventfs_inode structure has holes in it. Rework the structure
to be a bit more condensed, and also remove the no longer used llist
field.

Link: https://lore.kernel.org/linux-trace-kernel/20240201161617.002321438@goodmis.org

Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Cc: Ajay Kaher &lt;ajay.kaher@broadcom.com&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>eventfs: Get rid of dentry pointers without refcounts</title>
<updated>2024-02-01T15:31:17+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-01-31T18:49:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=43aa6f97c2d03a52c1ddb86768575fc84344bdbb'/>
<id>urn:sha1:43aa6f97c2d03a52c1ddb86768575fc84344bdbb</id>
<content type='text'>
The eventfs inode had pointers to dentries (and child dentries) without
actually holding a refcount on said pointer.  That is fundamentally
broken, and while eventfs tried to then maintain coherence with dentries
going away by hooking into the '.d_iput' callback, that doesn't actually
work since it's not ordered wrt lookups.

There were two reasonms why eventfs tried to keep a pointer to a dentry:

 - the creation of a 'events' directory would actually have a stable
   dentry pointer that it created with tracefs_start_creating().

   And it needed that dentry when tearing it all down again in
   eventfs_remove_events_dir().

   This use is actually ok, because the special top-level events
   directory dentries are actually stable, not just a temporary cache of
   the eventfs data structures.

 - the 'eventfs_inode' (aka ei) needs to stay around as long as there
   are dentries that refer to it.

   It then used these dentry pointers as a replacement for doing
   reference counting: it would try to make sure that there was only
   ever one dentry associated with an event_inode, and keep a child
   dentry array around to see which dentries might still refer to the
   parent ei.

This gets rid of the invalid dentry pointer use, and renames the one
valid case to a different name to make it clear that it's not just any
random dentry.

The magic child dentry array that is kind of a "reverse reference list"
is simply replaced by having child dentries take a ref to the ei.  As
does the directory dentries.  That makes the broken use case go away.

Link: https://lore.kernel.org/linux-trace-kernel/202401291043.e62e89dc-oliver.sang@intel.com/
Link: https://lore.kernel.org/linux-trace-kernel/20240131185513.280463000@goodmis.org

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Cc: Ajay Kaher &lt;ajay.kaher@broadcom.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Fixes: c1504e510238 ("eventfs: Implement eventfs dir creation functions")
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>eventfs: Clean up dentry ops and add revalidate function</title>
<updated>2024-02-01T15:31:17+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-01-31T18:49:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8dce06e98c70a7fcbb4bca7d90faf40522e65c58'/>
<id>urn:sha1:8dce06e98c70a7fcbb4bca7d90faf40522e65c58</id>
<content type='text'>
In order for the dentries to stay up-to-date with the eventfs changes,
just add a 'd_revalidate' function that checks the 'is_freed' bit.

Also, clean up the dentry release to actually use d_release() rather
than the slightly odd d_iput() function.  We don't care about the inode,
all we want to do is to get rid of the refcount to the eventfs data
added by dentry-&gt;d_fsdata.

It would probably be cleaner to make eventfs its own filesystem, or at
least set its own dentry ops when looking up eventfs files.  But as it
is, only eventfs dentries use d_fsdata, so we don't really need to split
these things up by use.

Another thing that might be worth doing is to make all eventfs lookups
mark their dentries as not worth caching.  We could do that with
d_delete(), but the DCACHE_DONTCACHE flag would likely be even better.

As it is, the dentries are all freeable, but they only tend to get freed
at memory pressure rather than more proactively.  But that's a separate
issue.

Link: https://lore.kernel.org/linux-trace-kernel/202401291043.e62e89dc-oliver.sang@intel.com/
Link: https://lore.kernel.org/linux-trace-kernel/20240131185513.124644253@goodmis.org

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Cc: Ajay Kaher &lt;ajay.kaher@broadcom.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Fixes: c1504e510238 ("eventfs: Implement eventfs dir creation functions")
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>eventfs: Remove unused d_parent pointer field</title>
<updated>2024-02-01T15:31:17+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-01-31T18:49:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=408600be78cdb8c650a97ecc7ff411cb216811b5'/>
<id>urn:sha1:408600be78cdb8c650a97ecc7ff411cb216811b5</id>
<content type='text'>
It's never used

Link: https://lore.kernel.org/linux-trace-kernel/202401291043.e62e89dc-oliver.sang@intel.com/
Link: https://lore.kernel.org/linux-trace-kernel/20240131185512.961772428@goodmis.org

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Cc: Ajay Kaher &lt;ajay.kaher@broadcom.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Fixes: c1504e510238 ("eventfs: Implement eventfs dir creation functions")
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracefs: dentry lookup crapectomy</title>
<updated>2024-02-01T15:30:33+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-02-01T04:32:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=49304c2b93e4f7468b51ef717cbe637981397115'/>
<id>urn:sha1:49304c2b93e4f7468b51ef717cbe637981397115</id>
<content type='text'>
The dentry lookup for eventfs files was very broken, and had lots of
signs of the old situation where the filesystem names were all created
statically in the dentry tree, rather than being looked up dynamically
based on the eventfs data structures.

You could see it in the naming - how it claimed to "create" dentries
rather than just look up the dentries that were given it.

You could see it in various nonsensical and very incorrect operations,
like using "simple_lookup()" on the dentries that were passed in, which
only results in those dentries becoming negative dentries.  Which meant
that any other lookup would possibly return ENOENT if it saw that
negative dentry before the data was then later filled in.

You could see it in the immense amount of nonsensical code that didn't
actually just do lookups.

Link: https://lore.kernel.org/linux-trace-kernel/202401291043.e62e89dc-oliver.sang@intel.com/
Link: https://lore.kernel.org/linux-trace-kernel/20240131233227.73db55e1@gandalf.local.home

Cc: stable@vger.kernel.org
Cc: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Ajay Kaher &lt;ajay.kaher@broadcom.com&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Fixes: c1504e510238 ("eventfs: Implement eventfs dir creation functions")
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracefs: Zero out the tracefs_inode when allocating it</title>
<updated>2024-01-31T19:15:47+00:00</updated>
<author>
<name>Steven Rostedt (Google)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2024-01-31T18:49:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d81786f53aec14fd4d56263145a0635afbc64617'/>
<id>urn:sha1:d81786f53aec14fd4d56263145a0635afbc64617</id>
<content type='text'>
eventfs uses the tracefs_inode and assumes that it's already initialized
to zero. That is, it doesn't set fields to zero (like ti-&gt;private) after
getting its tracefs_inode. This causes bugs due to stale values.

Just initialize the entire structure to zero on allocation so there isn't
any more surprises.

This is a partial fix to access to ti-&gt;private. The assignment still needs
to be made before the dentry is instantiated.

Link: https://lore.kernel.org/linux-trace-kernel/20240131185512.315825944@goodmis.org

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Christian Brauner &lt;brauner@kernel.org&gt;
Cc: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Cc: Ajay Kaher &lt;ajay.kaher@broadcom.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use eventfs_inode")
Reported-by: kernel test robot &lt;oliver.sang@intel.com&gt;
Closes: https://lore.kernel.org/oe-lkp/202401291043.e62e89dc-oliver.sang@intel.com
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
</feed>
