On Thu, Nov 12, 2020 at 03:15:32PM +0900, Byungchul Park wrote: > > If on the other hand there's some bug in lockdep itself that causes > > excessive false positives, it's better to limit the number of reports > > to one per bootup, so that it's not seen as a nuisance debugging > > facility. > > > > Or if lockdep gets extended that causes multiple previously unreported > > (but very much real) bugs to be reported, it's *still* better to > > handle them one by one: because lockdep doesn't know whether it's real > > Why do you think we cannot handle them one by one with multi-reporting? > We can handle them with the first one as we do with single-reporting. > And also that's how we work, for example, when building the kernel or > somethinig.
Let me add a little bit more. I just said the fact that we are able to handle the bugs one by one as if we do with single-reporting. But the thing is multi-reporting could be more useful in some cases. More precisely speaking, bugs not caused by IRQ state will be reported without annoying nuisance. I bet you have experienced a ton of nuisances when multi-reporting Lockdep detected a deadlock by IRQ state. For some cases, multi-reporting is as useful as single-reporting, while for the other cases, multi-reporting is more useful. Then I think we have to go with mutil-reporting if there's no technical issue. Thanks, Byungchul
