Re: [PATCH v6 05/11] perf bpf-filter: Add lock_held() sample filter for global mutexes

[Ian Rogers]

On Thu, Oct 22, 2026 at 3:55 PM Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
>
> On Thu, Oct 22, 2026 at 01:29:57PM -0700, Ian Rogers wrote:
[snip]
> > +static int resolve_lock_expr(struct perf_bpf_filter_expr *expr,
> > +                          struct perf_bpf_filter_entry *entry)
> > +{
> > +     const char *name = expr->lock_name;
> > +     char base[128];
> > +     bool has_amp;
> > +     unsigned int mode;
> > +     u64 addr = 0;
> > +     int ret;
> > +
> > +     ret = normalize_lock_expr_op(expr, &entry->op);
> > +     if (ret < 0)
> > +             return ret;
> > +
> > +     if (split_lock_name_mode(name, expr->part, base, sizeof(base),
> > +                              &has_amp, &mode) < 0 || has_amp) {
> > +             pr_err("Error: Invalid kernel lock filter '%s'\n", name ?: "");
> > +             return -EINVAL;
> > +     }
> > +
> > +     if (str_ends_with(base, "mutex") &&
> > +         !str_ends_with(base, "rt_mutex") &&
> > +         !str_ends_with(base, "rtmutex")) {
>
> Is it just checking the symbol name ends with "mutex" or so?  It seems
> risky and limited, can we check BTF to verify if it's really a mutex?

Agreed, a suffix check is only a heuristic. The catch is that kallsyms
gives an address for a global or static variable but not its type. And
vmlinux BTF normally only has BTF_KIND_VAR entries for per-CPU
variables: scripts/Makefile.btf passes "--btf_features=...,var,..."
but not "global_var". So on most kernels there's no BTF type for
something like cgroup_mutex to check.

Patch 6 in this series adds classify_lock_sym(), which uses BTF where
it can and falls back to the name suffix otherwise. It checks:
1. for a __percpu_rwsem_rc_<name> BTF var. DEFINE_PERCPU_RWSEM()
always emits one, and as a per-CPU variable it's always in BTF;
2. the symbol's BTF_KIND_VAR type (struct mutex, rt_mutex,
rw_semaphore, semaphore, ...), when the kernel was built with global
variables in BTF;
3. otherwise, the name suffix.

In any case a wrong guess is harmless. The direct owner check only
reads lock->owner with bpf_probe_read_kernel(), and only at an address
already confirmed to be in kernel .data/.bss (function symbols are
rejected via kallsyms and BTF). The worst case is that the filter
doesn't match.

Patch 5 adding a suffix check that patch 6 then replaces isn't
intuitive, so in the next version I'll move classify_lock_sym() into
patch 5 and use it from the start.

Thanks,
Ian

> Thanks,
> Namhyung