All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Chengfeng Ye <nicoyip.dev@gmail.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>, Florian Westphal <fw@strlen.de>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>
Subject: Re: [PATCH net v2] xfrm: retry inexact policy lookup after node reinsertion
Date: Mon, 21 Sep 2026 09:46:50 +0200	[thread overview]
Message-ID: <arDg6mhqpIy1kPSc@secunet.com> (raw)
In-Reply-To: <20260903145735.468999-1-nicoyip.dev@gmail.com>

On Thu, Sep 03, 2026 at 10:57:34PM +0800, Chengfeng Ye wrote:
> An inexact policy lookup first records pointers to candidate hlist heads
> and then traverses the lists.  A concurrent policy insertion can merge
> inexact tree nodes between those operations:
> 
>   lookup                         policy insertion
>   ------                         ----------------
>   find inexact candidates
>     save obsolete hlist head
>                                  write_seqcount_begin(&bin->count)
>                                  merge inexact tree nodes
>                                    hlist_del_rcu(&policy->bydst)
>                                    reinsert policy->bydst in survivor
>                                  write_seqcount_end(&bin->count)
>   evaluate saved candidate list
>     miss the moved policy
> 
> The merge immediately reinserts the same hlist node into the surviving
> tree node.  RCU keeps the policy alive, but it does not provide a
> consistent view while its list node is moved.  A lookup that selected the
> obsolete list can observe it empty.  A lookup already traversing a moved
> policy can instead follow the next pointer rewritten by the reinsertion.
> Either case can return an incorrect IPsec policy result.
> 
> The per-bin sequence counter already brackets calls to
> xfrm_policy_inexact_insert_node(), including node merges.  The read side,
> however, currently validates the counter only while searching an
> individual rb-tree.  A successful search returns without validation, and
> the later candidate-list traversal is outside that read-side section.
> 
> Snapshot the per-bin sequence before discovering candidate heads and
> validate it after evaluating all candidate lists.   Retry the lookup if
> the inexact policy tree changes while it is being searched.
> 
> Fixes: 9cf545ebd591 ("xfrm: policy: store inexact policies in a tree ordered by destination address")
> Cc: stable@vger.kernel.org
> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>

Applied, thanks a lot!

      reply	other threads:[~2026-09-21  7:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 14:57 [PATCH net v2] xfrm: retry inexact policy lookup after node reinsertion Chengfeng Ye
2026-09-21  7:46 ` Steffen Klassert [this message]

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=arDg6mhqpIy1kPSc@secunet.com \
    --to=steffen.klassert@secunet.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --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=nicoyip.dev@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    /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.