This is a possible memory leak that I discovered only by accidental code
reading.
--
If kvasprintf fails in kobject_set_name_vargs, the memory used by
the original kobj->name is leaked. Fix that. I also avoid useless
memory accesses to kobj->name by using the local variables old_name
and new_name instead.
Signed-off-by: Philippe De Muyter <ph...@macqel.be>
diff -r 373fdd3df333 linux-2.6.x/lib/kobject.c
--- a/linux-2.6.x/lib/kobject.c Wed Aug 19 23:26:44 2009 +0200
+++ b/linux-2.6.x/lib/kobject.c Sat Mar 13 13:35:43 2010 +0100
@@ -216,20 +216,22 @@ int kobject_set_name_vargs(struct kobjec
va_list vargs)
{
const char *old_name = kobj->name;
+ char *new_name;
char *s;
- if (kobj->name && !fmt)
+ if (old_name && !fmt)
return 0;
- kobj->name = kvasprintf(GFP_KERNEL, fmt, vargs);
- if (!kobj->name)
+ new_name = kvasprintf(GFP_KERNEL, fmt, vargs);
+ if (!new_name)
return -ENOMEM;
/* ewww... some of these buggers have '/' in the name ... */
- while ((s = strchr(kobj->name, '/')))
+ while ((s = strchr(new_name, '/')))
s[0] = '!';
kfree(old_name);
+ kobj->name = new_name;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the routine kobject_set_name_vargs() is described in
Documentation/kobject.txt as "legacy cruft" to be removed at some
point, so it's not clear there's any value in "fixing" it.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
Given I submitted a similar patch two days before, I guess a fix would
be welcome or else we might see one or two attempts per week from
various people.
http://lkml.org/lkml/2010/3/11/438
Legacy or not, this code looks wrong. I caught it while looking for
kmemleaks reports on my dev machine, that were triggered by
CONFIG_NO_BOOTMEM use.
fair enough, i was just going off of what i read in Doc/kobject.txt.