Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] tracing: user_events broken by fields_array[0].type check --
commit e8b9d44518a8f72216cba6b41f5a36c08fdcef3c Author: Haoran Wang <[email protected]> tracing: reject trace events with an empty TP_STRUCT__entry This patch adds a check in event_init() to reject trace events that have an empty TP_STRUCT__entry by returning -EINVAL if the first element of fields_array has a NULL type. > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c > index 30c0ddf90887f..9f79fbdf40a20 100644 > --- a/kernel/trace/trace_events.c > +++ b/kernel/trace/trace_events.c > @@ -3406,6 +3406,10 @@ static int event_init(struct trace_event_call *call) > if (WARN_ON(!name)) > return -EINVAL; > > + if (call->class->fields_array && > + !call->class->fields_array[0].type) > + return -EINVAL; [Severity: High] Does this inadvertently break the user_events subsystem? In kernel/trace/trace_events_user.c, user_events are assigned a statically initialized dummy array: kernel/trace/trace_events_user.c: static struct trace_event_fields user_event_fields_array[1]; Because this array is size 1 and zero-initialized, its first element's type field is implicitly NULL. When user_events are registered from userspace via the ABI, __register_event() calls event_init(), which will evaluate this new check to true and unconditionally return -EINVAL. Can we find another way to handle empty TP_STRUCT__entry events that won't cause a feature regression for user_events? > + > if (call->class->raw_init) { > ret = call->class->raw_init(call); > if (ret < 0 && ret != -ENOSYS) -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
