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
