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 1F9FBC433EF for ; Mon, 9 May 2022 01:23:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CDEC6B0071; Sun, 8 May 2022 21:23:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 47EE56B0073; Sun, 8 May 2022 21:23:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F8036B0074; Sun, 8 May 2022 21:23:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 197AA6B0071 for ; Sun, 8 May 2022 21:23:42 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DAAF3D1A for ; Mon, 9 May 2022 01:23:41 +0000 (UTC) X-FDA: 79444457442.10.E86AC03 Received: from lgeamrelo11.lge.com (lgeamrelo12.lge.com [156.147.23.52]) by imf06.hostedemail.com (Postfix) with ESMTP id D8CF3180004 for ; Mon, 9 May 2022 01:23:37 +0000 (UTC) Received: from unknown (HELO lgeamrelo04.lge.com) (156.147.1.127) by 156.147.23.52 with ESMTP; 9 May 2022 10:23:37 +0900 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO X58A-UD3R) (10.177.244.38) by 156.147.1.127 with ESMTP; 9 May 2022 10:23:37 +0900 X-Original-SENDERIP: 10.177.244.38 X-Original-MAILFROM: byungchul.park@lge.com Date: Mon, 9 May 2022 10:22:02 +0900 From: Byungchul Park To: Linus Torvalds Cc: Damien Le Moal , linux-ide@vger.kernel.org, Andreas Dilger , Ext4 Developers List , Ingo Molnar , Linux Kernel Mailing List , Peter Zijlstra , Will Deacon , Thomas Gleixner , Steven Rostedt , Joel Fernandes , Sasha Levin , Daniel Vetter , Chris Wilson , duyuyang@gmail.com, johannes.berg@intel.com, Tejun Heo , Theodore Ts'o , Matthew Wilcox , Dave Chinner , Amir Goldstein , "J. Bruce Fields" , Greg Kroah-Hartman , kernel-team@lge.com, Linux-MM , Andrew Morton , Michal Hocko , Minchan Kim , Johannes Weiner , Vladimir Davydov , sj@kernel.org, Jerome Glisse , Dennis Zhou , Christoph Lameter , Pekka Enberg , David Rientjes , Vlastimil Babka , ngupta@vflare.org, linux-block , paolo.valente@linaro.org, Josef Bacik , linux-fsdevel , Al Viro , Jan Kara , jack@suse.com, Jeff Layton , Dan Williams , Christoph Hellwig , "Darrick J. Wong" , dri-devel , Dave Airlie , rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com, 42.hyeyoo@gmail.com Subject: Re: [PATCH RFC v6 00/21] DEPT(Dependency Tracker) Message-ID: <20220509012202.GB6047@X58A-UD3R> References: <1651652269-15342-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: User-Agent: Mutt/1.5.21 (2010-09-15) Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of byungchul.park@lge.com designates 156.147.23.52 as permitted sender) smtp.mailfrom=byungchul.park@lge.com; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D8CF3180004 X-Stat-Signature: n35wrnpj5s16c1kustncnye6qonk76hw X-HE-Tag: 1652059417-227566 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 Wed, May 04, 2022 at 11:17:02AM -0700, Linus Torvalds wrote: > On Wed, May 4, 2022 at 1:19 AM Byungchul Park wrote: > > > > Hi Linus and folks, > > > > I've been developing a tool for detecting deadlock possibilities by > > tracking wait/event rather than lock(?) acquisition order to try to > > cover all synchonization machanisms. > > So what is the actual status of reports these days? I'd like to mention one important thing here. Reportability would get stronger if the more wait-event pairs get tagged everywhere DEPT can work. Everything e.g. HW-SW interface, any retry logic and so on can be a wait-event pair if they work wait or event anyway. For example, polling on an IO mapped read register and initiating the HW to go for the event also can be a pair. Definitely those make DEPT more useful. --- The way to use the APIs: 1. Define SDT(Simple Dependency Tracker) DEFINE_DEPT_SDT(my_hw_event); <- add this 2. Tag on the waits sdt_wait(&my_hw_event); <- add this ... retry logic until my hw work done ... <- the original code 3. Tag on the events sdt_event(&my_hw_event); <- add this run_my_hw(); <- the original code --- These are all we should do. I believe DEPT would be a very useful tool once all wait-event pairs get tagged by the developers in all subsystems and device drivers. Byungchul > Last time I looked at some reports, it gave a lot of false positives > due to mis-understanding prepare_to_sleep(). > > For this all to make sense, it would need to not have false positives > (or at least a very small number of them together with a way to sanely > get rid of them), and also have a track record of finding things that > lockdep doesn't. > > Maybe such reports have been sent out with the current situation, and > I haven't seen them. > > Linus