Messages in this thread Patch in this message | | | Date | Wed, 30 Jul 2008 02:19:47 -0700 | From | Andrew Morton <> | Subject | Re: linux-next: Tree for July 29 |
| |
On Wed, 30 Jul 2008 09:06:50 +0200 Bernhard Walle <bwalle@suse.de> wrote:
> * Greg KH <greg@kroah.com> [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.
| |