module kallsyms find_symbol() test
configname: CONFIG_TEST_KALLSYMS
Linux Kernel Configuration
└─>Kernel hacking
└─>Kernel Testing and Coverage
└─>Runtime Testing
└─>module kallsyms find_symbol() test
In linux kernel since version 6.13 (release Date: 2025-01-19)
This allows us to stress test find_symbol() through the kallsyms
used to place symbols on the kernel ELF kallsyms and modules kallsyms
where we place kernel symbols such as exported symbols.
We have four test modules:
A: has KALLSYSMS_NUMSYMS exported symbols
B: uses one of A's symbols
C: adds KALLSYMS_SCALE_FACTOR * KALLSYSMS_NUMSYMS exported
D: adds 2 * the symbols than C
We stress test find_symbol() through two means:
1) Upon load of B it will trigger simplify_symbols() to look for the
one symbol it uses from the module A with tons of symbols. This is an
indirect way for us to have B call resolve_symbol_wait() upon module
load. This will eventually call find_symbol() which will eventually
try to find the symbols used with find_exported_symbol_in_section().
find_exported_symbol_in_section() uses bsearch() so a binary search
for each symbol. Binary search will at worst be O(log(n)) so the
larger TEST_MODULE_KALLSYSMS the worse the search.
2) The selftests should load C first, before B. Upon B's load towards
the end right before we call module B's init routine we get
complete_formation() called on the module. That will first check
for duplicate symbols with the call to verify_exported_symbols().
That is when we'll force iteration on module C's insane symbol list.
Since it has 10 * KALLSYMS_NUMSYMS it means we can first test
just loading B without C. The amount of time it takes to load C Vs
B can give us an idea of the impact growth of the symbol space and
give us projection. Module A only uses one symbol from B so to allow
this scaling in module C to be proportional, if it used more symbols
then the first test would be doing more and increasing just the
search space would be slightly different. The last module, module D
will just increase the search space by twice the number of symbols in
C so to allow for full projects.
tools/testing/selftests/module/find_symbol.sh
The current defaults will incur a build delay of about 7 minutes
on an x86_64 with only 8 cores. Enable this only if you want to
stress test find_symbol() with thousands of symbols. At the same
time this is also useful to test building modules with thousands of
symbols, and if BTF is enabled this also stress tests adding BTF
information for each module. Currently enabling many more symbols
will segfault the build system.
If unsure, say N.
used to place symbols on the kernel ELF kallsyms and modules kallsyms
where we place kernel symbols such as exported symbols.
We have four test modules:
A: has KALLSYSMS_NUMSYMS exported symbols
B: uses one of A's symbols
C: adds KALLSYMS_SCALE_FACTOR * KALLSYSMS_NUMSYMS exported
D: adds 2 * the symbols than C
We stress test find_symbol() through two means:
1) Upon load of B it will trigger simplify_symbols() to look for the
one symbol it uses from the module A with tons of symbols. This is an
indirect way for us to have B call resolve_symbol_wait() upon module
load. This will eventually call find_symbol() which will eventually
try to find the symbols used with find_exported_symbol_in_section().
find_exported_symbol_in_section() uses bsearch() so a binary search
for each symbol. Binary search will at worst be O(log(n)) so the
larger TEST_MODULE_KALLSYSMS the worse the search.
2) The selftests should load C first, before B. Upon B's load towards
the end right before we call module B's init routine we get
complete_formation() called on the module. That will first check
for duplicate symbols with the call to verify_exported_symbols().
That is when we'll force iteration on module C's insane symbol list.
Since it has 10 * KALLSYMS_NUMSYMS it means we can first test
just loading B without C. The amount of time it takes to load C Vs
B can give us an idea of the impact growth of the symbol space and
give us projection. Module A only uses one symbol from B so to allow
this scaling in module C to be proportional, if it used more symbols
then the first test would be doing more and increasing just the
search space would be slightly different. The last module, module D
will just increase the search space by twice the number of symbols in
C so to allow for full projects.
tools/testing/selftests/module/find_symbol.sh
The current defaults will incur a build delay of about 7 minutes
on an x86_64 with only 8 cores. Enable this only if you want to
stress test find_symbol() with thousands of symbols. At the same
time this is also useful to test building modules with thousands of
symbols, and if BTF is enabled this also stress tests adding BTF
information for each module. Currently enabling many more symbols
will segfault the build system.
If unsure, say N.