From: Steffen Klassert <steffen.klassert@secunet.com>
To: Yan Yan <evitayan@google.com>
Cc: <netdev@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, <lorenzo@google.com>,
<maze@google.com>, <nharold@google.com>,
<benedictwong@google.com>
Subject: Re: [PATCH v1 1/2] xfrm: Check if_id in xfrm_migrate
Date: Wed, 12 Jan 2022 08:32:42 +0100 [thread overview]
Message-ID: <20220112073242.GA1223722@gauss3.secunet.de> (raw)
In-Reply-To: <20220108013230.56294-1-evitayan@google.com>
On Fri, Jan 07, 2022 at 05:32:30PM -0800, Yan Yan wrote:
> This patch enables distinguishing SAs and SPs based on if_id during
> the xfrm_migrate flow. This ensures support for xfrm interfaces
> throughout the SA/SP lifecycle.
>
> When there are multiple existing SPs with the same direction,
> the same xfrm_selector and different endpoint addresses,
> xfrm_migrate might fail with ENODATA.
>
> Specifically, the code path for performing xfrm_migrate is:
> Stage 1: find policy to migrate with
> xfrm_migrate_policy_find(sel, dir, type, net)
> Stage 2: find and update state(s) with
> xfrm_migrate_state_find(mp, net)
> Stage 3: update endpoint address(es) of template(s) with
> xfrm_policy_migrate(pol, m, num_migrate)
>
> Currently "Stage 1" always returns the first xfrm_policy that
> matches, and "Stage 3" looks for the xfrm_tmpl that matches the
> old endpoint address. Thus if there are multiple xfrm_policy
> with same selector, direction, type and net, "Stage 1" might
> rertun a wrong xfrm_policy and "Stage 3" will fail with ENODATA
> because it cannot find a xfrm_tmpl with the matching endpoint
> address.
>
> The fix is to allow userspace to pass an if_id and add if_id
> to the matching rule in Stage 1 and Stage 2 since if_id is a
> unique ID for xfrm_policy and xfrm_state. For compatibility,
> if_id will only be checked if the attribute is set.
>
> Tested with additions to Android's kernel unit test suite:
> https://android-review.googlesource.com/c/kernel/tests/+/1668886
>
> Signed-off-by: Yan Yan <evitayan@google.com>
What is the difference between this patch and the one with
the same subject you sent on Jan 5th?
next prev parent reply other threads:[~2022-01-12 7:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-08 1:32 [PATCH v1 1/2] xfrm: Check if_id in xfrm_migrate Yan Yan
2022-01-12 7:32 ` Steffen Klassert [this message]
2022-01-12 22:53 ` Yan Yan
2022-01-17 11:46 ` Steffen Klassert
-- strict thread matches above, loose matches on Subject: below --
2022-01-06 0:52 [PATCH v1 0/2] Fix issues " Yan Yan
2022-01-06 0:52 ` [PATCH v1 1/2] xfrm: Check if_id " Yan Yan
2021-12-23 0:45 [PATCH v1 0/2] Fix issues " Yan Yan
2021-12-23 0:45 ` [PATCH v1 1/2] xfrm: Check if_id " Yan Yan
2021-12-25 18:30 ` kernel test robot
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=20220112073242.GA1223722@gauss3.secunet.de \
--to=steffen.klassert@secunet.com \
--cc=benedictwong@google.com \
--cc=davem@davemloft.net \
--cc=evitayan@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=lorenzo@google.com \
--cc=maze@google.com \
--cc=netdev@vger.kernel.org \
--cc=nharold@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).