Comment # 8 on bug 1206321 from Miroslav Bene������

I am not able to reproduce on v6.1, but...

There is a race condition. The kernel infrastructure clears
klp_transition_patch once a transition succeeds. And only after that it calls
module_put() on all replaced previous live patches if klp_transition_patch was
replace_all.

klp_in_progress() in qa_test_klp checks /sys/kernel/livepatch/*/transition
which is basically an export of klp_transition_patch. klp_wait_complete() then
waits for klp_in_progress() to return false when a live patch module is loaded
and that is it.

So what very likely happens in klp_tc_8.sh is that klp_tc_8_*_livepatch are
loaded sequentially. When it is klp_tc_8_5_livepatch turn, the module is loaded
successfully and klp_transition_patch is cleared. klp_wait_complete() sees it
and tries to rmmod all previous modules because their refcnt should be zero.
But that does not have to be true for klp_tc_8_4_livepatch because its
module_put() has not been called yet in the kernel.

Let's just call klp_wait_complete() also before rmmod in klp_tc_8.sh. It has
the logic to wait for refcnt being zero anyway (used in klp_tc_exit() for
example, which does the right thing). Petr, could you test with the attached
patch for qa_test_klp, please?