| Message ID | 20191106222801.7541-1-joe.lawrence@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | selftests/livepatch: filter 'taints' from dmesg comparison | expand |
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. Miroslav > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> > --- > > Note: I stumbled across this in a testing scenario and thought it might > be generally useful to extend this admittedly fragile mechanism. Since > there are no related livepatch-core changes, this can go through Shuah's > kselftest tree if she prefers. -- Joe > > tools/testing/selftests/livepatch/functions.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/livepatch/functions.sh b/tools/testing/selftests/livepatch/functions.sh > index 79b0affd21fb..57975c323542 100644 > --- a/tools/testing/selftests/livepatch/functions.sh > +++ b/tools/testing/selftests/livepatch/functions.sh > @@ -221,7 +221,7 @@ function check_result { > local expect="$*" > local result > > - result=$(dmesg | grep -v 'tainting' | grep -e 'livepatch:' -e 'test_klp' | sed 's/^\[[ 0-9.]*\] //') > + result=$(dmesg | grep -ve '\<taints\>' -ve '\<tainting\>' | grep -e 'livepatch:' -e 'test_klp' | sed 's/^\[[ 0-9.]*\] //') > > if [[ "$expect" == "$result" ]] ; then > echo "ok" > -- > 2.21.0 >
On 11/7/19 3:58 AM, 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. > > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
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. > I'm only half a cup in this morning myself, but... In my scenario, I saw in the kernel log: % modprobe test_klp_livepatch test_klp_livepatch: loading out-of-tree module taints kernel. test_klp_livepatch: module verification failed: signature and/or required key missing - tainting kernel ... and because check_result() only removes 'tainting' with grep -v, the expected log message failed to match with the actual filtered message because of the first 'taints' message. So this change just adds more to the filtered out strings: result = dmesg | grep -v <filtered out strings> | grep <interesting strings> BTW, none of the callers of check_result() bother to include either taint message since I think they are only ever emitted on the first occurance. -- Joe
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? > I'm only half a cup in this morning myself, but... > > In my scenario, I saw in the kernel log: > > % modprobe test_klp_livepatch > test_klp_livepatch: loading out-of-tree module taints kernel. > test_klp_livepatch: module verification failed: signature and/or > required key missing - tainting kernel > ... So modprobe here should not print anything like this. > and because check_result() only removes 'tainting' with grep -v, the expected > log message failed to match with the actual filtered message because of the > first 'taints' message. > > So this change just adds more to the filtered out strings: > > result = dmesg | grep -v <filtered out strings> | grep <interesting > strings> The code is definitely correct. You can add my Acked-by: Miroslav Benes <mbenes@suse.cz> M
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? 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 :( And then it seemed that opening the tests for OOT modules was reasonable anyway. -- Joe
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
On Wed 2019-11-06 17:28:01, 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. It needs a special way how to build the selftest modules. But it is clearly possible. > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> > --- > > Since there are no related livepatch-core changes, this can go > through Shuah's kselftest tree if she prefers. Shuah, would you like to take it via kselftest tree, please? Or I could add it into livepatch tree if you would prefer it. Best Regards, Petr
On 11/7/19 10:24 AM, Miroslav Benes wrote: >> 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. > Forgot to mention that this works too, but I was looking to script it and not have each .ko hardcoded in a series of make commands. Anyway, it's a strange use-case and it was something I was only cooking up for an in-house continuous testing scenario. >> 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. > It would probably go hand in hand with custom test scripts that would understand the OOT module capabilities, I think. I doubt anyone will try it (besides me), but the grep filter was there and it was an easy tweak. -- Joe
diff --git a/tools/testing/selftests/livepatch/functions.sh b/tools/testing/selftests/livepatch/functions.sh index 79b0affd21fb..57975c323542 100644 --- a/tools/testing/selftests/livepatch/functions.sh +++ b/tools/testing/selftests/livepatch/functions.sh @@ -221,7 +221,7 @@ function check_result { local expect="$*" local result - result=$(dmesg | grep -v 'tainting' | grep -e 'livepatch:' -e 'test_klp' | sed 's/^\[[ 0-9.]*\] //') + result=$(dmesg | grep -ve '\<taints\>' -ve '\<tainting\>' | grep -e 'livepatch:' -e 'test_klp' | sed 's/^\[[ 0-9.]*\] //') if [[ "$expect" == "$result" ]] ; then echo "ok"
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. Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> --- Note: I stumbled across this in a testing scenario and thought it might be generally useful to extend this admittedly fragile mechanism. Since there are no related livepatch-core changes, this can go through Shuah's kselftest tree if she prefers. -- Joe tools/testing/selftests/livepatch/functions.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)