lkml.org 
[lkml]   [2008]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 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.


\
 
 \ /
  Last update: 2008-07-30 11:23    [W:0.467 / U:1.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site