> > Is there some political reason that collaboration isn't happening? I've > found the syzbot people to be great to work with. > > I'll give some analysis on this bug, but in general I won't in the > future until you guys start collaborating (or at least tell us what the > blocker is) - I don't want to be duplicating work I've already done for > syzbot. Thanks, no political reasons, simply just researching this area and not familiar enough with it, I'll keep an eye out for this later. > > We need to know what the other threads are doing. Since lockdep didn't > detect an actual deadlock, it seems most likely that the blocked thread > is blocked because the thread holding the inode lock is spinning and > livelocked. > > That's not in the dump, so to debug this we'd need to reproduce this in > a local VM and poke around with e.g. top/perf and see what's going on. > > I've a tool to reproduce syzbot bugs locally in a single command [1], so > that would be my starting point - except it doesn't work with your > forked version. Doh. > > Another thing we could do is write some additional code for the hung > task detector that, when lockdep is enabled, uses it to figure out which > task it's blocked on and additionally print a backtrace for that. > > [1]: https://evilpiepirate.org/git/ktest.git/tree/tests/syzbot-repro.ktest > >> Ok, I'll try it with this tool. For now, we are experimenting based on the early November 2024 version (df3dc63), let's see if we can debug this tool of yours.
