Re: [PATCH v2] resolve_btfids: preserve tag and parameter names when processing implicit args

[bot+bpf-ci]

> process_kfunc_with_implicit_args() obtains parameter names through
> btf__name_by_offset() and passes them to btf__add_func_param() while
> constructing a new function prototype. Tag names are processed in a
> similar fashion.
>
> The returned name pointer references memory owned by the BTF object.
> btf__add_func_param(), btf__add_decl_tag(), etc. modify the same BTF and
> may grow its internal storage, invalidating previously returned string
> pointers.
>
> This can result in btf__add_func_param(), btf__add_decl_tag(), etc.
> dereferencing a stale pointer when copying the string, leading to crashes
> in strset__add_str().

This isn't a bug, but could the crash path in strset__add_str() be spelled
out a little more?

btf__name_by_offset() returns a pointer into btf->strs_set->strs_data (while
the BTF is still modifiable and btf->strs_data is NULL), and
strset_str_append() in tools/lib/bpf/strset.c already reconstructs that
pointer if the buffer was reallocated before it copies:

tools/lib/bpf/strset.c:strset_str_append() {
	...
	old_data = set->strs_data;
	...
	if (old_data != set->strs_data)
		s = set->strs_data + (old_s - old_data);

	memcpy((void *)s, ...);
	...
}

Given that reconstruction, what crash in strset__add_str() remains, or is the
strdup intended as a defensive/robustness change rather than a fix for an
observed crash?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27852582382