David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Sat, 27 Aug 2005 01:23:25 -0700
The more interesting parts of the patch is below. The basic
idea is to pass a key in when you hold or put a device. This key
matches puts with holds. #defined macros grab the file name and
line number for printing out later. Duplicate keys are not desired,
but they should not break anything other than possibly pointing to the
wrong code as leak culprit.
Hmmm, how about dynamically registered integer keys?
These are just descriptors, anyways.
struct netdev_refcnt_client {
struct list_head list;
const char *name;
__u16 id;
};
int register_netdev_refcnt_client(struct netdev_refcnt_client *);
void unregister_netdev_refcnt_client(struct netdev_refcnt_client *);
The register fills in the "id" field on success, and stores the
struct in some lookup table somewhere.
This way you only need to store __u16's during the actual operations.
Only when you want a dump or a log do you have to go fetching out
the strings and pointers. You can even use a linked list since
lookup performance is not critical, since it only occurs when the
bug condition triggers. This is very space efficient for storing
the dev/get logging trails.
Since clients register, you can even provide some sysfs file that
lists the clients.
So each module, or perhaps each unique usage of dev get/put in
a module would register a new netdev_rfcnt_client object and
use it's index similar to how I use the 'key' ?
You would still have to allocate a new object for the reference
list for each dev-get, and free it for each dev-put, right?
I was thinking that if we have to go to kmalloc anyway, then
a few extra bytes to hold pointers really isn't that big of
a deal..especially for debugging code...
Does your scheme bother with removing references on dev-put, or
do you just keep a running log and do interesting debugging
on failure?
Although my implementation is not there yet, it would be nice if we
could use the address of the pointer than holds the dev reference
as the key. We should then be able to also catch double dereferences
and places where the same pointer is used to hold two references at
the same time (ie, forgot to drop the old ref before adding the new.)
If one had a particularly nasty case (maybe a leaked route cache object
holding a reference), it might be possible to do some in-depth debugging
in a debugger if you had the address of it's foo.dev pointer as a starting
point too...
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
