HI Greg, On Wed, 30 Jul 2008 16:44:19 -0700 Greg KH <gregkh@xxxxxxx> wrote: > > On Thu, Jul 31, 2008 at 09:41:05AM +1000, Stephen Rothwell wrote: > > Hi Andrew, > > > > On Wed, 30 Jul 2008 13:04:19 -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > The offending patch has just got itself turfed from linux-next so my > > > fix now has nothing to fix. > > > > > > We'll see what happens! > > > > I will put Dave's patch back with yours on top of it (hoping that Greg > > will take your patch). > > Greg will, it's in my queue. This is still not in your patch series ... summary email with patch repeated below. -- Cheers, Stephen Rothwell sfr@xxxxxxxxxxxxxxxx http://www.canb.auug.org.au/~sfr/ Date: Wed, 30 Jul 2008 02:19:47 -0700 From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> To: Bernhard Walle <bwalle@xxxxxxx> Cc: Greg KH <greg@xxxxxxxxx>, Hugh Dickins <hugh@xxxxxxxxxxx>, Greg KH <gregkh@xxxxxxx>, Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, linux-next@xxxxxxxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Dave Hansen <haveblue@xxxxxxxxxx> Subject: driver-core: kobject verification fixup On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <bwalle@xxxxxxx> wrote: > * Greg KH <greg@xxxxxxxxx> [2008-07-29 21:48]: > > > Isn't this the opposite end of the same problem for which Bernhard > > > has been repeatedly trying to find a taker for his patch: > > > > > > http://article.gmane.org/gmane.linux.kernel.kexec/1882 > > > > Yes. It's not the kobject patch at fault here, it's the use of kobjects > > so early in the boot process. That needs to be fixed. It was a bit optimistic to stick an unconditional GFP_KERNEL allocation into the previously-atomic kobject_init(). It's only 128 bytes, so why can't we fix both problems thusly? --- a/lib/kobject.c~a +++ a/lib/kobject.c @@ -38,12 +38,10 @@ static int ptr_in_range(void *ptr, void static void verify_dynamic_kobject_allocation(struct kobject *kobj) { - char *namebuf; + char namebuf[KSYM_NAME_LEN]; const char *ret; - namebuf = kzalloc(KSYM_NAME_LEN, GFP_KERNEL); - ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL, - namebuf); + ret = kallsyms_lookup((unsigned long)kobj, NULL, NULL, NULL, namebuf); /* * This is the X86_32-only part of this function. * This is here because it is valid to have a kobject @@ -63,7 +61,7 @@ static void verify_dynamic_kobject_alloc /* dump_stack(); */ pr_debug("---- end silly warning ----\n"); out: - kfree(namebuf); + return; } #else static void verify_dynamic_kobject_allocation(struct kobject *kobj) { } _ > Yes, but if somebody could tell me why nobody takes the patch, I would > be happy. Then I would be able to improve the patch. :) Copy me on the patch. Then I merge it and people know there will be no hiding from it. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
