mirror of
https://github.com/torvalds/linux.git
synced 2026-08-05 14:59:58 +02:00
62e23f1838
BTF dedup has a strong assumption that compiler with deduplicate identical types within any given compilation unit (i.e., .c file). This property is used when establishing equilvalence of two subgraphs of types. Unfortunately, this property doesn't always holds in practice. We've seen cases of having truly identical structs, unions, array definitions, and, most recently, even pointers to the same type being duplicated within CU. Previously, we mitigated this on a case-by-case basis, adding a few simple heuristics for validating that two BTF types (having two different type IDs) are structurally the same. But this approach scales poorly, and we can have more weird cases come up in the future. So let's take a half-step back, and implement a bit more generic structural equivalence check, recursively. We still limit it to reasonable depth to avoid long reference loops. Depth-wise limiting of potentially cyclical graph isn't great, but as I mentioned below doesn't seem to be detrimental performance-wise. We can always improve this in the future with per-type visited markers, if necessary. Performance-wise this doesn't seem too affect vmlinux BTF dedup, which makes sense because this logic kicks in not so frequently and only if we already established a canonical candidate type match, but suddenly find a different (but probably identical) type. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Link: https://lore.kernel.org/r/20250501235231.1339822-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|---|---|---|
| .. | ||
| api | ||
| bpf | ||
| perf | ||
| subcmd | ||
| symbol | ||
| thermal | ||
| argv_split.c | ||
| bitmap.c | ||
| cmdline.c | ||
| ctype.c | ||
| find_bit.c | ||
| hweight.c | ||
| list_sort.c | ||
| rbtree.c | ||
| slab.c | ||
| str_error_r.c | ||
| string.c | ||
| vsprintf.c | ||
| zalloc.c | ||