Linus wrote: > > On Wed, May 4, 2022 at 1:19 AM Byungchul Park <byungchul.park@xxxxxxx> wrote: > > > > 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. > > So what is the actual status of reports these days? > > Last time I looked at some reports, it gave a lot of false positives > due to mis-understanding prepare_to_sleep(). Yes, it was. I handled the case in the following way: 1. Stage the wait at prepare_to_sleep(), which might be used at commit. Which has yet to be an actual wait that Dept considers. 2. If the condition for sleep is true, the wait will be committed at __schedule(). The wait becomes an actual one that Dept considers. 3. If the condition is false and the task gets back to TASK_RUNNING, clean(=reset) the staged wait. That way, Dept only works with what actually hits to __schedule() for the waits through sleep. > For this all to make sense, it would need to not have false positives > (or at least a very small number of them together with a way to sanely Yes. I agree with you. I got rid of them that way I described above. > get rid of them), and also have a track record of finding things that > lockdep doesn't. I have some reports that wait_for_completion or waitqueue is involved. It's worth noting those are not tracked by Lockdep. I'm checking if those are true positive or not. I will share those reports once I get more convinced for that. > Maybe such reports have been sent out with the current situation, and > I haven't seen them. Dept reports usually have been sent to me privately, not in LKML. As I told you, I'm planning to share them. Byungchul > > Linus >
