Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
From: Vegard Nossum
Date: Sat Jul 19 2008 - 18:27:39 EST
On Sun, Jul 20, 2008 at 12:17 AM, Greg KH <gregkh@xxxxxxx> wrote:
> On Sat, Jul 19, 2008 at 02:59:12PM +0200, Vegard Nossum wrote:
>> On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote:
>> > What I don't get here is how SLUB can be used this early in the boot
>> > process. Notice that this is still miles away from the
>> > SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> > line, which comes much later. And that kobject_init() _is_ calling
>> > kzalloc() via verify_dynamic_kobject_allocation(). Isn't this an
>> > error?
>> > (Unfortunately, my "git log" doesn't turn up any recent changes for
>> > any of the affected code paths here.)
>> Ehe... and this is the reason why: The code was added by this patch:
>> commit 0e3638d1e04040121af00195f7e4628078246489
>> Author: Dave Hansen <haveblue@xxxxxxxxxx>
>> Date: Thu Mar 16 17:30:16 2006 -0800
>> warn when statically-allocated kobjects are used
>> ..which only exists in -next. Is that just a truly ancient patch, or
>> did somebody forget to adjust their clock?
> It is truely a very old patch, that only lives in my tree, and currently
> isn't planned to go to Linus any year soon.
> But it has a very long history of living in the -mm tree, and finding
> real bugs, it's just not "safe" enough to go to Linus's tree. Unless
> you think it is?
Hm. In this case, the patch is not even reporting a problem, it is in
fact in error itself.
The problem is that it calls kzalloc() before the slab caches have
been set up. (Yes, it's a wonder that nothing crashed.) I can only
suggest the addendum
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/