Re: [PATCH 2/5] tracing: Fix checking of freed trace_event_file for id files

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 10 Feb 2026 12:28:17 +0100
Petr Pavlu <petr.pavlu@suse.com> wrote:

> The code for reading an event id currently uses file->f_inode->i_private to
> store the value of trace_event_file->event_call->event.type, unlike all
> other event files which use it to store a pointer to the associated
> trace_event_file data. The event_id_read() function retrieves this id value
> from i_private and checks if it is non-0/NULL to determine whether the
> event is still valid. This approach worked in the past when
> remove_event_file_dir() would set i_private to NULL for all files in an
> event directory upon removal. However, with the introduction of eventfs,
> i_private is assigned when an eventfs inode is allocated and remains set

> throughout its lifetime. As a result, event_id_read() may fail to detect
> that an event is being removed.

Who cares? It's just an id. If the event is being removed, there's
nothing wrong with still returning its id. The code currently is very
simple, I don't want to make it complex for something nobody cares
about.

-- Steve


> 
> Fix this issue by changing the event id file to use i_private to store
> a trace_event_file pointer and utilize event_file_file() to check for the
> EVENT_FILE_FL_FREED flag.