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: WARNING: "register_uprobe" [/tmp/stap739yV3/stap_c07123156fc06731cd751ecff0100ad4_651.ko] undefined! WARNING: "register_uretprobe" [/tmp/stap739yV3/stap_c07123156fc06731cd751ecff0100ad4_651.ko] undefined! WARNING: "unregister_uprobe" [/tmp/stap739yV3/stap_c07123156fc06731cd751ecff0100ad4_651.ko] undefined! WARNING: "unregister_uretprobe" [/tmp/stap739yV3/stap_c07123156fc06731cd751ecff0100ad4_651.ko] undefined! 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, though. 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.