Re: [PATCH v7 for-next 7/8] selftests/livepatch: Add test for state ID conflict across provides

On Wed, Sep 2, 2026 at 11:25 PM Petr Mladek [off-list ref] wrote:

On Tue 2026-08-25 19:46:40, Yafang Shao wrote:

quoted

Livepatches with different provides ids must not share the same state
id. If a second livepatch attempts to reuse a state id already
registered by a livepatch with a different provides id, the loading
will fail. However, if the second livepatch's obsoletes list includes
the first livepatch's provides id, the second livepatch replaces the
first one and may reuse the same state id.

Add provides and obsoletes module parameters to test_klp_state.c and
test_klp_state2.c (guarded by #ifndef KLP_HAS_REPLACE) so that they
can be loaded with different provides ids and obsoletes ids.

Add a "state id conflict across provides" test scenario to
test-provides.sh:

  - Load test_klp_state with provides=1, which registers state ID 1.
  - Attempt to load test_klp_state2 with provides=2, which reuses the
    same state ID 1. The second livepatch is rejected because
    livepatches with different provides ids must not share the same
    state id.
  - Disable and unload the remaining livepatch.

Add a "taking over system state via obsoletes" test scenario to
test-state.sh:

  - Load test_klp_state with provides=10, which registers state ID 1.
  - Load test_klp_state2 with provides=20 obsoletes=10, which reuses the
    same state ID 1. Although the provides ids differ, the second livepatch
    replaces the first one because its obsoletes list includes the first
    livepatch's provides id (10). The state is taken over successfully.
  - Unload the replaced livepatch, then disable and unload the second
    livepatch.

Assisted-by: Comagic:DeepSeek-V4-Flash
Signed-off-by: Yafang Shao <redacted>
---
 .../livepatch/test-provides-obsoletes.sh      | 86 +++++++++++++++++++
 .../livepatch/test_modules/test_klp_state.c   |  9 ++
 .../livepatch/test_modules/test_klp_state2.c  | 19 ++++
 3 files changed, 114 insertions(+)

diff --git a/tools/testing/selftests/livepatch/test-provides-obsoletes.sh b/tools/testing/selftests/livepatch/test-provides-obsoletes.sh
index 2707457b9133..f9a9f9b28490 100755
--- a/tools/testing/selftests/livepatch/test-provides-obsoletes.sh
+++ b/tools/testing/selftests/livepatch/test-provides-obsoletes.sh

@@ -6,6 +6,8 @@

 MOD_ATOMIC=test_klp_atomic_replace
 MOD_LIVEPATCH=test_klp_livepatch
+MOD_STATE=test_klp_state
+MOD_STATE2=test_klp_state2

 setup_config

@@ -171,4 +173,88 @@ livepatch: '$MOD_ATOMIC': completing unpatching transition
 livepatch: '$MOD_ATOMIC': unpatching complete
 % rmmod $MOD_ATOMIC"

+# - load a livepatch with provides=1 that registers state ID 1
+# - try to load another livepatch with provides=2 that reuses the same
+#   state ID. The second one must be rejected because livepatches with
+#   different provides ids must not share the same state id.
+# - disable and unload the remaining livepatch
+
+start_test "state id conflict across provides"
+
+load_lp $MOD_STATE provides=1
+load_failing_mod $MOD_STATE2 provides=2

It is not obvious why it should fail because we do not know the used
state id. It might be better to define it via a parameter. It would
even allow to test more variants:

# same state, same provides
load_lp $MOD_STATE_LP1 state=1 provides=1
load_lp $MOD_STATE_LP2 state=1 provides=1

# same state, misc provides
load_lp $MOD_STATE_LP1 state=1 provides=1
load_failing_mod $MOD_STATE_LP2 state=1 provides=2

# same states, replaced by obsoletes
load_lp $MOD_STATE_LP1 state=1 provides=1
load_lp $MOD_STATE_LP2 state=1 provides=2 obsoletes=1

# misc states, same provides
load_lp $MOD_STATE_LP1 state=1 provides=1
load_failing_mod $MOD_STATE_LP2 state=2 provides=1

# misc states, misc provides
load_lp $MOD_STATE_LP1 state=1 provides=1
load_lp $MOD_STATE_LP2 state=2 provides=2

Makes sense.
I will update it.

-- 
Regards
Yafang