[lkml]   [2008]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <> wrote:
>>> commit 0e3638d1e04040121af00195f7e4628078246489
>>> Author: Dave Hansen <>
>>> 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
> if (!slab_is_available())
> return;

Well, of course, it's also possible that the e820 code shouldn't be
initializing kobjects this early in the first place.

firmware_map_add_early() is using bootmem for the allocation. So yes,
I guess it should possible to use kobjects here. That said, this code
is in fact fairly recent:

commit 69ac9cd629ca96e59f34eb4ccd12d00b2c8276a7
Author: Bernhard Walle <>
Date: Fri Jun 27 13:12:54 2008 +0200

sysfs: add /sys/firmware/memmap

I'll add the Cc. I still have a feeling that the kobject patch should
expect to run even when slab is not available.


"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

 \ /
  Last update: 2008-07-20 00:47    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean