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 88FC3C3DA78 for ; Sat, 14 Jan 2023 07:32:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF8038E0002; Sat, 14 Jan 2023 02:32:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA9528E0001; Sat, 14 Jan 2023 02:32:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D489C8E0002; Sat, 14 Jan 2023 02:32:08 -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 C61678E0001 for ; Sat, 14 Jan 2023 02:32:08 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 98C61AAB9E for ; Sat, 14 Jan 2023 07:32:08 +0000 (UTC) X-FDA: 80352585936.02.C6CB662 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf10.hostedemail.com (Postfix) with ESMTP id 95B4BC0008 for ; Sat, 14 Jan 2023 07:32:06 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=l6natnlT; spf=pass (imf10.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673681526; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ger4KU2Dz1Vds6traYL5dkaNpaTLAmJJXmZXIGQX0Go=; b=qCxPIrfgYIZvGSaujq3HWrrL4InNASN6qLjTI6A5f6We/ERPeszTxnBwo0eVVWMX3rFehG pXKO2ukYFQ/vC1piERGjWyjVPXMwkMyqeDECCZqJGS+CTlWlxcu4CxZW3J6hmsJmChESwC WbAFooLhbPX0QVOg6NWrD8+RoUFWgks= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=l6natnlT; spf=pass (imf10.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673681526; a=rsa-sha256; cv=none; b=aNSjS7NT3wKSbfthg4xAE0PZVL+dhcce765gH+OBil4bmUVWBOUYFksqTtabEnpVBO/RSG ScJAp1cK3U+V6V0r7tv2gmXREPu0CATvXWd4CJGTAr9z7TO19gmOEEyolzlBGglfDIoE8X kBXbjnqpAWlESm9q3Kj3iybTtHJjoSk= Received: by mail-qv1-f42.google.com with SMTP id i12so16304761qvs.2 for ; Fri, 13 Jan 2023 23:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=ger4KU2Dz1Vds6traYL5dkaNpaTLAmJJXmZXIGQX0Go=; b=l6natnlT8vZp5PX2iQevJjy3+OPB86O+uFWg3f8ui7GNca947pzG9q4trP8XwOfmN7 HJXWPTiscg+HTrapAKJEKSgasjEpWbY+kwFeQPJQxfAlMgOd8CU8gtn3291Sb7visRZw 1cPvPavPJhn/gVtZsuyuwzfm9hbnc8CTUT+ZJDBM8kXp2b6GGBRfJWoH4HI2oywwjxKJ 6bgXqlQU7slphPyd6r0V7zeOl+/Ifif72+by4bbY3DpogwlCfGOQ+0bq83Ghid1ZgPjr dPtYem45/5NCpaGfPg3o7UvRJ4C2HSEX9D++2kRe2iO8ib46vltk3+QG7qd8OY3k43pW ur8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ger4KU2Dz1Vds6traYL5dkaNpaTLAmJJXmZXIGQX0Go=; b=M78YEosYy9kdQ3RMUodWeuFFy5tLKFdy3RO4koQ/o6DaklcZxa5w2ZnIfUFBk6l8E4 0eRF5xq2u64A96NDtV8isWHJlOdHALpDBB+oon2Pds5AWk7QnpuAvdnh09JJBN7c3aLy tfkQBM5iLJ4LezwoYxtuZi2lrJprbj9BjIx6SeJQs7nbkDNoQ3Nd9YGQjVWc67db+lQS 5UKIudpnAzY4pXz5y1Kx47fZdPts7H24Kr7/1QaTwvCE9APmE8r4rmIdk0IanBs6iZMY ETitsrHfzF7qKAbKsixYpj7c/zooaTcDHpFRMZ/qcOGy05oM0JpUidcYKHITYJ/RTH5G 8hSQ== X-Gm-Message-State: AFqh2ko/DZ0xFhY5CRGAgE7FmYXmIRBn1u8LniBnsb+OhKpLMqt+KHXt 5IGQYooqjUBRkVzG59i7HOY= X-Google-Smtp-Source: AMrXdXvesyww/w6Xe8QvYhchlxrT6S7HVfagJBYMOXB4mutPAAdRicpPcWicbz4/tXET4PPeYnNB6Q== X-Received: by 2002:a0c:aa07:0:b0:531:9e7a:6778 with SMTP id d7-20020a0caa07000000b005319e7a6778mr16744561qvb.1.1673681525761; Fri, 13 Jan 2023 23:32:05 -0800 (PST) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com. [66.111.4.228]) by smtp.gmail.com with ESMTPSA id l14-20020a05620a28ce00b007062139ecb3sm2222815qkp.95.2023.01.13.23.32.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jan 2023 23:32:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 6F93427C0054; Sat, 14 Jan 2023 02:32:03 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 14 Jan 2023 02:32:04 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrleelgdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhu nhcuhfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeehudfgudffffetuedtvdehueevledvhfelleeivedtgeeuhfegueeviedu ffeivdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gsohhquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdei gedqudejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfih igmhgvrdhnrghmvg X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 14 Jan 2023 02:32:02 -0500 (EST) Date: Fri, 13 Jan 2023 23:32:01 -0800 From: Boqun Feng To: Hillf Danton 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 Message-ID: References: <20230113065955.815667-1-boqun.feng@gmail.com> <20230113130330.1027-1-hdanton@sina.com> <20230113235809.1085-1-hdanton@sina.com> <20230114071832.1162-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230114071832.1162-1-hdanton@sina.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 95B4BC0008 X-Rspam-User: X-Stat-Signature: og4k4kr5wttk6nrosdnm6iwqkdpmbrry X-HE-Tag: 1673681526-195570 X-HE-Meta: U2FsdGVkX18VZjnygtAoWrbPMzLReE7BKtX+UIokGZ4ipWtANnShWQ38UvFRYToy5Q1URZMUx7K8KGOt/Jtrwmrhp4a4pF0aImLgUNutv2xjCRikOhxVshHZbbkq79A4NfCCdATJf+n8CQVReJaLV9ia0yu+3tpKEF8FNiUfBiQc53VxMjiZKony/oxRd4OjFdE8hz/dNR8C3edndT//5vROZ3XVX2KUZH7mLXPMcToCAuzpE4nwjh9w9MmeNJRYhq7XeILcfO0i1rocKtWayH/QqYXkGcmfOGpJzYCBKnWx1B07bTTyXNm6hQ3spD4vCGk/wU8Xee6i57fR++ItezLuAV+YQ5Bgu5eBxHbraPOowped8IGxXHhhFwOO72kLUvIHum8g8FnLLG3bPbd0d9Qm5L88wuWrPlmoD4mK1WPJMybXzuqdSCFSDPu7kYhT5gcu2aphuBldALEd/9tGb/zqzzUJgXLmueAvbpvy3VpKHIfoJUvKMORz7RWZsX5TaRkVFyHth50x/YHE75avW+uIqRakG4ZCh4nIoakUQP7x3LONhPQxj9k73AvbAYtywDylhwu2hXDnI4HSxzwb6qu5nBes1rKI/eEnp1XM+sibs84L0EbQnDTcDisxnQYBSZu0Jou3vlNsaTa0OskVP/CmOx+zrV3hW+Jjpmhzor6SXi+CV0A2MEQz2M+wRg/S1onYhDAnmLzyYbD2tT2mznwt+AvHHiI+xcDfEjKN1gDLeF2cf1AhBKXc0dbFRuV5+a8xWGDG1FDRrpf8ilCS500OIX4R3+piCObskbYOHst1uV9spagw8OBO5i82RDTzZNToLfH2jccppKmFgRx6uHzmn3n+sVp9/l6NQECzhFEwnQZCFTkv5aMlNBf4bZfDBvANm/L6SQJfB/hKLlod9NOKDq2qlN5z1yO1L31SCk1dq0UFFKKy6Or/446jr2ChdWtKWlbfVea/RVhIPWl IHKf+6bx Rf3syonqfTqD/OqJqCipat8gyspiWbeFA77RegTUf8ZPdZT4BPGZ61jDFHsTJEMWv45K86BapgZEnM77VfGw9n0i2b6UA7mvAnuUIKQx8DYQIsYhXTxfO+L8n5w== 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 Sat, Jan 14, 2023 at 03:18:32PM +0800, Hillf Danton wrote: > 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); At this time, lockdep add dependency A -> B in the dependency graph. > b) lock_map_acquire_read(&B->dep_map); > __lock_release(&B->dep_map); > c) lock_map_acquire_read(&B->dep_map); > mutex_lock(A); and here, lockdep will try to add dependency B -> A into the dependency graph, and find that A -> B -> A will form a circle (with strong dependency), therefore lockdep knows it's a deadlock. > > No deadlock could be detected if taskY takes mutexA after taskX releases B, The timing that taskX releases B doesn't master, since lockdep uses graph to detect deadlocks rather than after-fact detection. > 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. I have test cases showing the above deadlock can be detected, so if you think there is a deadlock that may dodge from my change, feel free to add a test case in lib/locking-selftest.c ;-) Regards, Boqun