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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <84144f020701080126l550bba8v590cf00b12d46585@mail.gmail.com>
Date:	Mon, 8 Jan 2007 11:26:17 +0200
From:	"Pekka Enberg" <penberg@...helsinki.fi>
To:	"Amit Choudhary" <amit2030@...oo.com>
Cc:	"Hua Zhong" <hzhong@...il.com>,
	"Christoph Hellwig" <hch@...radead.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] include/linux/slab.h: new KFREE() macro.

On 1/8/07, Amit Choudhary <amit2030@...oo.com> wrote:
> It is a programming error because the underlying code cannot handle it.

Yes. Do you also grasp the fact that there is no way for the allocator
to handle it either? So, double-free, from allocator standpoint can
_never_ be no-op.

What you're proposing is _not_ making double-free no-op, but instead,
making sure we never have a reference to p after kfree(p). However,
(1) that bloats the kernel text and (2) doesn't actually guarantee
that there are _no_ references to p (you can have an alias q for it,
but there's no way for us to know that).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/