On 8/22/24 12:34, Ryan Sullivan wrote: > Uses 'loop_until' to wait for the atomic replace to unload all previous > livepatches, as on some machines with a large number of CPUs there is a > sizable delay between the atomic replace ocurring and when sysfs > updates accordingly. > Small nit: flip this around so it describes the problem first, then the 'loop_util' solution. Also spell check "occurring" if you keep it 😄 > Signed-off-by: Ryan Sullivan <rysulliv@xxxxxxxxxx> Let's give the CKI credit for finding this: Reported-by: CKI Project <cki-project@xxxxxxxxxx> If anyone is interested, here is the test/log link: https://datawarehouse.cki-project.org/kcidb/tests/redhat:1413102084-x86_64-kernel_upt_28 By the way, was it easy to repro on a similar machine as the one reported by CKI and then how did it fare with this patch in place? > --- > tools/testing/selftests/livepatch/test-livepatch.sh | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/tools/testing/selftests/livepatch/test-livepatch.sh b/tools/testing/selftests/livepatch/test-livepatch.sh > index 65c9c058458d..bd13257bfdfe 100755 > --- a/tools/testing/selftests/livepatch/test-livepatch.sh > +++ b/tools/testing/selftests/livepatch/test-livepatch.sh > @@ -139,11 +139,8 @@ load_lp $MOD_REPLACE replace=1 > grep 'live patched' /proc/cmdline > /dev/kmsg > grep 'live patched' /proc/meminfo > /dev/kmsg > > -mods=(/sys/kernel/livepatch/*) > -nmods=${#mods[@]} > -if [ "$nmods" -ne 1 ]; then > - die "Expecting only one moduled listed, found $nmods" > -fi > +loop_until 'mods=(/sys/kernel/livepatch/*); nmods=${#mods[@]}; [[ "$nmods" -eq 1 ]]' || > + die "Expecting only one moduled listed, found $nmods" > > # These modules were disabled by the atomic replace > for mod in $MOD_LIVEPATCH3 $MOD_LIVEPATCH2 $MOD_LIVEPATCH1; do With commit msg additions above: Acked-by: Joe Lawrence <joe.lawrence@xxxxxxxxxx> Thanks, -- Joe
