Bug 205241
| Summary: | trace-cmd reset die()'s on missing tracing_max_latency file | ||
|---|---|---|---|
| Product: | Tools | Reporter: | Valentin Schneider (valentin.schneider) |
| Component: | Trace-cmd/Kernelshark | Assignee: | Default virtual assignee for Trace-cmd and kernelshark (tools_tracecmd_kernelshark) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | rostedt, tstoyanov |
| Priority: | P1 | ||
| Hardware: | ARM | ||
| OS: | Linux | ||
| Kernel Version: | 5.4.0-rc3-00099-g0e2adab6cf28 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
Hi Valentin, Thank you for the testing and posting this bug. You are right, depending on the kernel config, some ftrace files are optional and this should not confuse trace-cmd. -- Tzvetomir (Ceco) Stoyanov VMware Open Source Technology Center Proposed a fix: https://patchwork.kernel.org/patch/11198623/ Fixed by commit 113b0664003c ("trace-cmd: Check if ftrace file exists, before writing in it.")
|
Hi, I was trying out a newer version of trace-cmd [1] and seem to have found an issue: $ trace-cmd trace-cmd version 2.6. $ trace-cmd reset <no output, everything's fine $./trace-cmd trace-cmd version 2.9.dev (4018b22056d772094a1fd2accf8f44f096ac3737) $ ./trace-cmd reset trace-cmd: No such file or directory opening to '/sys/kernel/tracing/tracing_max_latency' Note that this kernel wasn't compiled with either IRQ or preemption off tracers: $ zcat /proc/config.gz | grep TRACER CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_GENERIC_TRACER=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_IRQSOFF_TRACER is not set # CONFIG_PREEMPT_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_HWLAT_TRACER is not set # CONFIG_TRACER_SNAPSHOT is not set # CONFIG_STACK_TRACER is not set So as hinted by 5d4a9dba2d7f ("tracing: only show tracing_max_latency when latency tracer configured"), the file won't be there. From a quick look at the code, trace-record.c::reset_max_latency() ends up calling write_file() which die()'s if it can't open the file. Perhaps files that are not guaranteed to be there could use a e.g. "try_write_instance_file()" which would first check for the presence of the file and return gracefully if it's not there, rather than die(). Cheers, Valentin [1]: https://github.com/ARM-software/lisa/pull/1144