"ftrace: Rework event_create_dir()" triggers boot error messages

Qian Cai cai at lca.pw
Mon Jan 6 09:05:58 PST 2020



> On Dec 18, 2019, at 11:31 PM, Steven Rostedt <rostedt at goodmis.org> wrote:
> 
> On Wed, 18 Dec 2019 22:58:23 -0500
> Qian Cai <cai at lca.pw> wrote:
> 
>> The linux-next commit "ftrace: Rework event_create_dir()” [1] triggers boot warnings
>> for Clang-build (Clang version 8.0.1) kernels (reproduced on both arm64 and powerpc).
>> Reverted it (with trivial conflict fixes) on the top of today’s linux-next fixed the issue.
>> 
>> configs:
>> https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
>> https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
>> 
>> [1] https://lore.kernel.org/lkml/20191111132458.342979914@infradead.org/
>> 
>> [  115.799327][    T1] Registered efivars operations
>> [  115.849770][    T1] clocksource: Switched to clocksource arch_sys_counter
>> [  115.901145][    T1] Could not initialize trace point events/sys_enter_rt_sigreturn
>> [  115.908854][    T1] Could not create directory for event sys_enter_rt_sigreturn
>> [  115.998949][    T1] Could not initialize trace point events/sys_enter_restart_syscall
>> [  116.006802][    T1] Could not create directory for event sys_enter_restart_syscall
>> [  116.062702][    T1] Could not initialize trace point events/sys_enter_getpid
>> [  116.069828][    T1] Could not create directory for event sys_enter_getpid
>> [  116.078058][    T1] Could not initialize trace point events/sys_enter_gettid
>> [  116.085181][    T1] Could not create directory for event sys_enter_gettid
>> [  116.093405][    T1] Could not initialize trace point events/sys_enter_getppid
>> [  116.100612][    T1] Could not create directory for event sys_enter_getppid
>> [  116.108989][    T1] Could not initialize trace point events/sys_enter_getuid
>> [  116.116058][    T1] Could not create directory for event sys_enter_getuid
>> [  116.124250][    T1] Could not initialize trace point events/sys_enter_geteuid
>> [  116.131457][    T1] Could not create directory for event sys_enter_geteuid
>> [  116.139840][    T1] Could not initialize trace point events/sys_enter_getgid
>> [  116.146908][    T1] Could not create directory for event sys_enter_getgid
>> [  116.155163][    T1] Could not initialize trace point events/sys_enter_getegid
>> [  116.162370][    T1] Could not create directory for event sys_enter_getegid
>> [  116.178015][    T1] Could not initialize trace point events/sys_enter_setsid
>> [  116.185138][    T1] Could not create directory for event sys_enter_setsid
>> [  116.269307][    T1] Could not initialize trace point events/sys_enter_sched_yield
>> [  116.276811][    T1] Could not create directory for event sys_enter_sched_yield
>> [  116.527652][    T1] Could not initialize trace point events/sys_enter_munlockall
>> [  116.535126][    T1] Could not create directory for event sys_enter_munlockall
>> [  116.622096][    T1] Could not initialize trace point events/sys_enter_vhangup
>> [  116.629307][    T1] Could not create directory for event sys_enter_vhangup
>> [  116.783867][    T1] Could not initialize trace point events/sys_enter_sync
>> [  116.790819][    T1] Could not create directory for event sys_enter_sync
>> [  117.723402][    T1] pnp: PnP ACPI init
> 
> I noticed that all of the above have zero parameters. Does the
> following patch fix it?
> 
> (note, I prefer "ret" and "i" on different lines anyway)
> 
> -- Steve
> 
> diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> index 53935259f701..abb70c71fe60 100644
> --- a/kernel/trace/trace_syscalls.c
> +++ b/kernel/trace/trace_syscalls.c
> @@ -269,7 +269,8 @@ static int __init syscall_enter_define_fields(struct trace_event_call *call)
> 	struct syscall_trace_enter trace;
> 	struct syscall_metadata *meta = call->data;
> 	int offset = offsetof(typeof(trace), args);
> -	int ret, i;
> +	int ret = 0;
> +	int i;
> 
> 	for (i = 0; i < meta->nb_args; i++) {
> 		ret = trace_define_field(call, meta->types[i],

Steve, those errors are still there in today’s linux-next. Is this patch on the way to the linux-next?




More information about the linux-arm-kernel mailing list