On 2/11/26 5:37 PM, Steven Rostedt wrote: > On Tue, 10 Feb 2026 12:28:17 +0100 > Petr Pavlu <[email protected]> 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
