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@xxxxxxxxxxxxxxxxxxx/#t > https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@xxxxxxx/ > > 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
