Page MenuHomeFreeBSD

libdtrace: Be less strict when comparing pointer types
ClosedPublic

Authored by markj on Mon, Dec 30, 5:43 PM.
Tags
None
Referenced Files
F107533353: D48254.diff
Wed, Jan 15, 1:02 PM
Unknown Object (File)
Wed, Jan 8, 5:35 PM
Unknown Object (File)
Wed, Jan 8, 10:49 AM
Unknown Object (File)
Wed, Jan 8, 6:50 AM
Unknown Object (File)
Wed, Jan 8, 5:05 AM
Unknown Object (File)
Wed, Jan 8, 4:43 AM
Unknown Object (File)
Tue, Jan 7, 7:20 PM
Unknown Object (File)
Wed, Jan 1, 3:15 AM

Details

Summary

If one of two pointers refers to a forward declaration, let the pointers
be compatible so long as the referred types have the same name.
Otherwise we can get spurious errors.

To be specific, this can happen when ipfw_nat.ko is loaded before
ipfw.ko and /usr/lib/dtrace/ipfw.d is processed. Currently, ipfw_nat.ko
does not have a definition for struct inpcb (i.e., none of its files
include in_pcb.h), so in the CTF type graph, struct ip_fw_args' "inp"
member refers to a forward declaration, represented in CTF with
CTF_K_FORWARD.

Then, when libdtrace processes the ipfw_match_info_t translator in
ipfw.d, it decides that the "inp" field assignment is incorrect because
the two pointers are incompatible. However, there's no harm in allowing
this assignment. Add some logic to dt_node_is_ptrcompat() to detect
this case and declare the pointers as compatible so long as the name of
the thing they refer to is the same.

Reported by: marck

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 61413
Build 58297: arc lint + arc unit

Event Timeline

markj requested review of this revision.Mon, Dec 30, 5:43 PM

Only compare names if we have them.

Don't have expertise to review, but thanks a lot for working on that. Was following your discussion with Dmitry. I hit this problem many many times, when running a different mix of modules on FreeBSD CURRENT and never bothered to understand it. Always resorted to recompile a static kernel.

This is roughly similar to something I've done in HyperTrace, but made it even looser for those purposes, so LGTM.

This revision is now accepted and ready to land.Mon, Dec 30, 5:56 PM

Don't have expertise to review, but thanks a lot for working on that. Was following your discussion with Dmitry. I hit this problem many many times, when running a different mix of modules on FreeBSD CURRENT and never bothered to understand it. Always resorted to recompile a static kernel.

Are you sure it was exactly the same? I fixed another problem recently which has similar symptoms: b64c5a0ace59.

Are you sure it was exactly the same? I fixed another problem recently which has similar symptoms: b64c5a0ace59.

Not sure. I could have hit both at different times. Always cured with "recompile all statically". Thanks for fixing both!