RE: Why is the kfree() argument const?

[David Schwartz]

> On Thu, 17 Jan 2008, David Schwartz wrote:

> > Nonsense. The 'kfree' function *destroys* the object pointer to by the
> > pointer. How can you describe that as not doing anything to the object?
>
> Here's an idea. Think it through.
>
> Why don't we need write permissions to a file to unlink it?

You cannot unlink a file. Given a file, if you were to attempt to unlink it,
what directory would you remove it from?

Unlinking a file is an operation on the directory the file is in, not on the
directory itself. We do need write permissions to the directory.

If you had only a const pointer to the data in the file, you should
definitely not be able to use that pointer to find a directory the file is
in and remove it without clearly indicating you know *exactly* what you're
doing. Given just that 'const' pointer, you're not supposed to be modifying
the data and certainly using that pointer to modify anything logically above
it.

> Here's a hint: because unlinking doesn't *write* to it. In fact, it
> doesn't read from it either. It doesn't do any access at all to that
> object, it just *removes* it.

Right. It's an operation on the directory the file is in that might have
consequences for the file.

> Is the file gone after you unlink it? Yes (modulo refcounting for
> aliasing
> "pointers" aka filenames, but that's the same for any memory manager -
> malloc/free just doesn't have any, so you could think of it as a
> non-hardlinking filesystem).

The file is gone if and only if the directory was the only thing that needed
the file to exist. A file that is only on one directory "belongs to" that
directory. So write permission to the directory is all that is needed.

What you are arguing is essentially that you should be able to remove a file
from any directory it is in just because you have write access to the file's
data.

> So you're the one who are speaking nonsense. Making something "not exist"
> is not at all the same thing as accessing it for a write (or a read). It
> is a metadata operation that doesn't conceptually change the data in any
> way, shape or form - it just makes it go away.

Making something "not exist" is a modification operation on that thing.

> And btw, exactly as with kfree(), a unlink() may well do something like
> "disk scrubbing" for security purposes, or cancel pending writes to the
> backing store. But even though it may write (or, by undoing a pending
> write, effectively "change the state") to the disk sectors that used to
> contain the file data, ONLY AN IDIOT would call it "writing to the file".
> Because "the file" is gone. Writing to the place where the file
> used to be
> is a different thing.

I agree with you about that part. I can't understand why you keep thinking
this is where our disagreement lies when I've stated at least three times
that I agree about this. The issue has nothing to do with whether or not
'kfree' modifies the particular bytes pointed to. It has to do with whether
or not 'kfree' is the kind of operation one would normally want to allow on
a 'const' object.

> So give it up. You're wrong. Freeing a memory area is not "writing to it"
> or accessing it in *any* manner, it's an operation on another level
> entirely.

Nevertheless, it's a modification operation on an object that's not supposed
to be modified.

By the way, I did think of one argument that supports your position: Suppose
you have a reference counted object. You have a 'release reference and free
if zero' function. Should it be 'const'? If not, how can a 'lookup and
reference for read' function return a const pointer to the object?

However, on balance, I think a 'release reference and free if zero' function
that operates on a const pointer is sufficiently unusual that a cast to show
you know what you're doing is not a bad thing. In this case, you know it's
safe to destroy the object through a const pointer because you *know* nobody
gave you the 'const' pointer trusting you not to destroy the object. A cast
to show you have that special knowledge is, IMO, reasonable.

DS


--
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/