On Wednesday, 8 of October 2008, Ingo Molnar wrote: > > * Rafael J. Wysocki <rjw@xxxxxxx> wrote: > > > On Wednesday, 8 of October 2008, David Miller wrote: > > > From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> > > > Date: Tue, 7 Oct 2008 23:58:33 +0100 > > > > > > > > This should have been fixed by: > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f5a6d958b5d0a10e7e7a9dee1862fb31d08c6d26 > > > > > > > > You mean - hidden by - that change should IMHO be reverted > > > > > > Grrr... I totally agree. > > > > Even though they are false positives in many cases? > > > > (Yes, they are). > > it's your judgement call i guess - i just wanted to challenge the > terminology of calling it a fix ;-) Well, since I added the WARN_ON() and then reallized it did more harm than good, I consider it as a fix. :-) > Can you think of any good way of reintroducing the good aspect of the > WARN(), without the false positives? [ If not, and if the WARN()s do > more harm than good then it's the right change. ] Unfortunately not. In particular, the MMC subsystem is known to trigger this WARN_ON() which in turn is not related to any functional problem (it's a design issue in this case) and it's not going to be fixed any time soon IMO. USB used to trigger it too, but that has been fixed already. > But generally the trend is the opposite direction: we try to add as many > WARN()s as possible, and we need even more good WARN()s in the kernel. > When we meet false positives we try to improve the quality/yield of the > warning, not eliminate it. > > Granted, they are a bit embarrassing when they show up in the top 10 but > they are also very helpful and are tracked very nicely and lead to > actual bugfixes that _matter_. > > Kerneloops.org is a wonderful tool: it enables a broad spectrum of users > to help us out with their feedback, without them being forced into any > manual work, and without them having to understand the kernel bug > reporting workflow. Its scale is already enormous: 3000+ bugs reported > per week. (many kudos Arjan!) > > Once its growth stabilizes (all the large distros have it either enabled > today or have the client in their pipeline) we can even observe > long-term trends and estimate release-to-release suckiness. That was > impossible before and maintainers were left largely to imprecise > intuitive guesses about where we stand wrt. kernel quality. While I agree with all that, I also think that it's not really reasonable to use WARNs causing people to waste their time for reporting issues that actually don't need to be reported. IMO it will make sense to add this WARN_ON() back again in future, but not at the moment. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
