Re: [PATCH] include/linux/slab.h: new KFREE() macro.

From: Jesper Juhl
Date: Mon Jan 08 2007 - 06:10:36 EST


On 08/01/07, Amit Choudhary <amit2030@xxxxxxxxx> wrote:

--- Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:

> On 1/8/07, Hua Zhong <hzhong@xxxxxxxxx> wrote:
> > > And as I explained, it can result in longer code too. So, why
> > > keep this value around. Why not re-initialize it to NULL.
> >
> > Because initialization increases code size.
>
> And it also effectively blocks the slab debugging code from doing its
> job detecting double-frees.
>

Man, so you do want someone to set 'x' to NULL after freeing it, so that the slab debugging
code can catch double frees. If you set it to NULL then double free is harmless.

No, setting the pointer to NULL doesn't make a double free harmless it
just hides a bug. The real fix would be to remove the double free.

If you just set the pointer to NULL and ignore the double free then
you've just bloated the kernel with an extra pointless assignment and
left a kfree() call in the kernel that should not be there. In my
book that's a bug.
If instead you rework the code to avoid the double free, then you
avoid the pointless NULL assignment and you get rid of a kfree call,
and you also get to review the logic and find the flaw that lead to a
double free in the first place. A double free is not something we
should just sweep under the carpet and forget about, it's very likely
an indication that some logic is flawed and should be fixed.

This KFREE macro does not belong in the kernel IMHO.


--
Jesper Juhl <jesper.juhl@xxxxxxxxx>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/