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 E95A1C38159 for ; Thu, 19 Jan 2023 00:58:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FA206B0072; Wed, 18 Jan 2023 19:58:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AB556B0073; Wed, 18 Jan 2023 19:58:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44B436B0074; Wed, 18 Jan 2023 19:58:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 354B66B0072 for ; Wed, 18 Jan 2023 19:58:45 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0827B1401B5 for ; Thu, 19 Jan 2023 00:58:45 +0000 (UTC) X-FDA: 80369738610.03.FF00448 Received: from lgeamrelo11.lge.com (lgeamrelo13.lge.com [156.147.23.53]) by imf10.hostedemail.com (Postfix) with ESMTP id 633F6C000B for ; Thu, 19 Jan 2023 00:58:42 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of byungchul.park@lge.com designates 156.147.23.53 as permitted sender) smtp.mailfrom=byungchul.park@lge.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674089923; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=6jmoryj2QPeEE+0PqCMgS2kcLyZ7tosXA2qdKW8YMDg=; b=1E6C2P7yhBpPGvtwWHkDpvsYdpQlkvX5rhnbDCOdesbNGKZHPe2vuvtXjckfAtlqVevmVf RFNSes09VyzpWLVB0Iw7fcIvwg4WeK2SQGZQ8XQlJRMGHrwcPldf/TKUAoXdLKJtgKCVwE HKHG90GSHno7xwdXb+uCcWFjbSZb/dU= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of byungchul.park@lge.com designates 156.147.23.53 as permitted sender) smtp.mailfrom=byungchul.park@lge.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674089923; a=rsa-sha256; cv=none; b=rbSM+6huTneZd9ixi04DZ/zIL27QuKn8FJkm6Fv6r2PMIQ1afZcKwTufA5N4Sb7JOjSbpa CYonB1kKYqi5tYdQIyD/Ti7Lw7WSwyG15eqO6kvszclPUB8SRHU0QXQAxJ4p2B7QCLqvax lESI2AMN5hDht5e2OyuPdWbUD4nHs1U= Received: from unknown (HELO lgemrelse7q.lge.com) (156.147.1.151) by 156.147.23.53 with ESMTP; 19 Jan 2023 09:58:39 +0900 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO localhost.localdomain) (10.177.244.38) by 156.147.1.151 with ESMTP; 19 Jan 2023 09:58:39 +0900 X-Original-SENDERIP: 10.177.244.38 X-Original-MAILFROM: byungchul.park@lge.com From: Byungchul Park To: torvalds@linux-foundation.org Cc: 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, 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, jlayton@kernel.org, dan.j.williams@intel.com, hch@infradead.org, djwong@kernel.org, dri-devel@lists.freedesktop.org, rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com, 42.hyeyoo@gmail.com, chris.p.wilson@intel.com, gwan-gyeong.mun@intel.com, max.byungchul.park@gmail.com Subject: Re: [PATCH RFC v7 00/23] DEPT(Dependency Tracker) Date: Thu, 19 Jan 2023 09:58:27 +0900 Message-Id: <1674089907-31690-1-git-send-email-byungchul.park@lge.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: References: X-Rspamd-Queue-Id: 633F6C000B X-Stat-Signature: hed7c1s3w1ietmpxoh5ptgiaqndua5ow X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1674089922-850684 X-HE-Meta: U2FsdGVkX18NgsokvFP8/Y5siYYFi1rjwOe3Lz36i+DM2V1BWeRoWSpe0duW4mLb8/d7X9Rvj9HlZJ89ExLEKlc+vgWzP8bM5MDcD/P5rKCioxNyluOVCCfRWe9oOWcywwOxkfYF7KDP5H1YGV41QYsfhmrgAUsRiq0RTThWV9E45LBQEfgmn3Y1joOSS4Ru+Y33ZrEnrl4MXIr6aeBtEDk08NiQtz0GjC56wxq+NYswtg7LdHuPvRvFFUdJY/rsGZFV+ANgNK5/cwiLC9ly5aH10OnYnRmIhyj354AmXp4MFRQIkBPhEw4J5/bau9v9BXOwUWe2I2ETrHukngbmW7AyZCK7FvOCgoEZ4ad0DBa65NoIBd8bFEhoKyazlAboZlswG7EGZnwmrUg+wWPiG2spqjZ2bANetFyBTAGUTytyBP7MaFpg8/OTbT0XUXR4ulK5Df0jhX4Vi+NHYUlwRq662EW3tv1i04Y79sw+deXHl6ulxzvMp2+IlMA4Qq7nOV55WMnJ3l7wnfkS8ILCBxZpuiqkvCQXTuGqZjTBcmrlSFNe5XA1XKFAp2rklxF5MmwN0SHn3QgSfqrdtD8bEZwzN/VJZ0RQD9TrJmrUmW1yInvQahKX7xhSbCbUAcPK8w8Zu8fwOLmlTlPfg25JgUgPHyHFW2zpeTU6+fCOfAN41gBF8J4ekwLZuSKjV3u4U0v1nicitBZqGHlyLRQ0VvreUOqvVqdPstWU20di0eKQ7KQQvii3JRSVcDSH2TuSjdpv3xt29Y2qDirOZstV16bELywOEAZmk5TPaInCDkb47kBjaPlNFK7g8RV8hhvWVKeLZ1nOVQI= 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: Torvalds wrote: > On Sun, Jan 8, 2023 at 7:33 PM Byungchul Park wrote: >> >> 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. It's done on v6.2-rc2. > > Ugh. I hate how this adds random patterns like I undertand what you mean.. But all the synchronization primitives should let DEPT know the beginning and the end of each. However, I will remove the 'if' statement that looks ugly from the next spin, and place the pattern to a better place if possible. > if (timeout == MAX_SCHEDULE_TIMEOUT) > sdt_might_sleep_strong(NULL); > else > sdt_might_sleep_strong_timeout(NULL); > ... > sdt_might_sleep_finish(); > > to various places, it seems so very odd and unmaintainable. > > I also recall this giving a fair amount of false positives, are they all fixed? Yes. Of course I removed all the false positives we found. > Anyway, I'd really like the lockdep people to comment and be involved. > We did have a fairly recent case of "lockdep doesn't track page lock > dependencies because it fundamentally cannot" issue, so DEPT might fix > those kinds of missing dependency analysis. See Sure. That's exactly what DEPT works for e.g. PG_locked. > https://lore.kernel.org/lkml/00000000000060d41f05f139aa44@google.com/ I will reproduce it and share the result. > for some context to that one, but at teh same time I would *really* > want the lockdep people more involved and acking this work. > > Maybe I missed the email where you reported on things DEPT has found > (and on the lack of false positives)? Maybe you didn't miss. It's still too hard to make a decision between: Aggressive detection with false alarms that need to be fixed by manual classification as Lockdep did, focusing on potential possibility more. versus Conservative detection with few false alarms, which requires us to test much longer to get result we expect, focusing on actual happening. > > Linus Byungchul