In function '__synth_event_add_val', inlined from 'synth_event_add_next_val' at kernel/trace/trace_events_synth.c:1991:9: kernel/trace/trace_events_synth.c:1905:29: warning: argument 2 null where non-null expected [-Wnonnull] 1905 | if (strcmp(field->name, field_name) == 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./include/linux/bitmap.h:11, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:22, from ./arch/x86/include/asm/timex.h:5, from ./include/linux/timex.h:67, from ./include/linux/time32.h:13, from ./include/linux/time.h:60, from ./include/linux/stat.h:19, from ./include/linux/module.h:13, from kernel/trace/trace_events_synth.c:8: ./include/linux/string.h: In function 'synth_event_add_next_val': ./include/linux/string.h:48:12: note: in a call to function 'strcmp' declared 'nonnull' 48 | extern int strcmp(const char *,const char *); | ^~~~~~
Created attachment 303749 [details] Check for NULL field_name in __synth_event_add_val() Can you test this to see if it fixes the issue for you?
Hi Steven, I will try to apply your change. but these days I'm busy. I will return with a feedback in the following days. Thanks.
According to Tom Zanussi, it can never be NULL. https://lore.kernel.org/lkml/06c77bca76cd5679c8cd459480621b7db21f3a7b.camel@kernel.org/ As the code has: if (field_name) { if (trace_state->add_next) { ret = -EINVAL; goto out; } trace_state->add_name = true; } else { if (trace_state->add_name) { ret = -EINVAL; goto out; <<--- HERE If field_name is NULL and trace_state->add_name is true, it exits the function. } trace_state->add_next = true; } if (trace_state->disabled) goto out; event = trace_state->event; if (trace_state->add_name) { trace_state->add_name must be true to get here. for (i = 0; i < event->n_fields; i++) { field = event->fields[i]; if (strcmp(field->name, field_name) == 0) How can field_name be NULL then? break; } I'm closing this as not a bug, because it seems to be a bug in gcc's warning. Feel free to reopen it if you can show this is incorrect.