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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E26CAC6379F for ; Fri, 13 Jan 2023 23:58:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 774668E0002; Fri, 13 Jan 2023 18:58:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 724AD8E0001; Fri, 13 Jan 2023 18:58:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EC1F8E0002; Fri, 13 Jan 2023 18:58:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 505218E0001 for ; Fri, 13 Jan 2023 18:58:29 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 29676A015F for ; Fri, 13 Jan 2023 23:58:29 +0000 (UTC) X-FDA: 80351442738.28.0510292 Received: from r3-24.sinamail.sina.com.cn (r3-24.sinamail.sina.com.cn [202.108.3.24]) by imf23.hostedemail.com (Postfix) with ESMTP id D8A49140007 for ; Fri, 13 Jan 2023 23:58:25 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.24 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673654307; a=rsa-sha256; cv=none; b=24zZUZSZM+wZ9IViEcYkltQof7gFdhqtYSBGPB4g2YY7Wf5EkU26fIEZOKizCF5O6yi3z1 4rBgikHIp+KifPJsnxtsSixekq+VbezNPq7Vx3LXctlTPdmWjwd9IZsd9xeVt3Vm1QiCtN K/XsKeQVdyys9mnhWM+PRMTXAk3B78o= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.24 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673654307; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HaIL0CsWza1bdE/eqU3XEFO9X97xuIwnPeR3HERYxLA=; b=z6XOV6NlqDpfQyTArUl/O+xQKn3aXluBWA5dWxkZtB+RN8pnhkjwNdULuBTVjD0LHpfiXW dG1PttJIkM8QFY9CtEYKWQSsh3jlGbm5vcIPY/RX0uMd5RPMw3JOvgb7DEbWLvEtVgxaLf 38q8PU61Og5i95Rcpm/fPwTHUe4guEU= Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.23) with ESMTP id 63C1EF630002CFFC; Fri, 14 Jan 2023 07:55:17 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 8421054922167 From: Hillf Danton To: Boqun Feng Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Peter Zijlstra , "Paul E. McKenney" , Paolo Bonzini , Joel Fernandes Subject: Re: [PATCH 2/3] rcu: Equip sleepable RCU with lockdep dependency graph checks Date: Sat, 14 Jan 2023 07:58:09 +0800 Message-Id: <20230113235809.1085-1-hdanton@sina.com> In-Reply-To: References: <20230113065955.815667-1-boqun.feng@gmail.com> <20230113130330.1027-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: D8A49140007 X-Rspamd-Server: rspam01 X-Stat-Signature: qjwjmjnks5rp7aa6kpj5fqon8mgace3j X-HE-Tag: 1673654305-177294 X-HE-Meta: U2FsdGVkX1/8iImJNbO/aBBnzFz/3plJGfKaWK5/U0dGg3mHhjujd9q40M65gP6Jjevi9iyMjM41CHeoxkq+RPtEBlQsaSjkpy/3hwJlMAol7WnKLLXmCWXAKRIUbMugQcT/12uZez0L6HQuuBWaCLx3eS+Brrp9tTxYEeziuQnJZaRFR99RGc2XqtbUmADYkY34PBM6eig2Uyrss7Z5HVotmJiGUBgNAf1FNs2t+KMfJ22mg14YFqJRbOClAM2DT6nehap/Ia9h7imSUsq5X5QxxwTZEumqadTBHXUxdKXGsJN4Q6BAK9KMsZhM7BM1bsIKSQakxlv9UbFtiPs/69WGvEC2JyoR5PXE8bRhPaT2kD8a45G2xHUzL2o06ef/OsCaDVyk4dU7yXR8pDfo4oyqeM3ctspCjm1QxDFkIQ8fkeWkVtiseP1wJxq0Ztp60xDifqYYl5wHugUxEvOkXfTgoWfq9/65FcafLqHMLDmqXCvOu8AIvLSPZUCHv6aNwWPwCHoNtXVYj5kuXhaN8iKG8bLufj+/qGKfOqpZp/XI+Ko21xMSThcZPOFT/GKOz/0a6ndGbOZ0pIurIZARz6OUadmyaTnEwNBmf5DNtB8rk5kzOUjHA8fAoL/IeOk7C1/cRC37foRFMk9b1kEVC0nJEmwTW8wntLEqWmqC8MIZKwhgqbfHwWZg+sz49v0RMHs/TWUlanFBjnhIK/87j4q27txF3SBCchiNYhsPRNrd+OTPRylvIVKGGh/nrSyyGJpfO+afdDuBVflNX00xHXxyAlqIqp0WLmiCZ8KBadcTgWT0rb6uDPyNzrcVcz7fldS6PC9BDo0A5CL9kNQQFKEqbPe1Z7qUC2fKe4xE7BFDFIzTy2ZZtw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 13 Jan 2023 09:58:10 -0800 Boqun Feng > On Fri, Jan 13, 2023 at 09:03:30PM +0800, Hillf Danton wrote: > > On 12 Jan 2023 22:59:54 -0800 Boqun Feng > > > --- a/kernel/rcu/srcutree.c > > > +++ b/kernel/rcu/srcutree.c > > > @@ -1267,6 +1267,8 @@ static void __synchronize_srcu(struct srcu_struct *ssp, bool do_norm) > > > { > > > struct rcu_synchronize rcu; > > > > > > + srcu_lock_sync(&ssp->dep_map); > > > + > > > RCU_LOCKDEP_WARN(lockdep_is_held(ssp) || > > > lock_is_held(&rcu_bh_lock_map) || > > > lock_is_held(&rcu_lock_map) || > > > -- > > > 2.38.1 > > > > The following deadlock is able to escape srcu_lock_sync() because the > > __lock_release folded in sync leaves one lock on the sync side. > > > > cpu9 cpu0 > > --- --- > > lock A srcu_lock_acquire(&ssp->dep_map); > > srcu_lock_sync(&ssp->dep_map); > > lock A > > But isn't it just the srcu_mutex_ABBA test case in patch #3, and my run > of lockdep selftest shows we can catch it. Anything subtle I'm missing? I am leaning to not call it ABBA deadlock, because B is unlocked. task X task Y --- --- lock A lock B lock B unlock B wait_for_completion E lock A complete E And no deadlock should be detected/caught after B goes home.