Hi Antony,

I ran the following test cases and two—4.2 and 6—are worth disucssing:

1.  Mark Inheritance: Creates one SA and migrates it without
specifying a new mark. [PASSED]
2.  Mark Update: Creates one SA with a specific mark and migrates it
to a new specific mark. [PASSED]
3.  State Update Isolation: Creates two SAs differing only by mark and
verifies that migrating one does not affect the other. [PASSED]
4.  Mark Collision:
    4.1 [Specific Mark] Creates two SAs differing only by mark: SA
(mark_1) and an SA (mark_2). Verifies migrating SA (mark_1) to mark_2
fails with EEXIST and both SAs intact. [PASSED]
    4.2 [Wildcard Mark] Creates two SAs differing only by mark: SA
(mark_1) and an SA (mark_none). Migrate the mark_none to mark_1.
Expecting failure with EEXIST and both SAs intact. [FAILED: SA
(mark_none) ends up being deleted]
5.  Mark Mismatch:
    5.1 Creates only a wildcard SA and verifying migration using a
specific mark fails with ESRCH; SA intact [PASSED]
    5.2 Creates only one SA (mark_1) and verifying migration using a
mark_2 fails with ESRCH; SA intact [PASSED]
6.  Mark Shadowing Failure:: Creates two SAs differing only by mark:
the first SA (mark_1) and the second SA (mark None). Migrating the SA
(mark_1) fails with ESRCH, two SAs remain untouched [PASSED]

--------------------------------
My questions are as follows:

Regarding 4.2 I believe is a kernel bug. During the pre-migration
collision check, the lookup for the mark_1 matches the wildcard SA
itself first, causing the kernel to miss the collision with the
existing specific SA with mark_1

At https://github.com/antonyantony/linux/blob/migrate-state-fixes-v0/net/xfrm/xfrm_user.c#L3450

x_new = xfrm_state_lookup(net, new_mark_key, &m.new_daddr, ----> BUG:
We are looking for the existence of SA (mark_1) but SA (mark_none) is
returned.
um->id.spi, um->id.proto, m.new_family);
if (x_new) {
    xfrm_state_put(x_new);
    if (x_new != x) { ----> BUG: We end up having x_new == x
    NL_SET_ERR_MSG(extack, "New SA tuple already occupied");
    err = -EEXIST;
    goto out;
}
/* self-match via wide mark mask; not a collision */

Would it be possible to traverse the entire list or create a lookup
method for an exact match?

Regarding  6.  I wrote the tests as per the kernel implementation but
I'm not sure it is intended. Intuitively, this migration should
succeed by finding and updating the specific SA (mark_1) instead of
failing. Is this failure considered an acceptable limit, or should we
aim to support exact-match lookup here?



On Wed, Jun 24, 2026 at 6:45 PM Yan Yan [off-list ref] wrote:

Hi Antony,

Sure, I'm happy to write and run some tests. I should be able to have the results by the end of the week.



--
--
Best,
Yan

--
--
Best,
Yan