Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf trace: Support --bitmask-list with --libtraceevent
Date: Sat, 03 Oct 2026 01:34:01 +0000	[thread overview]
Message-ID: <20261003013401.9EDCF1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20261002213145.333100-1-atomlin@atomlin.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] perf trace: incomplete AST traversal for TEP_PRINT_HEX_STR nodes
- [Medium] perf trace: --bitmask-list broken for pipe mode streams
- [Low] perf trace: build failure on older libtraceevent due to missing TEP_PRINT_CPUMASK
- [Low] perf trace: future build failures due to -Wswitch-enum on external libtraceevent enum
--

commit f1dd0cf882822a7f067e6b6c6825d55f9ca3811c
Author: Aaron Tomlin <atomlin@atomlin.com>

    perf trace: Support --bitmask-list with --libtraceevent
    
    Commit ab74d1fbe061 ("perf trace: Add --bitmask-list command-line option")
    introduced the --bitmask-list option to display cpumasks and bitmasks as
    condensed, human-readable range lists (e.g. "0,2-5,7") instead of the
    default hexadecimal format.
    
    However, that implementation only augmented trace__fprintf_tp_fields().
    When --libtraceevent is specified, event formatting is delegated to
    event_format__fprintf(), which bypasses trace__fprintf_tp_fields() and
    relies directly on libtraceevent.

> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index c3c7f1f85c530..57249df65fe31 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -4857,6 +4857,77 @@ static int trace__run(struct trace *trace, int argc, const char **argv)
>  	goto out_put_evlist;
>  }
>  
> +#ifdef HAVE_LIBTRACEEVENT
> +static void tep_print_arg__set_bitmask_list(struct tep_print_arg *arg)
> +{
> +	for (; arg; arg = arg->next) {
> +		switch (arg->type) {

[Severity: Low]
Will this cause build failures on future libtraceevent updates?

The commit message mentions adding all enum values of tep_print_arg_type to
satisfy -Wswitch-enum. However, because tep_print_arg_type is an external
enum from libtraceevent, any future updates to libtraceevent that add new
values to this enum will break the perf build due to -Werror.

> +		case TEP_PRINT_BITMASK:
> +			arg->type = TEP_PRINT_CPUMASK;

[Severity: Low]
Can this cause a build failure on older libtraceevent versions?

If TEP_PRINT_CPUMASK is missing from the installed system libtraceevent
headers, this unconditional assignment will fail to compile.

> +			break;
> +		case TEP_PRINT_OP:
> +			tep_print_arg__set_bitmask_list(arg->op.left);
> +			tep_print_arg__set_bitmask_list(arg->op.right);
> +			break;
> +		case TEP_PRINT_FUNC:
> +			tep_print_arg__set_bitmask_list(arg->func.args);
> +			break;
> +		case TEP_PRINT_FLAGS:
> +			tep_print_arg__set_bitmask_list(arg->flags.field);
> +			break;
> +		case TEP_PRINT_SYMBOL:
> +			tep_print_arg__set_bitmask_list(arg->symbol.field);
> +			break;
> +		case TEP_PRINT_HEX:
> +			tep_print_arg__set_bitmask_list(arg->hex.field);
> +			tep_print_arg__set_bitmask_list(arg->hex.size);
> +			break;
> +		case TEP_PRINT_INT_ARRAY:
> +			tep_print_arg__set_bitmask_list(arg->int_array.field);
> +			tep_print_arg__set_bitmask_list(arg->int_array.count);
> +			tep_print_arg__set_bitmask_list(arg->int_array.el_size);
> +			break;
> +		case TEP_PRINT_TYPE:
> +			tep_print_arg__set_bitmask_list(arg->typecast.item);
> +			break;
> +		case TEP_PRINT_DYNAMIC_ARRAY:
> +			tep_print_arg__set_bitmask_list(arg->dynarray.index);
> +			break;
> +		case TEP_PRINT_NULL:
> +		case TEP_PRINT_ATOM:
> +		case TEP_PRINT_FIELD:
> +		case TEP_PRINT_STRING:
> +		case TEP_PRINT_BSTRING:
> +		case TEP_PRINT_DYNAMIC_ARRAY_LEN:
> +		case TEP_PRINT_HEX_STR:

[Severity: Medium]
Does this skip the AST traversal for TEP_PRINT_HEX_STR nodes?

The fallthrough here prevents the recursive traversal of arg->hex.field and
arg->hex.size for TEP_PRINT_HEX_STR nodes, which share the same structural
payload as TEP_PRINT_HEX. Nested bitmask evaluations inside a hex string
length or field argument could be silently ignored.

> +		case TEP_PRINT_CPUMASK:
> +		default:
> +			break;
> +		}
> +	}
> +}
> +

[ ... ]

> @@ -4908,6 +4979,8 @@ static int trace__replay(struct trace *trace)
>  	if (err)
>  		goto out;
>  
> +	trace__init_tp_bitmask_list(trace, session->evlist);

[Severity: Medium]
Is --bitmask-list broken for pipe mode streams?

In pipe mode, the event list is populated dynamically from synthesized
events during perf_session__process_events(), which happens later in this
function. By calling trace__init_tp_bitmask_list() here, the initialization
operates on an empty evlist, skipping the AST transformation.

> +
>  	evsel = evlist__find_tracepoint_by_name(session->evlist, "raw_syscalls:sys_enter");
>  	trace->syscalls.events.sys_enter = evsel;
>  	/* older kernels have syscalls tp versus raw_syscalls */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002213145.333100-1-atomlin@atomlin.com?part=1

  reply	other threads:[~2026-10-03  1:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 21:31 [PATCH] perf trace: Support --bitmask-list with --libtraceevent Aaron Tomlin
2026-10-03  1:34 ` sashiko-bot [this message]
2026-10-04 12:27   ` Aaron Tomlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261003013401.9EDCF1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=atomlin@atomlin.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox