On Thu, 7 Nov 2019, Joe Lawrence wrote:
On 11/7/19 9:53 AM, Miroslav Benes wrote:
On Thu, 7 Nov 2019, Joe Lawrence wrote:
On 11/7/19 3:42 AM, Miroslav Benes wrote:
On Wed, 6 Nov 2019, Joe Lawrence wrote:
The livepatch selftests compare expected dmesg output to verify kernel behavior. They currently filter out "tainting kernel with TAINT_LIVEPATCH" messages which may be logged when loading livepatch modules.
Further filter the log to also drop "loading out-of-tree module taints kernel" messages in case the klp_test modules have been build without the in-tree module flag.
That is true, but "tainting kernel with TAINT_LIVEPATCH" should be printed out even in this case. check_modinfo_livepatch() is called for all modules and relies on MODINFO(livepatch, Y).
So either the bug is elsewhere or I need one more cup of tea.
Ok, the above is not relevant here.
I'm only wondering about the execution steps, because supporting modules lib/livepatch/ should be built as in-tree. No?
Ah, I see. Well as you noted they are modprobed, so theoretically they could come from anywhere OOT, right?
Yes.
In my test, I had a kernel tree, but only wanted to build the test modules. Once I did a 'make modules SUBDIR=' or 'make M= ...' KBUILD_EXTMOD got flipped on and the modules lost in-tree status. No amount of googling could tell me how to build a single in-tree directory of modules :(
"make lib/livepatch/test_klp_livepatch.ko" should do the trick. "make lib/livepatch/" only builds the object files and I haven't found a way to make it link .ko modules other than specifying them one by one directly.
And then it seemed that opening the tests for OOT modules was reasonable anyway.
That's an interesting idea. If a module is in tree, it is under our control. So we know what "testing capabilities" it offers. I guess that with OOT testing modules the selftests would have to be smarter.
Miroslav