From: Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org>
To: Vegard Nossum <vegard.nossum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mariusz Kozlowski
<m.kozlowski-NWF1p15JEu3VItvQsEIGlw@public.gmane.org>,
Dave Hansen <haveblue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>,
kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org>,
Bernhard Walle <bwalle-l3A5Bk7waGM@public.gmane.org>
Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
Date: Sat, 19 Jul 2008 15:58:17 -0700 [thread overview]
Message-ID: <20080719225817.GA6264@suse.de> (raw)
In-Reply-To: <19f34abd0807191544nfd73be5nf7dde4b61992a7e8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Jul 20, 2008 at 12:44:38AM +0200, Vegard Nossum wrote:
> On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <vegard.nossum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> commit 0e3638d1e04040121af00195f7e4628078246489
> >>> Author: Dave Hansen <haveblue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> >>> 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.
That's probably the case, the kobject code isn't able to handle this
kind of thing (sysfs included).
> 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 <bwalle-l3A5Bk7waGM@public.gmane.org>
> 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.
I never has been expected to do so in the past, so odds are, lots of
things might break :(
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@suse.de>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Mariusz Kozlowski <m.kozlowski@tuxland.pl>,
Dave Hansen <haveblue@us.ibm.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
kernel-testers@vger.kernel.org, linux-next@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Bernhard Walle <bwalle@suse.de>
Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
Date: Sat, 19 Jul 2008 15:58:17 -0700 [thread overview]
Message-ID: <20080719225817.GA6264@suse.de> (raw)
In-Reply-To: <19f34abd0807191544nfd73be5nf7dde4b61992a7e8@mail.gmail.com>
On Sun, Jul 20, 2008 at 12:44:38AM +0200, Vegard Nossum wrote:
> On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
> >>> commit 0e3638d1e04040121af00195f7e4628078246489
> >>> Author: Dave Hansen <haveblue@us.ibm.com>
> >>> 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.
That's probably the case, the kobject code isn't able to handle this
kind of thing (sysfs included).
> 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 <bwalle@suse.de>
> 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.
I never has been expected to do so in the past, so odds are, lots of
things might break :(
thanks,
greg k-h
next prev parent reply other threads:[~2008-07-19 22:58 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-18 9:53 linux-next: Tree for July 18 Stephen Rothwell
2008-07-19 7:28 ` linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller Mariusz Kozlowski
2008-07-19 9:55 ` Vegard Nossum
[not found] ` <19f34abd0807190255x304173d4wf2bfabb2d5bce511-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 12:56 ` Pekka Enberg
2008-07-19 12:56 ` Pekka Enberg
2008-07-19 12:59 ` Vegard Nossum
[not found] ` <19f34abd0807190559y2fe5ebf9h7095793e82de3122-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 13:22 ` Stephen Rothwell
2008-07-19 13:22 ` Stephen Rothwell
2008-07-19 22:17 ` Greg KH
2008-07-19 22:17 ` Greg KH
2008-07-19 22:27 ` Vegard Nossum
[not found] ` <19f34abd0807191527u61c5ed61kffe2279c8d46915d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 22:41 ` Greg KH
2008-07-19 22:41 ` Greg KH
2008-07-19 22:44 ` Vegard Nossum
[not found] ` <19f34abd0807191544nfd73be5nf7dde4b61992a7e8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 22:58 ` Greg KH [this message]
2008-07-19 22:58 ` Greg KH
2008-07-19 23:11 ` Vegard Nossum
[not found] ` <19f34abd0807191611y7cabf405iad307ba79591e04f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 23:20 ` Greg KH
2008-07-19 23:20 ` Greg KH
2008-07-20 12:51 ` Bernhard Walle
2008-07-20 9:01 ` Dave Hansen
2008-07-20 9:01 ` Dave Hansen
2008-07-20 9:01 ` Dave Hansen
2008-07-20 9:35 ` Thomas Meyer
2008-07-20 9:35 ` Thomas Meyer
2008-07-20 9:35 ` Thomas Meyer
2008-07-20 13:03 ` Bernhard Walle
2008-07-20 13:03 ` Bernhard Walle
[not found] ` <20080720150341.7cd381c2-Hxm9IJOWyO+kWa+peg0mPg@public.gmane.org>
2008-07-20 15:44 ` Bernhard Walle
2008-07-20 15:44 ` Bernhard Walle
2008-07-20 15:44 ` Bernhard Walle
2008-07-21 13:17 ` Vivek Goyal
2008-07-21 13:17 ` Vivek Goyal
2008-07-21 13:17 ` Vivek Goyal
[not found] ` <20080721131721.GB4451-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-07-21 13:25 ` Bernhard Walle
2008-07-21 13:25 ` Bernhard Walle
2008-07-21 13:25 ` Bernhard Walle
2008-07-21 13:39 ` Vivek Goyal
2008-07-21 13:39 ` Vivek Goyal
2008-07-21 13:47 ` Bernhard Walle
2008-07-21 14:54 ` Vivek Goyal
2008-07-21 15:00 ` Bernhard Walle
[not found] ` <20080721133937.GC4451-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-07-21 15:00 ` Bernhard Walle
2008-07-21 15:00 ` Bernhard Walle
2008-07-21 15:00 ` Bernhard Walle
[not found] ` <20080721170037.1a0046b1-oJhqVyG5NZ9bpigZmTR7Iw@public.gmane.org>
2008-07-22 6:15 ` Yasunori Goto
2008-07-22 6:15 ` Yasunori Goto
2008-07-22 6:15 ` Yasunori Goto
2008-07-20 12:48 ` Bernhard Walle
2008-07-20 12:48 ` Bernhard Walle
[not found] ` <20080718195352.e562a00f.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
2008-07-19 7:39 ` linux-next: Tree for July 18: nfs problems Mariusz Kozlowski
2008-07-19 7:39 ` Mariusz Kozlowski
2008-07-19 9:35 ` linux-next: Tree for July 18: powerpc g3 hangs Mariusz Kozlowski
2008-07-19 15:31 ` linux-next: Tree for July 18 (very early crash on x86_32) Bartlomiej Zolnierkiewicz
2008-07-20 0:20 ` linux-next: Tree for July 18: sky2 WOL broken Rafael J. Wysocki
2008-07-20 4:58 ` Stephen Hemminger
2008-07-20 15:39 ` Rafael J. Wysocki
[not found] ` <200807201739.22919.rjw-KKrjLPT3xs0@public.gmane.org>
2008-07-21 0:53 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080719225817.GA6264@suse.de \
--to=gregkh-l3a5bk7wagm@public.gmane.org \
--cc=bwalle-l3A5Bk7waGM@public.gmane.org \
--cc=haveblue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
--cc=kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=m.kozlowski-NWF1p15JEu3VItvQsEIGlw@public.gmane.org \
--cc=penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org \
--cc=sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org \
--cc=vegard.nossum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.