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]

Date:	Mon, 8 Jan 2007 00:57:27 -0800
From:	"Hua Zhong" <hzhong@...il.com>
To:	"'Amit Choudhary'" <amit2030@...oo.com>,
	"'Christoph Hellwig'" <hch@...radead.org>
Cc:	"'Linux Kernel'" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] include/linux/slab.h: new KFREE() macro.

> --- Hua Zhong <hzhong@...il.com> wrote:
> 
> > > Any strong reason why not? x has some value that does not 
> > > make sense and can create only problems.
> > 
> > By the same logic, you should memset the buffer to zero 
> before freeing it too.
> > 
> 
> How does this help?

It doesn't. I thought that was my point?
 
> > > 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.
> 
> Then why use kzalloc()? Let's remove _ALL_ the initialization 
> code from the kernel.

You initialize before use, not after.

> Attached is some code from the kernel. Expanded KFREE() has 
> been used atleast 1000 times in the
> kernel. By your logic, everyone is stupid in doing so. 
> Something has been done atleast 1000 times
> in the kernel, that looks okay. But consolidating it at one 
> place does not look okay. I am listing
> some of the 1000 places where KFREE() has been used. All this 
> code have been written by atleast 50
> different people. From your logic they were doing "silly" things.

Maybe you should first each one of them and see why they do it. 
And if there is no purpose than "better be safe than sorry", 
maybe you can then submit a patch to fix it.

-
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/