David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Sat, 27 Aug 2005 11:19:24 -0700


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


You make some good points, let me think about it.

One worrysome spot is the case where multiple references
from a single client are legal.  I can't think of any such
cases here, but it's something to at least consider.

Here's an updated patch (git working better now, thanks!):

http://www.candelatech.com/oss/rfcnt.patch

I started a list of constants #defined in netdevice.h.  These
will be used for all stack variable references and other places
where I cannot determine the address of the reference to the
netdevice.  (Someone versed in particular modules may be able to
get rid of some of the constants if desired.)

The constants are all odd, and the verification code in dev.c
will not check for duplicate references to anything with an
odd address.  I am assuming that any real address of a pointer
will NOT be odd, and duplicate reference checks are done
for these...

This code seems to at least mostly work (system boots and pings
the web, does NFS, etc).  Probably breaks the compile if the
debugging option is not enabled in kconfig at this point.

There are more modules yet to convert (ipv6 comes to mind).  If/when
we agree that this method is worth pursuing, I'll convert the rest
of the modules.

In the meantime, comments are welcome, and I'll start trying to
track down the elusive leak that started all this...

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

Reply via email to