From: Leon Romanovsky <leon@kernel.org>
To: Florian Westphal <fw@strlen.de>
Cc: Sabrina Dubroca <sd@queasysnail.net>,
netdev@vger.kernel.org,
Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH ipsec-next 01/10] xfrm: state: fix sparse warnings on xfrm_state_hold_rcu
Date: Tue, 10 Mar 2026 21:45:00 +0200 [thread overview]
Message-ID: <20260310194500.GO12611@unreal> (raw)
In-Reply-To: <abBv6zR4Qq_lrzuC@strlen.de>
On Tue, Mar 10, 2026 at 08:24:27PM +0100, Florian Westphal wrote:
> Leon Romanovsky <leon@kernel.org> wrote:
> > > > This change makes me wonder why we need both xfrm_state_hold_rcu() and
> > > > xfrm_state_hold().
> > >
> > > Commit 02efdff7e209 ("xfrm: state: use atomic_inc_not_zero to
> > > increment refcount") and the series around it [0] introduced the
> > > possibility of that refcount increment failing.
> > >
> > > I can't tell you why a 10-years-old commit made some choice, but
> > > keeping both variants has the benefit of documenting that one
> > > increment is expected to never fail (because we already hold a ref on
> > > the object on that path) and we can skip the error handling. We don't
> > > want to add error handling that will never get reached, it always goes
> > > wrong (because it's untested) and it adds uneeded complexity to the
> > > code.
> > >
> > > So I wouldn't get rid of xfrm_state_hold.
> >
> > So let's add some comment when this function should be used.
>
> Before rcu-ification, everything was serialized via state lock.
> Entries still in the state table thus always had > 0 refcounts.
>
> You can only use xfrm_state_hold() if the refcount is already > 0.
> xfrm_state_hold uses refcount_inc(), so you get a UaF warn splat
> if this assuption doesn't hold true.
I know it, the thing that bothers me is that it is unclear how
xfrm_state_hold_rcu() can have refcount equal to 0.
xfrm_state_put() decreases refcount and when it is zero, it calls
to __xfrm_state_destroy(). The latter assumes that the state was
already removed from various hlists.
For example:
1175 static struct xfrm_state *__xfrm_state_lookup(const struct xfrm_hash_state_ptrs *state_ptrs
1176 u32 mark,
1177 const xfrm_address_t *daddr,
1178 __be32 spi, u8 proto,
1179 unsigned short family)
1180 {
1181 unsigned int h = __xfrm_spi_hash(daddr, spi, proto, family, state_ptrs->hmask);
1182 struct xfrm_state *x;
1183
1184 hlist_for_each_entry_rcu(x, state_ptrs->byspi + h, byspi) {
<...>
1193 if (!xfrm_state_hold_rcu(x))
1194 continue;
1195 return x;
1196 }
1197
1198 return NULL;
1199 }
Thanks
next prev parent reply other threads:[~2026-03-10 19:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 10:32 [PATCH ipsec-next 00/10] xfrm: fix most sparse warnings Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 01/10] xfrm: state: fix sparse warnings on xfrm_state_hold_rcu Sabrina Dubroca
2026-03-10 10:31 ` Leon Romanovsky
2026-03-10 11:33 ` Sabrina Dubroca
2026-03-10 18:20 ` Leon Romanovsky
2026-03-10 19:24 ` Florian Westphal
2026-03-10 19:45 ` Leon Romanovsky [this message]
2026-03-10 19:49 ` Florian Westphal
2026-03-10 20:10 ` Leon Romanovsky
2026-03-10 21:41 ` Sabrina Dubroca
2026-03-11 7:36 ` Leon Romanovsky
2026-03-12 14:36 ` Sabrina Dubroca
2026-03-16 19:55 ` Leon Romanovsky
2026-03-12 6:27 ` Steffen Klassert
2026-03-09 10:32 ` [PATCH ipsec-next 02/10] xfrm: state: fix sparse warnings in xfrm_state_init Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 03/10] xfrm: state: fix sparse warnings around XFRM_STATE_INSERT Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 04/10] xfrm: state: add xfrm_state_deref_prot to state_by* walk under lock Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 05/10] xfrm: remove rcu/state_hold from xfrm_state_lookup_spi_proto Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 06/10] xfrm: state: silence sparse warnings during netns exit Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 07/10] xfrm: policy: fix sparse warnings in xfrm_policy_{init,fini} Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 08/10] xfrm: policy: silence sparse warning in xfrm_policy_unregister_afinfo Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 09/10] xfrm: add rcu_access_pointer to silence sparse warning for xfrm_input_afinfo Sabrina Dubroca
2026-03-09 10:32 ` [PATCH ipsec-next 10/10] xfrm: avoid RCU warnings around the per-netns netlink socket Sabrina Dubroca
2026-03-10 17:51 ` [PATCH ipsec-next 00/10] xfrm: fix most sparse warnings Simon Horman
2026-03-13 7:48 ` Steffen Klassert
2026-03-17 9:31 ` Steffen Klassert
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=20260310194500.GO12611@unreal \
--to=leon@kernel.org \
--cc=fw@strlen.de \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
--cc=steffen.klassert@secunet.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