Messages in this thread |  | | | From | Nick Piggin <> | | Subject | Re: [patch 1/7] slab: introduce kzfree() | | Date | Tue, 24 Feb 2009 01:01:24 +1100 |
| |
On Friday 20 February 2009 07:36:48 Hugh Dickins wrote: > On Thu, 19 Feb 2009, Pekka Enberg wrote:
> > Quite frankly, I fail to see how kzfree() is fundamentally different from > > kfree(). I don't see kzfree() as a memset() + kfree() but rather as a > > kfree() "and make sure no one sees my data". So the zeroing happens > > _after_ you've invalidated the pointer with kzfree() so there's no > > "zeroing of buffer going on". > > Well, that would be one way of picturing it, yes. > Imagine the "z" as for "zap" rather than "zero", > and the mechanism as opaque as Hannes suggests. > > > So the way I see it, Linus' argument for having const for kfree() applies > > to kzfree(). > > > > That said, if you guys think it's a merge blocker, by all means remove > > the const. I just want few less open-coded ksize() users, that's all. > > I wouldn't call it a merge blocker, no; though I still > think it makes far more sense without the "const" there.
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.
|  |