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 D7F70C43217 for ; Thu, 17 Feb 2022 17:00:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 293156B0078; Thu, 17 Feb 2022 12:00:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 21B546B007B; Thu, 17 Feb 2022 12:00:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 095F06B007D; Thu, 17 Feb 2022 12:00:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id E6D296B0078 for ; Thu, 17 Feb 2022 12:00:14 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9A77C8249980 for ; Thu, 17 Feb 2022 17:00:14 +0000 (UTC) X-FDA: 79152884748.20.D0F6794 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 1876B20005 for ; Thu, 17 Feb 2022 17:00:13 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0F762615F2; Thu, 17 Feb 2022 17:00:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AA09C340E8; Thu, 17 Feb 2022 17:00:06 +0000 (UTC) Date: Thu, 17 Feb 2022 12:00:05 -0500 From: Steven Rostedt To: "Theodore Ts'o" Cc: Byungchul Park , 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, 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, 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: [PATCH 00/16] DEPT(Dependency Tracker) Message-ID: <20220217120005.67f5ddf4@gandalf.local.home> In-Reply-To: References: <1645095472-26530-1-git-send-email-byungchul.park@lge.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 1876B20005 X-Stat-Signature: g5xdyrg44sshpj8fcbsouwdq9aatstfi X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of "SRS0=CucC=TA=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=CucC=TA=goodmis.org=rostedt@kernel.org" X-HE-Tag: 1645117213-364133 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 Feb 2022 10:51:09 -0500 "Theodore Ts'o" wrote: > I know that you're trying to help us, but this tool needs to be far > better than Lockdep before we should think about merging it. Even if > it finds 5% more potential deadlocks, if it creates 95% more false > positive reports --- and the ones it finds are crazy things that > rarely actually happen in practice, are the costs worth the benefits? > And who is bearing the costs, and who is receiving the benefits? I personally believe that there's potential that this can be helpful and we will want to merge it. But, what I believe Ted is trying to say is, if you do not know if the report is a bug or not, please do not ask the maintainers to determine it for you. This is a good opportunity for you to look to see why your tool reported an issue, and learn that subsystem. Look at if this is really a bug or not, and investigate why. The likely/unlikely tracing I do finds issues all over the kernel. But before I report anything, I look at the subsystem and determine *why* it's reporting what it does. In some cases, it's just a config issue. Where, I may submit a patch saying "this is 100% wrong in X config, and we should just remove the "unlikely". But I did the due diligence to find out exactly what the issue is, and why the tooling reported what it reported. I want to stress that your Dept tooling looks to have the potential of being something that will be worth while including. But the false positives needs to be down to the rate of lockdep false positives. As Ted said, if it's reporting 95% false positives, nobody is going to look at the 5% of real bugs that it finds. -- Steve