# HG changeset patch
# User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
# Date 1200052669 -3600
# Node ID 5278b5fa14a754ea8c6cfdd7870cdb7fc6c62fe7
# Parent 393ba1344f5be2ea42b21adea0d377de440516dc
Make inst_list_free() handle NULL pointers
Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com>
diff -r 393ba1344f5b -r 5278b5fa14a7 inst_list.c
--- a/inst_list.c Fri Jan 11 10:33:08 2008 +0100
+++ b/inst_list.c Fri Jan 11 12:57:49 2008 +0100
@@ -50,6 +50,9 @@ void inst_list_init(struct inst_list *li
void inst_list_free(struct inst_list *list)
{
+ if (!list)
+ return;
+
free(list->list);
inst_list_init(list);
}
Show replies by date
HE> void inst_list_free(struct inst_list *list)
HE> {
HE> + if (!list)
HE> + return;
HE> +
HE> free(list->list);
HE> inst_list_init(list);
HE> }
I have no problem with this patch, although I'd like to reiterate that
it won't solve the initialization problem.
If you have this:
struct inst_list foo;
inst_list_free(&foo);
You're passing in the address of a stack variable, which will never be
NULL, so the additional check will fall through. The free() will then
attempt to free a garbage pointer (list is valid, but list->list is
not) and the heap is blown.
I'd also point out that we overwhelmingly use inst_list variables on
the stack, which means 99% of the time, this check won't help us, and
will just consume "extra cycles". I'm sure that this would eclipse
the overhead of a few unnecessary inst_list_init() calls :)
I'm fine applying this to handle the case where we might have a
dynamically-allocated list pointer. Any objections?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com