https://bugzilla.suse.com/show_bug.cgi?id=1206321 https://bugzilla.suse.com/show_bug.cgi?id=1206321#c8 --- Comment #8 from Miroslav Bene�� <mbenes@suse.com> --- 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? -- You are receiving this mail because: You are the assignee for the bug.