All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.