On Tue, Oct 20, 2020 at 04:18:00PM +0800, Zhuoliang Zhang wrote: > From: zhuoliang zhang <zhuoliang.zh...@mediatek.com> > > we found that the following race condition exists in > xfrm_alloc_userspi flow: > > user thread state_hash_work thread > ---- ---- > xfrm_alloc_userspi() > __find_acq_core() > /*alloc new xfrm_state:x*/ > xfrm_state_alloc() > /*schedule state_hash_work thread*/ > xfrm_hash_grow_check() xfrm_hash_resize() > xfrm_alloc_spi /*hold lock*/ > x->id.spi = htonl(spi) > spin_lock_bh(&net->xfrm.xfrm_state_lock) > /*waiting lock release*/ xfrm_hash_transfer() > spin_lock_bh(&net->xfrm.xfrm_state_lock) /*add x into > hlist:net->xfrm.state_byspi*/ > > hlist_add_head_rcu(&x->byspi) > > spin_unlock_bh(&net->xfrm.xfrm_state_lock) > > /*add x into hlist:net->xfrm.state_byspi 2 times*/ > hlist_add_head_rcu(&x->byspi) > > So the same xfrm_stame (x) is added into the same list_hash > (net->xfrm.state_byspi)2 times that makes the list_hash become > a inifite loop.
Your explanation makes no sense. Prior to obtaining the spin lock on the LHS, the state x hasn't been added to thte table yet. So how can the RHS be transferring it? Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
