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

[Petr Pavlu]

On 2/11/26 5:37 PM, Steven Rostedt wrote:
> On Tue, 10 Feb 2026 12:28:17 +0100
> Petr Pavlu <petr.pavlu@xxxxxxxx> 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.

I think one could argue that handling all event files in the same way is
less complex. It would also allow for a minor simplification where
event_callback() would no longer need to modify the data pointer and
eventfs then wouldn't need to pass it down to lookup_file() because it
could always use the default ei->data.

However, this is all minor and I can see your point of view. I'll drop
this patch.

-- 
Thanks,
Petr