From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B757FC388F2 for ; Thu, 22 Oct 2020 06:01:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 31DB12244C for ; Thu, 22 Oct 2020 06:01:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="waUZWzqB"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="JqQgzu93" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31DB12244C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vUa4KDY4wEsU6OUwyGYbQtWXqJTm0j6NYnMCscEHW7M=; b=waUZWzqBIQqJaiqjXRCb68fh1 QWxoXOVJiBwLzhmZsHV16NFRLTaYasDi6M4t/8CqY58xbrHO7ZDWsbvZZR9vafX2ggk7+BEmoOeMA XKohbDL31zGQ2I7nlHDGXCikwNf5HdqTAIgScl564C5U+BKsJ9UUnUjwuodvL/gR3++B2pJbdXaBZ uy97oOxh0Pb8sWyJaDEm9SJz1O1cHEr7f6zVPPW6OCi7Q8KLa/prKZODaYdBx4sgQXEZH8kd0E/qK G8kU7/LSGtdagnP7wym827y9Kuctki6cVejKMbYOR9eEkH7eiY5u7FWtAeY+heo/UzY0pq6dzT5Ll W4/XE6Q7Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVTdz-0005Jt-SW; Thu, 22 Oct 2020 06:00:11 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVTdw-0005Ia-8G; Thu, 22 Oct 2020 06:00:09 +0000 X-UUID: af2babcb47284fff9892a57b5916142b-20201021 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=2RTnJ5bggE6yxjCSkF508vcLzRCyBm7i8MbqmzI5xrI=; b=JqQgzu936rBhuHQI3LFgeASeZrxW9MyxnzZn0RyGO0D+xCRrndvCz7uyEaVfqQF1Ydz6NqbdjXckxyvK4+e7y1VJr3mnE+uAzz5gaSPqyJVQTZ2718oV1leaDB1FRn9TUMGM1tkT9ZCDG/JmJ4e4watrjg2yKhRoOqVCVoOkgqA=; X-UUID: af2babcb47284fff9892a57b5916142b-20201021 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 509836399; Wed, 21 Oct 2020 21:59:50 -0800 Received: from MTKMBS01N1.mediatek.inc (172.21.101.68) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Oct 2020 22:59:49 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Oct 2020 13:59:47 +0800 Received: from [10.15.20.246] (10.15.20.246) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 22 Oct 2020 13:59:47 +0800 Message-ID: <1603345995.13237.2.camel@mbjsdccf07> Subject: Re: [PATCH] net: xfrm: fix a race condition during allocing spi From: zhuoliang.zhang To: Herbert Xu Date: Thu, 22 Oct 2020 13:53:15 +0800 In-Reply-To: <20201021071222.GA11474@gondor.apana.org.au> References: <20201020081800.29454-1-zhuoliang.zhang@mediatek.com> <20201021071222.GA11474@gondor.apana.org.au> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_020008_486196_22880737 X-CRM114-Status: GOOD ( 14.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Steffen Klassert , wsd_upstream@mediatek.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, Matthias Brugger , Jakub Kicinski , "David S . Miller" , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org hi maintainer: there are 2 related hash lists : net->xfrm.state_bydst and net->xfrm.state_byspi: 1. a new state x is alloced in xfrm_state_alloc() and added into the bydst hlist in __find_acq_core() on the LHS; 2. on the RHS, state_hash_work thread travels the old bydst and tranfers every xfrm_state (include x) to the new bydst hlist and new byspi hlist; 3. user thread on the LHS gets the lock and adds x to the new byspi hlist again. thanks On Wed, 2020-10-21 at 18:12 +1100, Herbert Xu wrote: > On Tue, Oct 20, 2020 at 04:18:00PM +0800, Zhuoliang Zhang wrote: > > From: zhuoliang zhang > > > > 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, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel