From: Alexander Viro <viro@math.psu.edu>
What??? You've just said that on the first stage you are not going to
free these objects and then add freeing them and audit the whole thing
at that point.
The first is commonly known as leak (objects are allocated but not freed).
You are mistaken. Allocation without freeing is not a leak.
A leak is the situation where an unbounded amount of memory is lost
over time because of repeated allocs without corresponding frees.
Allocation of a known, bounded amount of memory is no leak.
(But this has very little relevance except in a shouting match.
Your next remarks are more interesting.)
Dangling pointers is what you will have to fight during that audit -
places where something retains kdev_t after your object had been freed.
Let me rephrase it: with your plan we will have much more complex audit
needed at the moment when you introduce freeing your objects. Reason:
it will have to involve all subsystems using kdev_t at once. That's
my problem with your plan. Sigh...
I am not as afraid as you are.
Something retains kdev_t after the module has been unloaded?
That would be a bug, sure, both in the present and in the future kernel.
I listed the places where a kdev_t is stored (inode, sb, ..) and for
each of those it is true that these structs should be released before
or at module unload time, so that after module unload time no instances
of corresponding kdev_t are left.
Moreover, the audit happens fully automatically during the boring,
mechanical work. Indeed, already the separation of kdev_t into
kbdev_t and kcdev_t will touch all places where kdev_t occurs,
so that as a side effect one has a list of all places where one
of these is stored.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:19 EST