All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antony Antony <antony@phenome.org>
To: Antony Antony <antony@phenome.org>
Cc: Sabrina Dubroca <sd@queasysnail.net>,
	Antony Antony <antony.antony@secunet.com>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Chiachang Wang <chiachangwang@google.com>,
	devel@linux-ipsec.org, Simon Horman <horms@kernel.org>,
	Paul Moore <paul@paul-moore.com>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	linux-kernel@vger.kernel.org, selinux@vger.kernel.org,
	Nathan Harold <nharold@google.com>, Yan Yan <evitayan@google.com>
Subject: Re: [devel-ipsec] Re: [PATCH ipsec-next v5 8/8] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
Date: Tue, 7 Apr 2026 15:29:37 +0200	[thread overview]
Message-ID: <adUGwQbs3L6esfZv@Antony2201.local> (raw)
In-Reply-To: <CADHa2dCdFKE4Wg-uSmYLmh1-JEf=rZOA2WUmRbTy0S0rp+rz+A@mail.gmail.com>

On Fri, Mar 13, 2026 at 05:32:15PM -0700, Yan Yan via Devel wrote:
> > yes I can add that. I would add XFRMA_SET_MARK/XFRMA_SET_MARK_MASK together.
> > If you set only the SET_MARK mask will be 0xffffffff.
> 
> > I am actually using xfrm_smark_init() which will accept both.
> 
> Great! Thanks for supporting that.
> 
> > Option 1: add XFRM_OFFLOAD_CLEAR to xfrm_user_offload flags in uapi xfrm.h:
> >
> > #define XFRM_OFFLOAD_CLEAR  (1 << 7)
> > When set in XFRMA_OFFLOAD_DEV, it means remove offload rather than configure it.
> >
> > Option 2: add a __u32 flags field to xfrm_user_migrate_state in uapi xfrm.h.
> > There is a __u16 reserved currently used for alignment, but 16 bits feels
> > too small if we want to cover clearing other attributes in the future.
> > A __u32 at the end of the struct avoids that constraint.
> >
> > I am leaning toward option 2. Any preference?
> 
> I'm also in favor of option 2 for better extensibility.
> 
> >     - XFRMA_REPLAY_ESN_VAL / XFRMA_REPLAY_VAL : may be later replay type
> >       should not change.
> 
> I agree we should keep the replay type immutable. Changing ESN flag on
> the fly would make it hard to keep both sides synced, and I'm not
> aware of any use case for this.

While testing XFRM_MSG_MIGRATE_STATE we ran into an issue with x->sel
migration in transport mode. In transport mode the selector is typically
a single-host entry matching the SA's saddr and daddr, so after
migration it only needs to be updated with the new addresses.

For this common case I added XFRM_MIGRATE_STATE_UPDATE_SEL to
xfrm_user_migrate_state.flags. When set, the kernel validates that the
existing selector is a single-host match for the SA addresses and
derives the new selector from new_daddr/new_saddr with the appropriate
mask for the new family.

I think this is the main use case. However, for corner cases out there,
the selector is not a simple single-host entry,
struct xfrm_user_migrate_state now carries a new_sel field. When
XFRM_MIGRATE_STATE_UPDATE_SEL is not set, new_sel is used as-is for
the migrated SA.

-antony

  reply	other threads:[~2026-04-07 13:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27 10:41 [PATCH ipsec-next v5 0/8] xfrm: XFRM_MSG_MIGRATE_STATE new netlink message Antony Antony
2026-01-27 10:42 ` [PATCH ipsec-next v5 1/8] xfrm: add missing __rcu annotation to nlsk Antony Antony
2026-02-26 17:07   ` Sabrina Dubroca
2026-03-05  7:46     ` [devel-ipsec] " Antony Antony
2026-01-27 10:42 ` [PATCH ipsec-next v5 2/8] xfrm: remove redundant assignments Antony Antony
2026-01-27 10:42 ` [PATCH ipsec-next v5 3/8] xfrm: allow migration from UDP encapsulated to non-encapsulated ESP Antony Antony
2026-01-30 11:28   ` Sabrina Dubroca
2026-02-02 12:57     ` Antony Antony
     [not found]       ` <CADhJOfbkUFaPfxTBrmOnrEh2JvxPKpkxaRrSdJHZGxeoQsQTcw@mail.gmail.com>
2026-02-02 19:38         ` [devel-ipsec] " Antony Antony
2026-02-24  3:28           ` Yan Yan
2026-02-26 15:41             ` Antony Antony
2026-03-06  2:49               ` Yan Yan
2026-01-27 10:42 ` [PATCH ipsec-next v5 4/8] xfrm: rename reqid in xfrm_migrate Antony Antony
2026-01-27 10:43 ` [PATCH ipsec-next v5 5/8] xfrm: split xfrm_state_migrate into create and install functions Antony Antony
2026-01-27 10:43 ` [PATCH ipsec-next v5 7/8] xfrm: add error messages to state migration Antony Antony
2026-01-30 12:14   ` Sabrina Dubroca
2026-02-26 15:43     ` [devel-ipsec] " Antony Antony
2026-02-26 16:59       ` Sabrina Dubroca
2026-03-02 14:06         ` Antony Antony
2026-01-27 10:44 ` [PATCH ipsec-next v5 8/8] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration Antony Antony
2026-02-03 21:25   ` Sabrina Dubroca
2026-02-26 15:46     ` Antony Antony
2026-02-26 18:05       ` Sabrina Dubroca
2026-03-02 14:21         ` [devel-ipsec] " Antony Antony
2026-02-27  1:44   ` Yan Yan
2026-02-27 11:26     ` [devel-ipsec] " Sabrina Dubroca
2026-02-27 23:14       ` Yan Yan
2026-03-08 14:42         ` Antony Antony
2026-03-10 11:09           ` Sabrina Dubroca
2026-03-10 16:52             ` Antony Antony
2026-03-14  0:32               ` Yan Yan
2026-04-07 13:29                 ` Antony Antony [this message]
2026-03-05  7:51     ` Antony Antony
2026-01-27 10:50 ` [PATCH ipsec-next v5 6/8] xfrm: add state synchronization after migration Antony Antony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adUGwQbs3L6esfZv@Antony2201.local \
    --to=antony@phenome.org \
    --cc=antony.antony@secunet.com \
    --cc=chiachangwang@google.com \
    --cc=davem@davemloft.net \
    --cc=devel@linux-ipsec.org \
    --cc=edumazet@google.com \
    --cc=evitayan@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nharold@google.com \
    --cc=omosnace@redhat.com \
    --cc=pabeni@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=sd@queasysnail.net \
    --cc=selinux@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=stephen.smalley.work@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.