[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87oaumdz1f.fsf@rasmusvillemoes.dk>
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