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 B4BC9C433F5 for ; Tue, 22 Feb 2022 08:27:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEE628D0002; Tue, 22 Feb 2022 03:27:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D9E338D0001; Tue, 22 Feb 2022 03:27:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C66628D0002; Tue, 22 Feb 2022 03:27:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B88C98D0001 for ; Tue, 22 Feb 2022 03:27:31 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 74F8C181C9B88 for ; Tue, 22 Feb 2022 08:27:31 +0000 (UTC) X-FDA: 79169736702.21.48CE735 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf18.hostedemail.com (Postfix) with ESMTP id 78B4F1C0003 for ; Tue, 22 Feb 2022 08:27:30 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 1DA4C1F397; Tue, 22 Feb 2022 08:27:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1645518449; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dKa9YzG6WdPDW42WrXRDZOX/ZgG302zZsU6kzGjfuRk=; b=lVNqHC/SJXtfdUU1TvgLIEMqWyPvy2fp+HyHbXYbPfHfuZZMbbELQMO/hilxMxCbea4DxJ ugoy4UpC8tOrcLzxuNBmP5ZyZykkOuY+1PiwA4us8FNWR3k/lRPfP7OFBgxmPwowJFwI/K tx9BFWn1Go6d0U3AAkc8c0Ayhbp9HNI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1645518449; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dKa9YzG6WdPDW42WrXRDZOX/ZgG302zZsU6kzGjfuRk=; b=OZiJ8XOK9jUItoV3AtwtQa1Drdy4scvKJ56k+qcYOdL1CygSJh+86zCmsqu2snN9Ldfuz4 to3GnATifyxgYVAw== Received: from quack3.suse.cz (unknown [10.100.200.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id E227CA3B89; Tue, 22 Feb 2022 08:27:23 +0000 (UTC) Received: by quack3.suse.cz (Postfix, from userid 1000) id 9F9B5A0606; Tue, 22 Feb 2022 09:27:23 +0100 (CET) Date: Tue, 22 Feb 2022 09:27:23 +0100 From: Jan Kara To: Byungchul Park Cc: torvalds@linux-foundation.org, damien.lemoal@opensource.wdc.com, linux-ide@vger.kernel.org, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, peterz@infradead.org, will@kernel.org, tglx@linutronix.de, rostedt@goodmis.org, joel@joelfernandes.org, sashal@kernel.org, daniel.vetter@ffwll.ch, chris@chris-wilson.co.uk, duyuyang@gmail.com, johannes.berg@intel.com, tj@kernel.org, tytso@mit.edu, willy@infradead.org, david@fromorbit.com, amir73il@gmail.com, bfields@fieldses.org, gregkh@linuxfoundation.org, kernel-team@lge.com, linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@kernel.org, minchan@kernel.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com, sj@kernel.org, jglisse@redhat.com, dennis@kernel.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, vbabka@suse.cz, ngupta@vflare.org, linux-block@vger.kernel.org, axboe@kernel.dk, paolo.valente@linaro.org, josef@toxicpanda.com, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz, jack@suse.com, jlayton@kernel.org, dan.j.williams@intel.com, hch@infradead.org, djwong@kernel.org, dri-devel@lists.freedesktop.org, airlied@linux.ie, rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com Subject: Re: Report 1 in ext4 and journal based on v5.17-rc1 Message-ID: <20220222082723.rddf4typah3wegrc@quack3.lan> References: <1645095472-26530-1-git-send-email-byungchul.park@lge.com> <1645096204-31670-1-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1645096204-31670-1-git-send-email-byungchul.park@lge.com> X-Rspamd-Queue-Id: 78B4F1C0003 X-Stat-Signature: 1ghpbpwetbniszmshopxgrzewpsyoc4n Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="lVNqHC/S"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=OZiJ8XOK; dmarc=none; spf=pass (imf18.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1645518450-271547 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 Thu 17-02-22 20:10:03, Byungchul Park wrote: > [ 7.009608] =================================================== > [ 7.009613] DEPT: Circular dependency has been detected. > [ 7.009614] 5.17.0-rc1-00014-g8a599299c0cb-dirty #30 Tainted: G W > [ 7.009616] --------------------------------------------------- > [ 7.009617] summary > [ 7.009618] --------------------------------------------------- > [ 7.009618] *** DEADLOCK *** > [ 7.009618] > [ 7.009619] context A > [ 7.009619] [S] (unknown)(&(bit_wait_table + i)->dmap:0) > [ 7.009621] [W] down_write(&ei->i_data_sem:0) > [ 7.009623] [E] event(&(bit_wait_table + i)->dmap:0) > [ 7.009624] > [ 7.009625] context B > [ 7.009625] [S] down_read(&ei->i_data_sem:0) > [ 7.009626] [W] wait(&(bit_wait_table + i)->dmap:0) > [ 7.009627] [E] up_read(&ei->i_data_sem:0) > [ 7.009628] Looking into this I have noticed that Dept here tracks bitlocks (buffer locks in particular) but it apparently treats locks on all buffers as one locking class so it conflates lock on superblock buffer with a lock on extent tree block buffer. These are wastly different locks with different locking constraints. So to avoid false positives in filesystems we will need to add annotations to differentiate locks on different buffers (based on what the block is used for). Similarly how we e.g. annotate i_rwsem for different inodes. Honza -- Jan Kara SUSE Labs, CR