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] [day] [month] [year] [list]
Date:	Thu, 11 Sep 2014 16:14:52 +0200
From:	Rasmus Villemoes <linux@...musvillemoes.dk>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	Theodore Ts'o <tytso@....edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm/sl[aou]b: make kfree() aware of error pointers

On Wed, Sep 10 2014, Jiri Kosina <jkosina@...e.cz> wrote:

> On Wed, 10 Sep 2014, Dan Carpenter wrote:
>
>> > BTW if we stretch this argument a little bit more, we should also kill the 
>> > ZERO_OR_NULL_PTR() check from kfree() and make it callers responsibility 
>> > to perform the checking only if applicable ... we are currently doing a 
>> > lot of pointless checking in cases where caller would be able to guarantee 
>> > that the pointer is going to be non-NULL.
>> 
>> What you're saying is that we should remove the ZERO_SIZE_PTR
>> completely.  ZERO_SIZE_PTR is a very useful idiom and also it's too late
>> to remove it because everything depends on it.
>
> I was just argumenting that if we care about single additional test in 
> this path, the ZERO_OR_NULL_PTR() should have never been added at the 
> first place, and the responsibility for checking should have been kept at 
> callers.

I think it makes a lot of sense to have the domain of kfree() be exactly
the codomain of kmalloc() and friends. That is, what is acceptable to
pass to kfree() is exactly the set of values that might be returned from
kmalloc() et al. Those include NULL and the very useful unique
zero-sized "object" ZERO_SIZE_PTR, but does not include any ERR_PTR().

Having every caller of kfree() check for NULL would bloat the code size
considerably, and it seems that these checks are being actively removed.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ