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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 238EFC433FE for ; Mon, 9 May 2022 01:30:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233485AbiEIBdv (ORCPT ); Sun, 8 May 2022 21:33:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235274AbiEIBbm (ORCPT ); Sun, 8 May 2022 21:31:42 -0400 Received: from lgeamrelo11.lge.com (lgeamrelo12.lge.com [156.147.23.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BE4B013D33 for ; Sun, 8 May 2022 18:23:38 -0700 (PDT) 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) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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