On Fri, Feb 27, 2026 at 05:28:05PM -0500, Andrey Grodzovsky wrote: > 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.
I think the problem is that it could now pass for cases where function name has multiple instances in kallsyms .. while before it would be caught in libbpf_available_kallsyms_parse and fail jirka > > 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.
