public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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

  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