Re: [PATCH 05/10] tracing/filters: Report parse error on all -EINVAL paths in filter parsing

[Steven Rostedt]

On Sun, 25 Oct 2026 01:26:10 +0900
"Masami Hiramatsu (Google)" <mhiramat@xxxxxxxxxx> wrote:

> From: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
> 
> Several error paths in filter parsing return -EINVAL (or -1) without
> calling parse_error() to set pe->lasterr:
> 
> 1. In parse_pred(), when an invalid token is encountered where a field name
>    is expected (e.g., "common_pid == 1 || (common_pid == 2 && )"), len is 0
>    and it returns -1 without calling parse_error().
> 2. In process_preds(), when !nr_preds (e.g., empty or whitespace-only
>    filter), it returns -EINVAL before predicate_parse() can set
>    FILT_ERR_NO_FILTER.
> 3. In predicate_parse(), when op_stack overflows or the jump target check
>    fails, it returns -EINVAL without calling parse_error().
> 
> Because pe->lasterr remains 0 on these paths, append_filter_err() falls
> back to printing an uninformative "Error: (0)" instead of reporting the
> diagnostic and error position.
> 
> Call parse_error() with the appropriate error code on all of these paths.
> 
> Fixes: 80765597bc58 ("tracing: Rewrite filter logic to be simpler and faster")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>

This is more of a cleanup than fixes. You can keep the "fixes" tag but
remove the stable. It's not that important to backport. Sure, the stable
folks may backport it anyway, but I use the stable tag for what I feel is
important to backport.

-- Steve