When a stap script uses uprobes.ko as built on the fly from source in
runtime/uprobes, we can get modpost warnings from stap -vv and a tainted
kernel. (However, the stap-generated module loads and runs fine
with the stap-built uprobes.ko.)
The modpost warnings look like this:
They result from a modpost command that looks like this, during the build of
the stap-generated probe module:
scripts/mod/modpost -m -i /xxx/Module.symvers -I /tmp/stap739yV3/Module.symvers
-o /tmp/stap739yV3/Module.symvers -w -s
where /xxx is apparently /lib/modules/`uname -r`/build.
I think if the -I option pointed at Module.symvers in the directory where
uprobes.ko lives, we'd be OK. I haven't figured out how to make that happen,
This is the sort of "tainted" message that shows up in /var/log/messages
when the stap-generated probe module is inserted:
Nov 5 12:33:35 myhost kernel: stap_c07123156fc06731cd751ecff0100ad4_651: no
version for "unregister_uretprobe" found: kernel tainted.
I forgot to mention... We'd also have to move step 4.5 (uprobes.ko
build) ahead of step 4 (compilation of the probe module).
Checked in fix today.
To test: On a system where the kernel provides the exports needed by uprobes,
but uprobes is not part of the kernel build (neither built-in nor a module), run
a stap script that uses uprobes (see, e.g., bz5079 or bz5083). Verify that the
"tainted" message isn't reported to /var/log/messages, and stap -vv doesn't
report the indicated warnings.