Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3571097pxj; Mon, 21 Jun 2021 01:33:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwp8ZLCAn+kG+2uIDxKIhRIBZvF/xeOlNSWIjteG0x3JiJJu5hSf942bqFzJ6QC0L9IInlw X-Received: by 2002:a17:906:4c8c:: with SMTP id q12mr23648343eju.254.1624264381265; Mon, 21 Jun 2021 01:33:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624264381; cv=none; d=google.com; s=arc-20160816; b=hZeb3djszwLxthXAVLfDliXjh6chDmpDDI6I+7goXEnd/oNsQpdFdn+buVCOEOAoOe uWipO/C50kRo7haRtFlmMPeoDBK5AI6zTob3pyFjFAu8Z7F8pI1U/ZiLehjUVCA47uwu MktmtAY5O6L2dVdYAdZf7MfmHJH2U40Py+RGPwKcQ/0axxOmuqD474+oTFHJK10zYoE3 hVJ6rSQsSVC1k3Q96x6arxAbEOPtOOi2YTwMITJ+/W2sG6kxIKwxqmzA7kbqcIopCNkP tQncgSbQSMTjbi0e/s0zE8vWkzs6HPAK50DSRkUfM2KHQt6HMi3tBOlwX2xo6NTfVPzJ qgIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=02PrXNWOK95d7w3GQPbh55xvHxPSIKnwIKbtEiK8q58=; b=r9S8fxPAJOBmL9OKeq+Gr/eks3VLr6aZbnSy5JRV034owvHAazKqQILoBxgZlkG3m/ oURzrFZf/k6RiUh3mKiDZDuxJ+8MM0FR8+WaKOPC+ar0+bxD8WH7ZWyLZeog2Z0kUpF+ OBqWSyQAA1DiuEf2qVxyVzPqCQBjYPz9BHYM08klG3UUGx8xZGUz7A432ibeF0ugi5Vt YpGQ3fjB0Pb+mK1ENnLNb02bWWsumwrJv7qAPLCfHhyO/9ZCjslCxSnAEx9S4LkvYNy6 TUQiTgxtTo9ImBDBqI04u11FSz/eratgGQ0h92pEik+g/foYYCbelJLyeBfIzw9q29he Q6nQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m12si7248615edc.65.2021.06.21.01.32.39; Mon, 21 Jun 2021 01:33:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230288AbhFUIcH (ORCPT + 99 others); Mon, 21 Jun 2021 04:32:07 -0400 Received: from mailout1.secunet.com ([62.96.220.44]:57788 "EHLO mailout1.secunet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230137AbhFUIcG (ORCPT ); Mon, 21 Jun 2021 04:32:06 -0400 Received: from cas-essen-01.secunet.de (unknown [10.53.40.201]) by mailout1.secunet.com (Postfix) with ESMTP id 2005D80004E; Mon, 21 Jun 2021 10:29:50 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by cas-essen-01.secunet.de (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 21 Jun 2021 10:29:49 +0200 Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 21 Jun 2021 10:29:49 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 899D131803E8; Mon, 21 Jun 2021 10:29:49 +0200 (CEST) Date: Mon, 21 Jun 2021 10:29:49 +0200 From: Steffen Klassert To: Varad Gautam CC: , linux-rt-users , , Herbert Xu , "David S. Miller" , "Jakub Kicinski" , Florian Westphal , "Ahmed S. Darwish" , Frederic Weisbecker , Subject: Re: [PATCH] xfrm: policy: Restructure RCU-read locking in xfrm_sk_policy_lookup Message-ID: <20210621082949.GX40979@gauss3.secunet.de> References: <20210618141101.18168-1-varad.gautam@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20210618141101.18168-1-varad.gautam@suse.com> X-ClientProxiedBy: cas-essen-02.secunet.de (10.53.40.202) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 18, 2021 at 04:11:01PM +0200, Varad Gautam wrote: > Commit "xfrm: policy: Read seqcount outside of rcu-read side in > xfrm_policy_lookup_bytype" [Linked] resolved a locking bug in > xfrm_policy_lookup_bytype that causes an RCU reader-writer deadlock on > the mutex wrapped by xfrm_policy_hash_generation on PREEMPT_RT since > 77cc278f7b20 ("xfrm: policy: Use sequence counters with associated > lock"). > > However, xfrm_sk_policy_lookup can still reach xfrm_policy_lookup_bytype > while holding rcu_read_lock(), as: > xfrm_sk_policy_lookup() > rcu_read_lock() > security_xfrm_policy_lookup() > xfrm_policy_lookup() Hm, I don't see that call chain. security_xfrm_policy_lookup() calls a hook with the name xfrm_policy_lookup. The only LSM that has registered a function to that hook is selinux. It registers selinux_xfrm_policy_lookup() and I don't see how we can call xfrm_policy_lookup() from there. Did you actually trigger that bug?