On Sun, 27 May 2007 11:56:21 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > > > So section mismatch warnings are more about catching sloopy usage of __init > > than it is to > > catch potential kernel oopesen. But the latter is a nice side effect that > > is appreciated. > > My point was that I cannot recall a single real oops bug found by the compile > time checking. There are quite a few of these fixes where you look at it and wonder "ytf did the kernel ever work"? I suspect that it's partly a case of the code reading random junk from where a flag used to be and continuing to work. CONFIG_DEBUG_PAGEALLOC would have caught it. Also, simply lack of testing coverage: few people have the correct hardware, the correct config options and then go and do an rmmod+insmod. Even fewer do a CPU hotplug. Fewer still do a memory hotplug. But there are a lot of fixes, and a lot of warnings, and they are real bugs. > We had a few in the past, but since we poison init data after boot they all > tended > to be found quickly anyways. Sometimes. But a common pattern is "discover something at boot time and save it away for later boot-time code". The storage gets marked __fooinit and then it turns out that some non-boot-time initialisation code is using it. > But the warnings just seem to require endless changes and bogus changes > (randomly moving code which was actually ok because it only called > in the init case). That would be a false positive. We do need the various tools to suppress those so that we can find new bugs as they turn up. You're right that it's all a complete pain. But the fault doesn't lie with the checking code, IMO. It's just that the whole initdata thing is hard to get right. All this fuss for a couple hundred kbytes - any sane organisation would have killed the whole thing years ago ;) It'll really get to be fun when some smarty writes us a "non __init symbol referred to only from __init code" checker. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/