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 8EE93EB64D7 for ; Mon, 26 Jun 2023 13:02:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECC7F8D0002; Mon, 26 Jun 2023 09:02:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7C828D0001; Mon, 26 Jun 2023 09:02:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D44648D0002; Mon, 26 Jun 2023 09:02:46 -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 C326D8D0001 for ; Mon, 26 Jun 2023 09:02:46 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C2EEF1C74A8 for ; Mon, 26 Jun 2023 13:02:45 +0000 (UTC) X-FDA: 80944913490.11.9AD0420 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id BB90814015B for ; Mon, 26 Jun 2023 13:02:29 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=o53DZaDN; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf09.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687784549; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KtuBsjjrqdYqK8rnHik/NU+r+We2k+v37wwCwErCAlo=; b=jSgZoqiX4NanmQn9wqo3sy9UmqGvQBA/vClI2ygHaTXmnTbLVIruody0hGf+4sUUR8FbJw NBPApRufkXptSn8IpG808CtnThtJQmH/QzFGIAMMJBrka2pC8+fJSzee2eejomC9yveY6J WIItlNDkKle48u+ORJmKb8BTMMEUhyQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=o53DZaDN; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf09.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687784549; a=rsa-sha256; cv=none; b=FHPKcn0f26RPdQK20OGQXQDHUwXB9Tm4g0hP8VCdmj4wdP4B61hwqqKcJUKxXvP76N73T7 uuMntC0adY7dX1C3X6Wp7OnXmMzRlAGtDWZHSy496WHM2QWie+Ox4U2S0rLVXpQWJLJgA5 IidYijkA2/04KkLpGNFegkdB/5mW2/U= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1A2ED60EA2; Mon, 26 Jun 2023 13:02:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F9A6C433C0; Mon, 26 Jun 2023 13:02:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1687784546; bh=qHCByCNDys2ECT6mI9nx7oOPVqRAJqAf0TdsDuDj2PI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=o53DZaDNvEAwptnEewGQrTiUVPR6v8FwlmTYX7yfgHWj/oUbJGR0mhRH1GL39WX5g fp4oalcmiYuaNf5x8s65Ydy5ihYFrRckIWBUSM6GaHDjLwal1iUXFES1D/rhkOxDnz cdPK4n96JJlMF7nWtd+JoN35UgJzBHocXT3XWUCw= Date: Mon, 26 Jun 2023 15:02:22 +0200 From: Greg KH To: Byungchul Park Cc: linux-kernel@vger.kernel.org, kernel_team@skhynix.com, 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, 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, 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, boqun.feng@gmail.com, longman@redhat.com, hdanton@sina.com, her0gyugyu@gmail.com Subject: Re: [PATCH v10 00/25] DEPT(Dependency Tracker) Message-ID: <2023062627-chooser-douche-6613@gregkh> References: <20230626115700.13873-1-byungchul@sk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230626115700.13873-1-byungchul@sk.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: BB90814015B X-Stat-Signature: bxkep3ybytzmn43ea77pxhqdciqs6hti X-Rspam-User: X-HE-Tag: 1687784549-208545 X-HE-Meta: U2FsdGVkX1/INPpRYW17g/QhtVBOY+nCofxHFPyLaIBRO+F7XJkXO/en9xTGJ8WWKr8ag3slyxGysvQei/71xuTHaOfanICJE6S1xNmWKsEXky1F3ANLldxGeDGXA26k/rII1LUYNYWJ1vmB4svgCMuKTJGlQS+fkkhg4x/WXJegwd7pA1SZD2ruUwQZFXE/fJg/o8G98eIT8tCFi+Wgmm9PbWcxRqQ7+ENa5IuFHYflKVj8ZG3G/qAJXEJio4AUku188hOJBfyBxyC3Wq/cMUBxKYcVQUIU7XqZtRq8EMsjjohlKX5nd0IJmoqIHl/GSCIvCU4zbZ8RFYMZ26Fy4X9XQn1UideVYP05md2JU0grzoekofrCVfyFL68EQgqaFVmkhWFlVWu0lNav8ymORhLG1wIfqdr1ww6AX5IqNt4ZRFGptmHNIt0ZvtVcRQfBwlpAz2RgxI9AbTQaIVA69ynhayDT/o27cQwkNjwTB+zRBoyEKzdRaonT/a25vt9sPcC10R6B7FYtxwoWBVYyCDmrL4gfdm0SURbj0/yIqn9Y6Q+XnMu7/NYnMv1zrlT1G+qiYXuiZ58zdIzuKj5c7tYXtNsBYzT4/rjbZXercxXkUGgl2r4/d1IDBFVfl6UQ3xDwt4asU6zPe4iF2dYkWddrylKjxwG62ur3boTkPbFiNGOVexfAFFReIZ7nEjwvKIVkzPlCxTl5M6jU3ngkSNXvZViiauT976L/q4JmKSCBV7h1cJ0/Jk5FAsUP/j7ZUi2/fJqKzZV75Pbw3AigGVi//uIgrLXvcUyFsmrkdse8cOJvkAMBcqmjfm8LeWF0OSOSNosfdYKw6eIbfPcfg6tlgMOLgzk8wjx5doZRQzCPEgrR+kEF3sNqp0HPLzaSRvACGwHo6lca7cOi1enR3RINNhFpM0NoZ2hDKsCLey0i0fq0T2tYaXX8vEv+DDirnyLIDF3/NLndkLWEx2r V36j0oBT 2IQtSVntJqcR0KgLoQP4cXzM2c2boJhemwXpByQaXOjRvIw37fe/E+rKrt4mvpHcRpuaXmswQizvl2wchW5QI7XHo/CtqpRFcWWpfI5ivrivMcyebCw45chKmCJtqGgppjQPyQSHPkSH/rXyhycSOHHBbtF6aDdvoJf/EFnSCyN+XH9pFWv30MkPaiJcoL7BX3ND4NIlkbHAXz4WuJjskwqSozp9qeosXax1bbICHTCmG9cYmDSiLUP4DMi6+c2/ToUDfNqKJdFWffZt85Rri0aG2WNr77rHiLZApZPb32d6ld97tBLiUrH5aRKD2VVfI1P6f+TawXYFn2L4GAmw/itkr/EOPZPQlTu+BJcQp3QMshyLqFV3fVPAeibE8EsAEhWgfWG9keJFUn59yQsXZzAgwR6QWd3JbfRqXxsg4kViWTNJh1sry0aFW4/7YankIieGnjLyXtfBPCihROAYSiNUGYwqCBHWwt92f95EQQwc+iYoZNdc9vQB0dg== 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 Mon, Jun 26, 2023 at 08:56:35PM +0900, Byungchul Park wrote: > >From now on, I can work on LKML again! I'm wondering if DEPT has been > helping kernel debugging well even though it's a form of patches yet. > > I'm happy to see that DEPT reports a real problem in practice. See: > > https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp/#t > https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/ > > Nevertheless, I apologize for the lack of document. I promise to add it > before it gets needed to use DEPT's APIs by users. For now, you can use > DEPT just with CONFIG_DEPT on. > > --- > > 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. It's done on v6.2-rc2. > > Benifit: > > 0. Works with all lock primitives. > 1. Works with wait_for_completion()/complete(). > 2. Works with 'wait' on PG_locked. > 3. Works with 'wait' on PG_writeback. > 4. Works with swait/wakeup. > 5. Works with waitqueue. > 6. Works with wait_bit. > 7. Multiple reports are allowed. > 8. Deduplication control on multiple reports. > 9. Withstand false positives thanks to 6. > 10. Easy to tag any wait/event. > > Future work: > > 0. To make it more stable. > 1. To separates Dept from Lockdep. > 2. To improves performance in terms of time and space. > 3. To use Dept as a dependency engine for Lockdep. > 4. To add any missing tags of wait/event in the kernel. > 5. To deduplicate stack trace. If you run this today, does it find any issues with any subsystems / drivers that the current lockdep code does not find? Have you run your tool on patches sent to the different mailing lists for new drivers and code added to the tree to verify that it can find issues easily? In other words, why do we need this at all? What makes it 'better' than what we already have that works for us today? What benifit is it? thanks, greg k-h