[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201123110527.GB9464@X58A-UD3R>
Date: Mon, 23 Nov 2020 20:05:27 +0900
From: Byungchul Park <byungchul.park@....com>
To: torvalds@...ux-foundation.org, peterz@...radead.org,
mingo@...hat.com, will@...nel.org
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de,
rostedt@...dmis.org, joel@...lfernandes.org,
alexander.levin@...rosoft.com, daniel.vetter@...ll.ch,
chris@...is-wilson.co.uk, duyuyang@...il.com,
johannes.berg@...el.com, tj@...nel.org, tytso@....edu,
willy@...radead.org, david@...morbit.com, amir73il@...il.com,
bfields@...ldses.org, gregkh@...uxfoundation.org,
kernel-team@....com
Subject: [RFC] Dept(Dependency Tracker) Implementation
Hi,
This patchset is too nasty to get reviewed in detail for now.
This have:
1. applying Dept to spinlock/mutex/rwlock/completion
2. assigning custom keys or disable maps to avoid false positives
This doesn't have yet (but will be done):
1. proc interfaces e.g. to see dependecies the tool has built,
2. applying Dept to rw semaphore and the like,
3. applying Dept to lock_page()/unlock_page(),
4. assigning custom keys to more places properly,
5. replace all manual Lockdep annotations,
(and so on..)
But I decided to share it to let others able to test how it works and
someone who wants to see the detail able to check the code. The most
important thing I'd like to show is what exactly a deadlock detection
tool should do.
Turn on CONFIG_DEPT to test it. Feel free to leave any questions if you
have.
Thanks,
Byungchul
Powered by blists - more mailing lists