Received: by 2002:ab2:7903:0:b0:1fb:b500:807b with SMTP id a3csp1115500lqj; Mon, 3 Jun 2024 10:30:24 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVGa0SnnHSSQtF0bk8jY8JiBwXT8TqctqCKeAhVC3vc2zLiCASvCpgAlGzVUBtEqK57c+htDVp87TeLbTx6nqwROdkuJ7hbxpHeM4B8PA== X-Google-Smtp-Source: AGHT+IGZsLMZ+ox1KmmoYNVLx22yeZ0dDMhkiZiwAsw6g220AKHcgNZNSCY2R3OOo5z+OwQ+gjBR X-Received: by 2002:aca:1811:0:b0:3c9:68fd:b0ae with SMTP id 5614622812f47-3d1e34a1e64mr9771047b6e.35.1717435823471; Mon, 03 Jun 2024 10:30:23 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717435823; cv=pass; d=google.com; s=arc-20160816; b=nEtpeJd00r1uXju0+FT0VMQvbo/LZSohlzPv6YYz+l/oNhnM70yNR88P/xiyoaQIwX FEkMtn/ksM3yaE7/lj/z110+e4ibnsUkl3NkLY7r/R2N//eVBwAt0m/0tOuYko+YigSv Qr1W2dZPZYpHISQMdGzrk7mTBbqWc8RLfio7s9DuAQw9mSIL+fbALTXLuj3AcB2yXgwj gXHfF/A/9Zr0SNmmBmPvyfTYfhBw8fbXpIbZTzf27uuMuKwYeE4Li80nbIqS81JxksFn R0z0XVLsRmEeRR9wBA+GuLVTJECSSg69TX5pyRcufFmhXugr9QQ2j2l80BNAZwqzQpbB E3kQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :user-agent:content-transfer-encoding:references:in-reply-to:date:cc :to:from:subject:message-id:dkim-signature; bh=TP8+QiasuhOdVisljDp2pyOsuEXVypgBBteRkvvRnmM=; fh=iYa1LY1hfZ7L9qbr1acM2YcZOhX3o9MojMhiP0/jHO8=; b=oXRwInrn9PwGv30ZXxsULag3Ekk7g95u/IxLSh27Px8E2fHkoGxlX0dKCWOKIgi5W9 VcggEgH8FzryqioPJsXjEjor2kWA9neohuVYChOGF2L+NBR//VPS5JzKmMIMFbX9rsui cuKi1A1CWRAHFMTnPeHOs20mZlHGj9yN7e9QqMgIh3vb9OMtu5vJNjQ7b4BqjDXfsK9A krnpNWxxxkzOu9Uk4HqmHqJT8Lhidi6oxJmUj1mP876+o99xKKuZfHs2k30uNppAZPSN 6VfOAW1cvi2vqQ/imhkaV0zJkqjwQT5WQFID4tl7ItmNZ3rVOEtsMbO0icdnGNjeKpbV 2S0w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@suse.com header.s=google header.b=bxCSfKUK; arc=pass (i=1 spf=pass spfdomain=suse.com dkim=pass dkdomain=suse.com dmarc=pass fromdomain=suse.com); spf=pass (google.com: domain of linux-kernel+bounces-199510-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-199510-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id 6a1803df08f44-6ae4b403d92si89282336d6.207.2024.06.03.10.30.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jun 2024 10:30:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-199510-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=google header.b=bxCSfKUK; arc=pass (i=1 spf=pass spfdomain=suse.com dkim=pass dkdomain=suse.com dmarc=pass fromdomain=suse.com); spf=pass (google.com: domain of linux-kernel+bounces-199510-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-199510-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 9B5B91C22090 for ; Mon, 3 Jun 2024 17:30:21 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 130DB137775; Mon, 3 Jun 2024 17:30:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="bxCSfKUK" Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CC9A14294 for ; Mon, 3 Jun 2024 17:30:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717435812; cv=none; b=meTsF+brEf+19bruYCoA6QQmBSqy49jUrsoA8TT9NQYUpf/1iWg9l8pHc9LJSH1KXuBB8JMvpRvT/Ga/d2Y02PAlgvSyQPogiDvV3eVqxQr7DizzrSNBSsTKxKCQusC33JY+IJPZvjjTPqnHlaJ398oVPYcFK+XBQDNDPnl9Olg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717435812; c=relaxed/simple; bh=ltV8MMFtkwHdGR/la1V/bsd2+BUGbuIdSZO4QGmrCZw=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=oMXZS/IIaczH1+p/86n9b/66VzD0/rYrIAGd9mbLdVDgFeU2aMmlrlNUhjONCZ4tZk9LzBa/DNgNbHS4we6yHZqcbVf4XcntBZm5jOySvx2rMEk68VZIDdeoRPwHjIQCNKCp29jcl+YOVdbdoskPxsSpnZgARsT/BnUPl4scts8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=bxCSfKUK; arc=none smtp.client-ip=209.85.208.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2eaa794eb9fso29377901fa.2 for ; Mon, 03 Jun 2024 10:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1717435809; x=1718040609; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=TP8+QiasuhOdVisljDp2pyOsuEXVypgBBteRkvvRnmM=; b=bxCSfKUKUW5FSAQV/Rz25JjXNjFpaCOZ5j7V8nbso+Pg4QlA5FE3sAyJAv8TI6nS2e HSqCd6iB71oYpqmdx3FZyv5DySEJf8DI2idMHvFfvJ6Xpi+zounoB2RJu4Oco6+U34yB LLK4O9MGTPGUKbv+gihRUPbsKkBMtaD6T3E5nTrkqslSWh6uTL3Oztt4N9kXD4WWmnSZ yDVeIPxPLz0W7BijJtubklvA6f9r1KLK9xZJV/vbpVSoGkwSo6FP7K7FXmofRst1i5gn Zy3nOxRiEbozgoxhKVPl8saxKPONml8/Vs5gUU76oZ5p0kiexiQFUBLDwKeplg1CiKXO UN9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717435809; x=1718040609; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=TP8+QiasuhOdVisljDp2pyOsuEXVypgBBteRkvvRnmM=; b=mIOqIaS5JQjt/lninVOG6kmWK4ZV3mPMkjhA8bZxoJnJJCHOwV+NOqREjtCpK1O07+ gC0xfMsQ3tuFXl3BhMScijTGJQ0m5cP139uAawq9NJRUINLLX6AB3RI0IY03HJd8hvgq vY+3i1gglVr+H1ZBFE1JhrNQ9eIgMYZQB6718+SsKUaLPPsCVHfegNMBASAMxmsKROBN Wr1J919Pbj471QsAsIBXwyrSrm0FVYM6Wi0hWR8tr96KiLiBsdzhqnk/KmVY9+dI94tg XgM6DojWL4zarVxz0YaJTO78W4oEn1kHBEkDr9AJNo0N0os7VAo8wi37Hxmaz9oHqVWv w/xQ== X-Forwarded-Encrypted: i=1; AJvYcCXNaVOYB9JL5rBwTnQpHFeLk5ghZDlDNzT1xzCJaxtGXYF7i6O+MS56kz4gpwyrceUfLZAkRjH06TWRhP4RZ8rZnaaY76GVkE+UXHn3 X-Gm-Message-State: AOJu0YytqF16FxVlQpmJMLAesPMIp4DOH5zT4WVLKqKmldA0Ydal/dxJ laTWD9zzoMZeQ7VYlBKQ4lh2FJLqak5ZY31TFSIuXknGinJI+kP5cR3D75Iweh0= X-Received: by 2002:a05:651c:1504:b0:2ea:b956:db2b with SMTP id 38308e7fff4ca-2eab956e51amr9894891fa.7.1717435808755; Mon, 03 Jun 2024 10:30:08 -0700 (PDT) Received: from ?IPv6:2804:5078:851:4000:58f2:fc97:371f:2? ([2804:5078:851:4000:58f2:fc97:371f:2]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70242c247b0sm5738852b3a.216.2024.06.03.10.30.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jun 2024 10:30:08 -0700 (PDT) Message-ID: <3092cdf003427c6be942d2b8fa0671c084f8ebd9.camel@suse.com> Subject: Re: [PATCH v2] selftests: livepatch: Test atomic replace against multiple modules From: Marcos Paulo de Souza To: Petr Mladek Cc: Joe Lawrence , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Shuah Khan , live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 03 Jun 2024 14:29:55 -0300 In-Reply-To: References: <20240525-lp-atomic-replace-v2-1-142199bb65a1@suse.com> <92d683bd138a76e6c7100f4984be202dd06c9424.camel@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.1 (by Flathub.org) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2024-06-03 at 14:52 +0200, Petr Mladek wrote: > On Fri 2024-05-31 18:06:48, Marcos Paulo de Souza wrote: > > On Fri, 2024-05-31 at 15:44 -0400, Joe Lawrence wrote: > > > 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. > > > >=20 > > > > Signed-off-by: Marcos Paulo de Souza > > > > --- > > > > Changes since v1: > > > > * Added checks in the existing test-livepatch.sh instead of > > > > creating a > > > > =C2=A0 new test file. (Joe) > > > > * Fixed issues reported by ShellCheck (Joe) > > > > --- > > > > =C2=A0.../testing/selftests/livepatch/test-livepatch.sh=C2=A0 | 46 > > > > ++++++++++++++++++++-- > > > > =C2=A01 file changed, 42 insertions(+), 4 deletions(-) > > > >=20 > > > > 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 > > > > =C2=A0 > > > > =C2=A0# - load a livepatch that modifies the output from > > > > /proc/cmdline > > > > and > > > > =C2=A0#=C2=A0=C2=A0 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 > > > > -#=C2=A0=C2=A0 is still active > > > > +# - load two addtional livepatches and check the number of > > > > livepatch modules > > > > +#=C2=A0=C2=A0 applied > > > > +# - load an atomic replace livepatch and check that the other > > > > three modules were > > > > +#=C2=A0=C2=A0 disabled > > > > +# - remove all livepatches besides the atomic replace one and > > > > verify that the > > > > +#=C2=A0=C2=A0 atomic replace livepatch is still active > > > > =C2=A0# - remove the atomic replace livepatch and verify that none > > > > are > > > > active > > > > =C2=A0 > > > > =C2=A0start_test "atomic replace livepatch" > > > > @@ -119,12 +122,31 @@ load_lp $MOD_LIVEPATCH > > > > =C2=A0grep 'live patched' /proc/cmdline > /dev/kmsg > > > > =C2=A0grep 'live patched' /proc/meminfo > /dev/kmsg > > > > =C2=A0 > > > > +for mod in test_klp_syscall test_klp_callbacks_demo; do > > >=20 > > > Slightly nitpicky here, but the tests were originally written > > > with > > > the > > > livepatch module names via variables like $MOD_LIVEPATCH.=C2=A0 Would > > > using > > > $MOD_LIVEPATCH{1,2,3} help indicate that their specifics aren't > > > really > > > interesting, that we just need 3 of them? > >=20 > > Makes sense. I thought about it when I was changing the code, but I > > didn't want to change it too much, so it was the result. But that > > makes > > sense to have the modules better named. >=20 > I like this. >=20 > > > > + load_lp $mod > > > > +done > > > > + > > > > +mods=3D(/sys/kernel/livepatch/*) > > > > +nmods=3D${#mods[@]} > > > > +if [ "$nmods" -ne 3 ]; then > > > > + die "Expecting three modules listed, found $nmods" > > > > +fi > > > > + > > >=20 > > > 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.=C2=A0 But then I thought about this test, atomic replace! > > > Anything previously loaded is going to be pushed aside anyway. > > >=20 > > > 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?=C2=A0 That might also prevent some > > > collateral > > > damage when test A fails and leaves the world a strange place for > > > tests > > > B, C, etc. > >=20 > > We have been discussing about start/end functions that would check > > for > > leftover modules... maybe should be a good think to implement soon > > as > > we land more tests. >=20 > Makes sense :-) >=20 > > > > =C2=A0load_lp $MOD_REPLACE replace=3D1 > > > > =C2=A0 > > > > =C2=A0grep 'live patched' /proc/cmdline > /dev/kmsg > > > > =C2=A0grep 'live patched' /proc/meminfo > /dev/kmsg > > > > =C2=A0 > > > > -unload_lp $MOD_LIVEPATCH > > > > +mods=3D(/sys/kernel/livepatch/*) > > > > +nmods=3D${#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 > > > > =C2=A0 > > > > =C2=A0grep 'live patched' /proc/cmdline > /dev/kmsg > > > > =C2=A0grep 'live patched' /proc/meminfo > /dev/kmsg > > > > @@ -142,6 +164,20 @@ livepatch: '$MOD_LIVEPATCH': starting > > > > patching > > > > transition > > > > =C2=A0livepatch: '$MOD_LIVEPATCH': completing patching transition > > > > =C2=A0livepatch: '$MOD_LIVEPATCH': patching complete > > > > =C2=A0$MOD_LIVEPATCH: this has been live patched > > > > +% insmod test_modules/test_klp_syscall.ko > > >=20 > > > Similar minor nit here, too.=C2=A0 If we think copy/pasting all the > > > $MOD_FOO > > > is annoying, I am fine with leaving this as is.=C2=A0 I don't have a > > > strong > > > opinion other than following some convention. > > >=20 > > > With that, I'm happy to ack as-is or with variable names. > >=20 > > Thanks Joe! I think that is Petr's call, either way I can rework > > this > > patch, or send additional ones to adjust the tests. >=20 > I would prefer if you did respin this patch. The use of > $MOD_LIVEPATCH{1,2,3} would make even the patch easier to follow. Done in v3. About the pre-check, I discussed with Miroslav about having an easier way to skip tests. The idea was to split each "test" into a different file, like fstests already does. Using this approach, each start_test function will be placed in a different file to test specifically one functionality. This way we can skip a test if we don't have some requirements (like a sysfs attribute for example, or the there were leftover modules). I plan to send a patch starting this move when the v3 of this patchset is accepted. >=20 > Best Regards, > Petr