From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 731D7156C77 for ; Fri, 31 May 2024 19:44:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717184695; cv=none; b=qY4HUEx9DJBwVo9BpSqtWKlNH97/xmUepRfZIyZPkIIlHk98X3LwRXGHmUZsma3CrbnRha64vCwBVODRV0J7sV4ddZ+ZmU7yunEnHx9OwZccmfRZKFal+ujVrOpkjTLYVevH8Hv9jwxpitdtLxxnLG5TXkgQuKH+sVCxQ8+wAio= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717184695; c=relaxed/simple; bh=WsXsZUZBHM71gw5SH/Pl2AmNjI0Fjt2FzypgjJ5Rw5I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DRaKlL2guWHlznR5gdY/SQpZhrz7BrnnpLCS07X/jI8XmfdCCmIn5NtXYqE7jirYlgmeX27k/1PCy0N6T7AWjgm3HxaDk0ThQ+g5ay9/duhHY5AN3e71ukwHJBRwbvpBFIMsfo9liUC9/jeQrWbQOvMcdwBZpGmEAFf6akLqOcc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Au+QfD/e; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Au+QfD/e" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717184692; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=srIuKAq+Z2eXfh6Ltvl4It8PMcDQP7/BZ/A3IAY5rw0=; b=Au+QfD/eRafNq6WW4u0B9QBQyKlmcWEFbmH8Hhtk199Fo0M6otFXdLpZASikaGt4Dg1ZEz Jnm8hsDlcAXxAVg2aYnQSiHqNvVe1yAdcHAJPLJxeNA444ca07imjDcGJYgW3skdgIUaIr t3hRb1FVewIe9weu39qsgAjNHK3Su2w= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-612-pOdfD2urOUW337F-bRD_dA-1; Fri, 31 May 2024 15:44:48 -0400 X-MC-Unique: pOdfD2urOUW337F-bRD_dA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 37EAE3C025AC; Fri, 31 May 2024 19:44:48 +0000 (UTC) Received: from redhat.com (unknown [10.22.18.140]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BEBAC3C27; Fri, 31 May 2024 19:44:47 +0000 (UTC) Date: Fri, 31 May 2024 15:44:46 -0400 From: Joe Lawrence To: Marcos Paulo de Souza Cc: Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Shuah Khan , live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] selftests: livepatch: Test atomic replace against multiple modules Message-ID: References: <20240525-lp-atomic-replace-v2-1-142199bb65a1@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240525-lp-atomic-replace-v2-1-142199bb65a1@suse.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 On Sat, May 25, 2024 at 11:34:08AM -0300, Marcos Paulo de Souza wrote: > Adapt the current test-livepatch.sh script to account the number of > applied livepatches and ensure that an atomic replace livepatch disables > all previously applied livepatches. > > Signed-off-by: Marcos Paulo de Souza > --- > Changes since v1: > * Added checks in the existing test-livepatch.sh instead of creating a > new test file. (Joe) > * Fixed issues reported by ShellCheck (Joe) > --- > .../testing/selftests/livepatch/test-livepatch.sh | 46 ++++++++++++++++++++-- > 1 file changed, 42 insertions(+), 4 deletions(-) > > diff --git a/tools/testing/selftests/livepatch/test-livepatch.sh b/tools/testing/selftests/livepatch/test-livepatch.sh > index e3455a6b1158..d85405d18e54 100755 > --- a/tools/testing/selftests/livepatch/test-livepatch.sh > +++ b/tools/testing/selftests/livepatch/test-livepatch.sh > @@ -107,9 +107,12 @@ livepatch: '$MOD_LIVEPATCH': unpatching complete > > # - load a livepatch that modifies the output from /proc/cmdline and > # verify correct behavior > -# - load an atomic replace livepatch and verify that only the second is active > -# - remove the first livepatch and verify that the atomic replace livepatch > -# is still active > +# - load two addtional livepatches and check the number of livepatch modules > +# applied > +# - load an atomic replace livepatch and check that the other three modules were > +# disabled > +# - remove all livepatches besides the atomic replace one and verify that the > +# atomic replace livepatch is still active > # - remove the atomic replace livepatch and verify that none are active > > start_test "atomic replace livepatch" > @@ -119,12 +122,31 @@ load_lp $MOD_LIVEPATCH > grep 'live patched' /proc/cmdline > /dev/kmsg > grep 'live patched' /proc/meminfo > /dev/kmsg > > +for mod in test_klp_syscall test_klp_callbacks_demo; do Slightly nitpicky here, but the tests were originally written with the livepatch module names via variables like $MOD_LIVEPATCH. Would using $MOD_LIVEPATCH{1,2,3} help indicate that their specifics aren't really interesting, that we just need 3 of them? > + load_lp $mod > +done > + > +mods=(/sys/kernel/livepatch/*) > +nmods=${#mods[@]} > +if [ "$nmods" -ne 3 ]; then > + die "Expecting three modules listed, found $nmods" > +fi > + I was going to suggest that we might protect against a situation where other livepatch modules were active, that a simple count wouldn't be sufficient. But then I thought about this test, atomic replace! Anything previously loaded is going to be pushed aside anyway. So maybe (in another patch or set) it would be worth enhancing functions.sh :: start_test() do a quick sanity check to see that the initial conditions are safe? That might also prevent some collateral damage when test A fails and leaves the world a strange place for tests B, C, etc. > load_lp $MOD_REPLACE replace=1 > > grep 'live patched' /proc/cmdline > /dev/kmsg > grep 'live patched' /proc/meminfo > /dev/kmsg > > -unload_lp $MOD_LIVEPATCH > +mods=(/sys/kernel/livepatch/*) > +nmods=${#mods[@]} > +if [ "$nmods" -ne 1 ]; then > + die "Expecting only one moduled listed, found $nmods" > +fi > + > +# These modules were disabled by the atomic replace > +for mod in test_klp_callbacks_demo test_klp_syscall $MOD_LIVEPATCH; do > + unload_lp "$mod" > +done > > grep 'live patched' /proc/cmdline > /dev/kmsg > grep 'live patched' /proc/meminfo > /dev/kmsg > @@ -142,6 +164,20 @@ livepatch: '$MOD_LIVEPATCH': starting patching transition > livepatch: '$MOD_LIVEPATCH': completing patching transition > livepatch: '$MOD_LIVEPATCH': patching complete > $MOD_LIVEPATCH: this has been live patched > +% insmod test_modules/test_klp_syscall.ko Similar minor nit here, too. If we think copy/pasting all the $MOD_FOO is annoying, I am fine with leaving this as is. I don't have a strong opinion other than following some convention. With that, I'm happy to ack as-is or with variable names. Acked-by: Joe Lawrence -- Joe