Skip to content

callchain: answer the pointer chain with the sites that can reach it - #77

Open
kuba-moo wants to merge 1 commit into
facebookexperimental:mainfrom
kuba-moo:callchain-fix-weak-matches
Open

callchain: answer the pointer chain with the sites that can reach it#77
kuba-moo wants to merge 1 commit into
facebookexperimental:mainfrom
kuba-moo:callchain-fix-weak-matches

Conversation

@kuba-moo

Copy link
Copy Markdown

callers and callchain read one index and disagreed. Sites are joined to registrations on the bare member name, and a site whose receiver type is not the type the function was installed in is marked as such; show_indirect_callers reports those as a count, and the reverse chain reported them as answers.

can_rcv is installed in packet_type::func. func is also work_struct's, hda_fixup's, ac97_quirk's and the amdgpu calltables', so the section listed 27 dispatching functions ordered by name and cut the list at 15 — which stopped at for_each_frequency, with every site that receives a CAN frame past the end. The rows shown were a bcache work item and an amdgpu register-access macro, under a question about CAN.

Walking the chain above a site is what the section costs, so the same defect was the cost: one walk per row shown, 15 of them paid for sites that reach nothing. callchain can_rcv took 34s, of which 14 belonged to CGS_CALL alone. It now takes 3.7s, names the three sites in net/core/dev.c that callers names, and counts the other 36 rather than walking them.

A section with only member-name evidence still gets its heading and its count: saying nothing would claim the index knows of no way in, when it knows of one it cannot stand behind. That is why the return value grew from a count of rows to what the section said — the "isolated (no callers or callees)" line above it has to stay true.

`callers` and `callchain` read one index and disagreed. Sites are joined to
registrations on the bare member name, and a site whose receiver type is not
the type the function was installed in is marked as such;
show_indirect_callers reports those as a count, and the reverse chain reported
them as answers.

can_rcv is installed in packet_type::func. `func` is also work_struct's,
hda_fixup's, ac97_quirk's and the amdgpu calltables', so the section listed 27
dispatching functions ordered by name and cut the list at 15 — which stopped
at for_each_frequency, with every site that receives a CAN frame past the end.
The rows shown were a bcache work item and an amdgpu register-access macro,
under a question about CAN.

Walking the chain above a site is what the section costs, so the same defect
was the cost: one walk per row shown, 15 of them paid for sites that reach
nothing. `callchain can_rcv` took 34s, of which 14 belonged to CGS_CALL alone.
It now takes 3.7s, names the three sites in net/core/dev.c that `callers`
names, and counts the other 36 rather than walking them.

A section with only member-name evidence still gets its heading and its count:
saying nothing would claim the index knows of no way in, when it knows of one
it cannot stand behind. That is why the return value grew from a count of rows
to what the section said — the "isolated (no callers or callees)" line above it
has to stay true.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Meta Open Source bot. label Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Meta Open Source bot.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant