All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Hugh Dickins <hugh@veritas.com>
Cc: Matt Mackall <mpm@selenic.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	David Vrabel <david.vrabel@csr.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Chas Williams <chas@cmf.nrl.navy.mil>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Christoph Lameter <cl@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>
Subject: Re: [patch 1/7] slab: introduce kzfree()
Date: Thu, 19 Feb 2009 21:45:48 +0200	[thread overview]
Message-ID: <499DB6EC.3020904@cs.helsinki.fi> (raw)
In-Reply-To: <Pine.LNX.4.64.0902191819060.28475@blonde.anvils>

Hi Hugh.

Hugh Dickins wrote:
> Thanks for that, I remember it now.
> 
> Okay, that's some justification for kfree(const void *).
> 
> But I fail to see it as a justification for kzfree(const void *):
> if someone has "const char *string = kmalloc(size)" and then
> wants that string zeroed before it is freed, then I think it's
> quite right to cast out the const when calling kzfree().

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". 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.

			Pekka

WARNING: multiple messages have this Message-ID (diff)
From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Hugh Dickins <hugh@veritas.com>
Cc: Matt Mackall <mpm@selenic.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	David Vrabel <david.vrabel@csr.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Chas Williams <chas@cmf.nrl.navy.mil>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Christoph Lameter <cl@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>
Subject: Re: [patch 1/7] slab: introduce kzfree()
Date: Thu, 19 Feb 2009 21:45:48 +0200	[thread overview]
Message-ID: <499DB6EC.3020904@cs.helsinki.fi> (raw)
In-Reply-To: <Pine.LNX.4.64.0902191819060.28475@blonde.anvils>

Hi Hugh.

Hugh Dickins wrote:
> Thanks for that, I remember it now.
> 
> Okay, that's some justification for kfree(const void *).
> 
> But I fail to see it as a justification for kzfree(const void *):
> if someone has "const char *string = kmalloc(size)" and then
> wants that string zeroed before it is freed, then I think it's
> quite right to cast out the const when calling kzfree().

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". 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.

			Pekka

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-02-19 19:50 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-17 18:26 [patch 0/7] kzfree() v2 Johannes Weiner
2009-02-17 18:26 ` Johannes Weiner
2009-02-17 18:26 ` [patch 1/7] slab: introduce kzfree() Johannes Weiner
2009-02-17 18:26   ` Johannes Weiner
2009-02-17 20:06   ` Christoph Lameter
2009-02-17 20:06     ` Christoph Lameter
2009-02-18 10:50   ` David Vrabel
2009-02-18 10:50     ` David Vrabel
2009-02-18 10:54     ` Pekka Enberg
2009-02-18 10:54       ` Pekka Enberg
2009-02-19  1:22       ` KOSAKI Motohiro
2009-02-19  1:22         ` KOSAKI Motohiro
2009-02-19  9:13         ` Pekka Enberg
2009-02-19  9:13           ` Pekka Enberg
2009-02-19 12:12           ` KOSAKI Motohiro
2009-02-19 12:12             ` KOSAKI Motohiro
2009-02-19 16:34           ` Hugh Dickins
2009-02-19 16:34             ` Hugh Dickins
2009-02-19 18:02             ` Matt Mackall
2009-02-19 18:02               ` Matt Mackall
2009-02-19 18:28               ` Hugh Dickins
2009-02-19 18:28                 ` Hugh Dickins
2009-02-19 19:45                 ` Pekka Enberg [this message]
2009-02-19 19:45                   ` Pekka Enberg
2009-02-19 20:36                   ` Hugh Dickins
2009-02-19 20:36                     ` Hugh Dickins
2009-02-23 14:01                     ` Nick Piggin
2009-02-23 14:01                       ` Nick Piggin
2009-02-23 14:51                       ` Hugh Dickins
2009-02-23 14:51                         ` Hugh Dickins
2009-02-23 15:07                         ` Nick Piggin
2009-02-23 15:07                           ` Nick Piggin
2009-02-23 19:42                         ` Andrew Morton
2009-02-23 19:42                           ` Andrew Morton
2009-02-19 19:48                 ` Johannes Weiner
2009-02-19 19:48                   ` Johannes Weiner
2009-02-17 18:26 ` [patch 2/7] crypto: use kzfree() Johannes Weiner
2009-02-17 18:26   ` Johannes Weiner
2009-02-20  4:53   ` Herbert Xu
2009-02-20  4:53     ` Herbert Xu
2009-02-17 18:26 ` [patch 3/7] s390: " Johannes Weiner
2009-02-17 18:26   ` Johannes Weiner
2009-02-17 18:26 ` [patch 4/7] md: " Johannes Weiner
2009-02-17 18:26   ` Johannes Weiner
2009-02-17 18:26 ` [patch 5/7] usb: " Johannes Weiner
2009-02-17 18:26   ` Johannes Weiner
2009-02-18 10:51   ` David Vrabel
2009-02-18 10:51     ` David Vrabel
2009-02-17 18:26 ` [patch 6/7] cifs: " Johannes Weiner
2009-02-17 18:26   ` Johannes Weiner
2009-02-17 18:26 ` [patch 7/7] ecryptfs: " Johannes Weiner
2009-02-17 18:26   ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=499DB6EC.3020904@cs.helsinki.fi \
    --to=penberg@cs.helsinki.fi \
    --cc=akpm@linux-foundation.org \
    --cc=chas@cmf.nrl.navy.mil \
    --cc=cl@linux-foundation.org \
    --cc=david.vrabel@csr.com \
    --cc=hannes@cmpxchg.org \
    --cc=hugh@veritas.com \
    --cc=johnpol@2ka.mipt.ru \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpm@selenic.com \
    --cc=npiggin@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.