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 AD77AC433FE for ; Sat, 7 May 2022 07:21:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A9D86B0074; Sat, 7 May 2022 03:21:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 232B06B0075; Sat, 7 May 2022 03:21:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AC9A6B0078; Sat, 7 May 2022 03:21:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EA7CD6B0074 for ; Sat, 7 May 2022 03:21:12 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B590F607B3 for ; Sat, 7 May 2022 07:21:12 +0000 (UTC) X-FDA: 79438100784.18.B1D2031 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf22.hostedemail.com (Postfix) with ESMTP id CC6DBC0007 for ; Sat, 7 May 2022 07:21:10 +0000 (UTC) Received: by mail-pf1-f170.google.com with SMTP id x52so8027982pfu.11 for ; Sat, 07 May 2022 00:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=rNQz935Rwo42XgI1l8Va40p/MEeV4p6HEVCQ52VDnf4=; b=P42+8ex/HBpVSeUhi79CcZsiB1rEwx7SjPsWOzHKtYtuDRjT+7g81hnQb9Bg+3nrwT De8dQlU9BcgwoEV9wdnbeE3D82XEoM9rdMizKhVMhmThyQPs7pG6yQdXOZHUILyVEB8B MZOMaM5Nag+I9ca+mSFwEkbaCfc+mVQpZN8W0UFxaI3P1zlBAo3OLxIQcU7yZiXAhU1h Jiaawf+dpE+KAoqOYTid6KwfvlqOs8L3T25b9+uILvT8+qC03iIX5R5P7pBVqRxRlV1/ 2L77a/eKzFW5m+4Q8qaNXGrcogU5pQhNHMvwFRhhaVI7cMNifBapsGydQXtopBhbDEvv tGKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rNQz935Rwo42XgI1l8Va40p/MEeV4p6HEVCQ52VDnf4=; b=nOiRgm+y9HYuJfi7N3YS7Dn7pqwD2V2CH6syl6HqtrNLkndHrwZ4FaIr57RQ+oZVPK OCqbnYct+PekhL0Uek15N3Jvn+FoshU3iSLB579GxwsM5llZopf6cFiGiu9iJERKsAvX nzEOjOOi1akK0PoaS0Uwtc2Jgrwq1ySKDhM8o8QAHZkE31NmKe16DIG7jRRmrejiwLIp 5ojDmUro2SkEFlsrTFSazHhvk3khNGItnK5skRnLrWiFeJW1gSSw3Io6UQcgklnK1SwE fihes1NbL8laKdNuYDmXrUa34M+1IZISl7BCfxivA+LFHijraiWDeVFnw5P/stnrABxF vl8w== X-Gm-Message-State: AOAM530CfdLIw84TbWfOt7WVpn2OsnWVUHbmxELhqS9jpYQdi0nEu0Hp tOOJB8lXxzhBxCIhUTzQz00= X-Google-Smtp-Source: ABdhPJy8wngBA9nCSkNphuykt/x5APcFu3ZWQNW14hKz2s7Rb0bLuKnbzsVQiG9xcQts5UZOdrCb6w== X-Received: by 2002:a65:6093:0:b0:373:9c75:19ec with SMTP id t19-20020a656093000000b003739c7519ecmr5972095pgu.539.1651908071104; Sat, 07 May 2022 00:21:11 -0700 (PDT) Received: from hyeyoo ([114.29.24.243]) by smtp.gmail.com with ESMTPSA id 1-20020a170902c20100b0015ec44d25dasm2956759pll.235.2022.05.07.00.20.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 May 2022 00:21:10 -0700 (PDT) Date: Sat, 7 May 2022 16:20:50 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> 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, 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, 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 RFC v6 00/21] DEPT(Dependency Tracker) Message-ID: References: <1651795895-8641-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: <1651795895-8641-1-git-send-email-byungchul.park@lge.com> X-Rspamd-Queue-Id: CC6DBC0007 X-Stat-Signature: ak3k1egee34xxr7e57zk6s66z1o1jeu5 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="P42+8ex/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1651908070-591104 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 Fri, May 06, 2022 at 09:11:35AM +0900, Byungchul Park wrote: > Linus 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? > > > > Last time I looked at some reports, it gave a lot of false positives > > due to mis-understanding prepare_to_sleep(). > > Yes, it was. I handled the case in the following way: > > 1. Stage the wait at prepare_to_sleep(), which might be used at commit. > Which has yet to be an actual wait that Dept considers. > 2. If the condition for sleep is true, the wait will be committed at > __schedule(). The wait becomes an actual one that Dept considers. > 3. If the condition is false and the task gets back to TASK_RUNNING, > clean(=reset) the staged wait. > > That way, Dept only works with what actually hits to __schedule() for > the waits through 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 > > Yes. I agree with you. I got rid of them that way I described above. > IMHO DEPT should not report what lockdep allows (Not talking about wait events). I mean lockdep allows some kind of nested locks but DEPT reports them. When I was collecting reports from DEPT on varous configurations, Most of them was report of down_write_nested(), which is allowed in lockdep. DEPT should not report at least what we know it's not a real deadlock. Otherwise there will be reports that is never fixed, which is quite unpleasant and reporters cannot examine all of them if it's real deadlock or not. > > get rid of them), and also have a track record of finding things that > > lockdep doesn't. > > I have some reports that wait_for_completion or waitqueue is involved. > It's worth noting those are not tracked by Lockdep. I'm checking if > those are true positive or not. I will share those reports once I get > more convinced for that. > > > Maybe such reports have been sent out with the current situation, and > > I haven't seen them. > > Dept reports usually have been sent to me privately, not in LKML. As I > told you, I'm planning to share them. > > Byungchul > > > > > Linus > > -- Thanks, Hyeonggon