On Tue, 09 Jan 2007 11:02:35 PST, Amit Choudhary said:
> Correct. And doing kfree(x); x=NULL; is not hiding that. These issues can still be debugged by
> using the slab debugging options. One other benefit of doing this is that if someone tries to
> access the same memory again using the variable 'x', then he will get an immediate crash. And the
> problem can be solved immediately, without using the slab debugging options. I do not yet
> understand how doing this hides the bugs, obfuscates the code, etc. because I haven't seen an
> example yet, but only blanket statements.
char *broken() {
char *x, *y;
x = kmalloc(100);
y = x;
kfree(x);
x = NULL;
return y;
}
Setting x to NULL doesn't do anything to fix the *real* bug here, because
the problematic reference is held in y, not x. So you never get a crash
because somebody dereferences x.
Attachment:
pgpzVEc7wnwDh.pgp
Description: PGP signature
- Follow-Ups:
- Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- From: Amit Choudhary <[email protected]>
- Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- References:
- Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- From: Amit Choudhary <[email protected]>
- Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- Prev by Date: Re: [2.6 patch] x86_64: re-add a newline to RESTORE_CONTEXT
- Next by Date: Re: [Patch 0/2] driver core: device_move() fallout.
- Previous by thread: Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- Next by thread: Re: [PATCH] include/linux/slab.h: new KFREE() macro.
- Index(es):
 |