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 8BFE4C3DA78 for ; Sat, 14 Jan 2023 10:27:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C51978E0002; Sat, 14 Jan 2023 05:27:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C01568E0001; Sat, 14 Jan 2023 05:27:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF15C8E0002; Sat, 14 Jan 2023 05:27:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A12778E0001 for ; Sat, 14 Jan 2023 05:27:25 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 66C131C5BE1 for ; Sat, 14 Jan 2023 10:27:25 +0000 (UTC) X-FDA: 80353027650.10.AE0CFCF Received: from r3-21.sinamail.sina.com.cn (r3-21.sinamail.sina.com.cn [202.108.3.21]) by imf14.hostedemail.com (Postfix) with ESMTP id 409C210000F for ; Sat, 14 Jan 2023 10:27:16 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.21 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=1673692044; 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=8rReITtwrJ+jRRGJhGf8vLAcdG+FyPKphRyN8mVl760=; b=rw6wangdKFVesZWXPaYVXwemZc7LzZssm1+N696DX3DsD2IM4qyDvtRBw4fRL6sWSXSEAB 1pcJLaj510oqDWIvRs2UIwZtE53yVfjsVA4E7UQCnHEO1grE3Yfg9WQrK3i+bYmFTFaNyu pQpNWoQU9D8V6J+7C5pzdsNXcow4CDc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.21 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673692044; a=rsa-sha256; cv=none; b=CsTiKW+6P8tRIuM0zlJmssnEjwgVnuM2ukcIYaHsR7LLn6QfRBGzIGM8u88RtsDoalrfal LUZmlfLbFZQvfd5t0Zjmgx//Hq77FfN7lcMlQjji4CBaLasxo1WPzL2KOhL8IS5jidbL6E Ub9lWlrH0Zy+KQNJiyZ3GNqr3qRc5D8= Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.32) with ESMTP id 63C2829E0001C641; Sat, 14 Jan 2023 18:23:28 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 404933629136 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 18:26:59 +0800 Message-Id: <20230114102659.1219-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> <20230114071832.1162-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: s61b5ft1rnn4878wzqmksyp36dn5t3go X-Rspamd-Queue-Id: 409C210000F X-HE-Tag: 1673692036-358741 X-HE-Meta: U2FsdGVkX18YxFFgAHEI9QyZBdjtl8FMVSJKpg1gYcna/ufKoqpVEuN3iGgrWK0czIRPy7Imb6qntOtxWteEKJ4e74r4clQoJa/PCS8JHCgxRPGYDbOmhUqbk6e2EjpRKepFN9wQ3i6CzeuTHcSWX50DwpWrrabiG/0169hgxz2EFHrqQYLY1smsZZKVhcqHcuOPOnFYyAzm9qSe3IgqrTWtodUz5xKNvgbvK0dPSwpA1GakZLRAuhoffkpCSunMO+TeKt41i7z/8C5e7i7LEDGpDjY2o/UVOnYeeMHmryLm1vShqo1iK5euR3Mu9ELMzWr2hu2PBKUcezrIBgkMkLVK9Qi0nfbBdCCnifkc+sJ0DT6xk1v8JlVkV99rfKF61//Icx7+fcYESmpUNapNCAyrgdQxfeH5NdEsH6OQYZYGob7e+6tnGDfJqVHAhP7triEam04gO+Gp6+lJTi5TciMrRVBpr1QucOYji5zLN5Q6tH8lB8j97NcQOnSyACXFe+e0lgT9Po+5Ab3G6Httwk0Ckn+tvVqavAdLHVrNrHtEOHMfCDhdqQkywdMio4hn8kb4jgU6PKrpoLNDpj/1VX/LV0iqhWJnfth8SMCPQcZDoO2TjUxPonqH9Cf08J9KI5Kr/TlRcuJVaR7RGtFn8AGQyOxZrWcnUn4WkZYBJRcwsnYJP2DQQJCWS6pkV51e/YYkJ7LmlcgFVw/AhDOTW0RssKLYLFb4vQMv7YyBlZfAu4s1bCYU154Bd+ZJVxEZB/OD5jaTgp/BnOmM+rP9iDOOLu2FlfN5+hUgb82ev7HK9m+0PlYt9QrmwcI3qxCA9mqGb97Pz4yJkQfLmRMj8BBB3JzbddmnEq3GNChSzhwmYP2qbL6nzw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, 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 23:32:01 -0800 Boqun Feng > On Sat, Jan 14, 2023 at 03:18:32PM +0800, Hillf Danton wrote: > > > > 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. Is the strong dependency applying to mode c)? If yes then deadlock should be also detected in the following locking pattern that has no deadlock. cpu0 cpu1 --- --- mutex_lock A mutex_lock B mutex_unlock B mutex_lock B mutex_lock A > > > > > 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