Re: [patch 1/7] slab: introduce kzfree()

On Tuesday 24 February 2009 01:51:05 Hugh Dickins wrote:
On Tue, 24 Feb 2009, Nick Piggin wrote:
Well, the buffer is only non-modified in the case of one of the
allocators (SLAB). All others overwrite some of the data region
with their own metadata.

I think it is OK to use const, though. Because k(z)free has the
knowledge that the data will not be touched by the caller any
longer.

Sorry, you're not adding anything new to the thread here.

Yes, the caller is surrendering the buffer, so we can get
away with calling the argument const; and Linus argues that's
helpful in the case of kfree (to allow passing a const pointer
without having to cast it).

(Yes, not that I agree his argument is strong enough to be able
to call libc's definition wrong)

My contention is that kzfree(const void *ptr) is nonsensical
because it says please zero this buffer without modifying it.

But the change has gone in, I seem to be the only one still
bothered by it, and I've conceded that the "z" might stand
for zap rather than zero.

So it may be saying please hide the contents of this buffer,
rather than please zero it. And then it can be argued that
the modification is an implementation detail which happens
(like other housekeeping internal to the sl?b allocator)
only after the original buffer has been freed.

Philosophy.

Hmm, well it better if kzfree is defined to zap rather than zero
anyway. zap is a better definition because it theoretically allows
the implementation to do something else (poision it with some
other value; mark it as zapped and don't reallocate it without
zeroing it; etc). And also it doesn't imply that the caller still
cares about what it actually gets filled with.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/