On Thu, Feb 17, 2022 at 07:57:36PM +0900, Byungchul Park wrote: > > I've got several reports from the tool. Some of them look like false > alarms and some others look like real deadlock possibility. Because of > my unfamiliarity of the domain, it's hard to confirm if it's a real one. > Let me add the reports on this email thread. The problem is we have so many potentially invalid, or so-rare-as-to-be-not-worth-the-time-to-investigate-in-the- grand-scheme-of-all-of-the-fires-burning-on-maintainers laps that it's really not reasonable to ask maintainers to determine whether something is a false alarm or not. If I want more of these unreliable potential bug reports to investigate, there is a huge backlog in Syzkaller. :-) Looking at the second ext4 report, it doesn't make any sense. Context A is the kjournald thread. We don't do a commit until (a) the timeout expires, or (b) someone explicitly requests that a commit happen waking up j_wait_commit. I'm guessing that complaint here is that DEPT thinks nothing is explicitly requesting a wake up. But note that after 5 seconds (or whatever journal->j_commit_interval) is configured to be we *will* always start a commit. So ergo, there can't be a deadlock. At a higher level of discussion, it's an unfair tax on maintainer's times to ask maintainers to help you debug DEPT for you. Tools like Syzkaller and DEPT are useful insofar as they save us time in making our subsystems better. But until you can prove that it's not going to be a massive denial of service attack on maintainer's time, at the *very* least keep an RFC on the patch, or add massive warnings that more often than not DEPT is going to be sending maintainers on a wild goose chase. If you know there there "appear to be false positives", you need to make sure you've tracked them all down before trying to ask that this be merged. You may also want to add some documentation about why we should trust this; in particular for wait channels, when a process calls schedule() there may be multiple reasons why the thread will wake up --- in the worst case, such as in the select(2) or epoll(2) system call, there may be literally thousands of reasons (one for every file desriptor the select is waiting on) --- why the process will wake up and thus resolve the potential "deadlock" that DEPT is worrying about. How is DEPT going to handle those cases? If the answer is that things need to be tagged, then at least disclose potential reasons why DEPT might be untrustworthy to save your reviewers time. I know that you're trying to help us, but this tool needs to be far better than Lockdep before we should think about merging it. Even if it finds 5% more potential deadlocks, if it creates 95% more false positive reports --- and the ones it finds are crazy things that rarely actually happen in practice, are the costs worth the benefits? And who is bearing the costs, and who is receiving the benefits? Regards, - Ted
