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 2B383C3DA78 for ; Sat, 14 Jan 2023 07:18:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AACE8E0002; Sat, 14 Jan 2023 02:18:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 95A668E0001; Sat, 14 Jan 2023 02:18:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FCFB8E0002; Sat, 14 Jan 2023 02:18:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 710088E0001 for ; Sat, 14 Jan 2023 02:18:55 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 439D4A040B for ; Sat, 14 Jan 2023 07:18:55 +0000 (UTC) X-FDA: 80352552630.10.DDEE009 Received: from r3-11.sinamail.sina.com.cn (r3-11.sinamail.sina.com.cn [202.108.3.11]) by imf20.hostedemail.com (Postfix) with ESMTP id E7A1C1C0006 for ; Sat, 14 Jan 2023 07:18:50 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf20.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.11 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673680733; 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=E9VFHnJpwU3HUMSiAbHYp3Cap8urjHHwlm2s5tt8fGk=; b=1dL+WUWNcFjipmeGBoJ45tvHVGhiDp5iBeWkOnJB50J/cw4I0C6zxpoyvZfAAltjPn9GrC q9x/2vgTeL6lNYJup7KBB/f89SZkoTwsMCDp+U7WVfhYWW9hcCXxe0AxPdrIyJfqMfwSxj jI356xsbk900g5OWmn0x/1NM99Io6nA= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf20.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.11 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673680733; a=rsa-sha256; cv=none; b=owNasmMysOzWWNSdJJsLDdRX9rrXdc96lh6XMibaICRRV/+6Vg8Kff644eE+iYXuYnt6DC Lx+k80kBMdtXTtWCx4+LdTi0vlyakFYk58+SO1KWvPzzI4Jkln9xuzOddu1QIGaeS6MS6G HYUSa2+oRMdI/wHuikEVZvr5H4JZUN4= Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.27) with ESMTP id 63C256ED0001CF5D; Sat, 14 Jan 2023 15:17:03 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 7066949283834 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 15:18:32 +0800 Message-Id: <20230114071832.1162-1-hdanton@sina.com> In-Reply-To: References: <20230113065955.815667-1-boqun.feng@gmail.com> <20230113130330.1027-1-hdanton@sina.com> <20230113235809.1085-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E7A1C1C0006 X-Rspam-User: X-Stat-Signature: bqyswstwzwu5e35615tzwye4h3uao5uk X-HE-Tag: 1673680730-684132 X-HE-Meta: U2FsdGVkX1+IH1OQdrUw+dqlcxOgBmX9K7Ta0mJOlB4mqudAIjsh98z3i1pi0u6TttFmdIB2y+bNUTF7k2acOPG3pmqstoF/D+VmUyy1CFov9eKVsZDmpSmAqffsFEEes7Z/LEkLx0/w+SS4XFmP58T87hicJ1Hs+wfd2qz29AVtp6zYHEw7OQBaHUrxZsgGSU9BCcc3CF5I7hYC/QIrEfxfHlC85bUtiF1nxmGmKxdHk4CbSB/qSFZ+A6+Eil3MbvjGKF9DJxW8H4S+YL6czeBPAuXjel+mMAixPxZvPzeks6TvuylzDL9sDisxPuS5naNqxuj3eB/yjq8BkwOE32q3MhTF7Sbd1ayOfT0v/frzgl3Z5dSjWDtIJ+Q/f+0jw7V7dVraPdQxayGrSuR7IV4W+PW61QWJjVVbqYsuA2SAztH5wVe/mwMmeIg+covg+ldPyqbB8bTbzZb9DnyIMgxPYLNrhmIzNpmk5auyfHx5iUgsNCS6g/Nxx3gEntr3SISxHioU71rwEk/RcKerTerTKFhBwomH2aWLAupcp0NXE27MFZ2xh5Oj0KWf0BQZSNseUX+hU7a1oAkE4KacWiTuPTB+kG7ELBE319bcEzjIuESz7Cf+gUaFAqx46gYUptZgSNXhfKuxo1C07YijhvIZRuNh4ZHTsfIYncCYDvcwpJKNX7/TAtc/r773xrDlkR8t7cnK9QdbkhLgds2HoPhgZZEepKhHZ083BTdhT/l8PEiX3e4c/wrS1sxZVNP8Khx4oRkC0LWpo1trSBy/yQnyVNrboEw9mZVM7k32ATK+uzNGeerjYltelzS3pXOpkyffAWXX18BnBRi7CxT6VDEHRlVxQRl93VCQQMWtNdrTjdlURBXFrg== 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 Fri, 13 Jan 2023 16:17:59 -0800 Boqun Feng > On Sat, Jan 14, 2023 at 07:58:09AM +0800, Hillf Danton wrote: > > 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. > > Your example makes me more confused.. given the case: > > task X task Y > --- --- > mutex_lock(A); > srcu_read_lock(B); > synchronze_srcu(B); > mutex_lock(A); > > isn't it a deadlock? Yes and nope, see below. > If your example, A, B or E which one is srcu? A and B are mutex, and E is completion in my example to show the failure of catching deadlock in case of non-fake lock. Now see srcu after your change. task X task Y --- --- mutex_lock(A); srcu_read_lock(B); srcu_lock_acquire(&B->dep_map); a) lock_map_acquire_read(&B->dep_map); synchronze_srcu(B); __synchronize_srcu(B); srcu_lock_sync(&B->dep_map); lock_map_sync(&B->dep_map); lock_sync(&B->dep_map); __lock_acquire(&B->dep_map); b) lock_map_acquire_read(&B->dep_map); __lock_release(&B->dep_map); c) lock_map_acquire_read(&B->dep_map); mutex_lock(A); No deadlock could be detected if taskY takes mutexA after taskX releases B, and how taskY acquires B does not matter as per the a), b) and c) modes in the above chart, again because releasing lock can break deadlock in general.