On Fri, Feb 27, 2026 at 4:18 PM <[email protected]> wrote: > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > > --- a/tools/lib/bpf/libbpf.c > > +++ b/tools/lib/bpf/libbpf.c > > @@ -12041,7 +12041,15 @@ struct kprobe_multi_resolve res = { > > if (addrs && syms) > > return libbpf_err_ptr(-EINVAL); > > > > - if (pattern) { > > + /* > > + * Exact function name (no wildcards): bypass kallsyms parsing > > + * and pass the symbol directly to the kernel via syms[] array. > > + * The kernel's ftrace_lookup_symbols() resolves it efficiently. > > + */ > > + if (pattern && !strpbrk(pattern, "*?")) { > > + syms = &pattern; > > + cnt = 1; > > + } else if (pattern) { > > When the fast path is taken here, unique_match is never checked. > The unique_match validation is inside the "else if (pattern)" > branch: > > if (unique_match && res.cnt != 1) { > pr_warn("prog '%s': failed to find a unique match ..."); > err = -EINVAL; > goto error; > } > > Before this change, a caller passing an exact function name with > unique_match = true would go through kallsyms parsing, which could > find multiple addresses for same-named static functions across > different translation units, and the unique_match check would > correctly return an error. > > With the fast path, the name goes directly to the kernel's > ftrace_lookup_symbols(), which resolves only the first match via > kallsyms_callback() skipping duplicates: > > if (args->addrs[idx]) > return 0; > > Should the fast path condition also check unique_match, for > example: > > if (pattern && !strpbrk(pattern, "*?") && !unique_match) { > > This would preserve the optimization for the common case while > falling back to the slow path when unique_match is explicitly > requested. >
I am not sure this makes sense, according to the original patchset [1] this flag was specifically tailored for patterns with wildcards where this indeed makes sense. in our case, cnt == 1 from the get go since no wildcards so this check can't ever fail. Andrii, Yonghong - any suggestions ? [1] - https://lore.kernel.org/bpf/[email protected]/ Andrey > > [ ... ] > > > --- > AI reviewed your patch. Please fix the bug or email reply why it's not a bug. > See: > https://urldefense.com/v3/__https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md__;!!BmdzS3_lV9HdKG8!z-aIXCz8YRZcraMmGI2bmb4YrDgW0brRTcX_BaJCWYwj7xfmkZL6qka6aqqIwzDPUjR1TxUU-Mc50s9AAYQf-vQMuPuGlVKW$ > > CI run summary: > https://urldefense.com/v3/__https://github.com/kernel-patches/bpf/actions/runs/22503275616__;!!BmdzS3_lV9HdKG8!z-aIXCz8YRZcraMmGI2bmb4YrDgW0brRTcX_BaJCWYwj7xfmkZL6qka6aqqIwzDPUjR1TxUU-Mc50s9AAYQf-vQMuGeekJPd$ > > AI-authorship-score: medium > AI-authorship-explanation: Comments are unusually verbose for a simple > optimization, and the commit message is well-structured with distinct > sections, but the iterative v1-v3 refinement following reviewer feedback is > typical of human development. > issues-found: 1 > issue-severity-score: low > issue-severity-explanation: The fast path bypasses the unique_match check, > which could silently attach to the wrong function among same-named statics, > but requires the uncommon combination of unique_match=true with an exact name > matching multiple kernel functions.
