From: Al Viro <viro@ftp.linux.org.uk>
To: Kai Makisara <Kai.Makisara@kolumbus.fi>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Dave Jones <davej@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org, ericvh@gmail.com,
rminnich@lanl.gov
Subject: Re: 9pfs double kfree
Date: Mon, 6 Mar 2006 09:34:01 +0000 [thread overview]
Message-ID: <20060306093401.GH27946@ftp.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.63.0603061031550.8581@kai.makisara.local>
On Mon, Mar 06, 2006 at 10:40:03AM +0200, Kai Makisara wrote:
> > Legal, but rather bad taste. Init to NULL, possibly assign the value
> > if kmalloc(), then kfree() unconditionally - sure, but that... almost
> > certainly one hell of a lousy cleanup logics somewhere.
> >
> I agree with you.
>
> However, a few months ago it was advocated to let kfree take care of
> testing the pointer against NULL and a load of patches like this:
That's different - that's _exactly_ the case I've mentioned above.
Moreover, that's exact match to standard behaviour of free(3):
C99 7.20.3.2(2):
The free function causes the space pointed to by ptr to be deallocated, that
is, made available for further allocation. If ptr is a null pointer, no action
occurs. Otherwise, if the argument does not match a pointer returned by the
calloc, malloc, or realloc function, or if the space has been deallocated by
a call to free or realloc, the behaviour is undefined.
IOW, free(NULL) is guaranteed to be no-op while double-free is nasal daemon
country.
next prev parent reply other threads:[~2006-03-06 9:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-06 7:04 9pfs double kfree Dave Jones
2006-03-06 7:07 ` David S. Miller
2006-03-06 7:23 ` Al Viro
2006-03-06 7:28 ` Dave Jones
2006-03-06 7:56 ` Pekka Enberg
2006-03-06 8:00 ` Dave Jones
2006-03-06 8:16 ` Al Viro
2006-03-06 8:23 ` Pekka Enberg
2006-03-06 8:27 ` Arjan van de Ven
2006-03-06 8:40 ` Kai Makisara
2006-03-06 9:34 ` Al Viro [this message]
2006-03-06 22:07 ` Pavel Machek
2006-03-09 14:48 ` Luke-Jr
2006-03-06 7:26 ` Balbir Singh
2006-03-06 7:31 ` Dave Jones
2006-03-06 7:39 ` Balbir Singh
2006-03-07 0:37 ` Andrew Morton
2006-03-07 1:04 ` Eric Van Hensbergen
2006-03-07 2:20 ` Latchesar Ionkov
2006-03-07 1:49 ` Latchesar Ionkov
2006-03-07 12:43 ` [PATCH] v9fs: fix for access to unitialized variables or freed memory Latchesar Ionkov
2006-03-07 23:04 ` Andrew Morton
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=20060306093401.GH27946@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=Kai.Makisara@kolumbus.fi \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=ericvh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=rminnich@lanl.gov \
/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.