jamal wrote:
On Sun, 2005-28-08 at 01:19 -0700, Ben Greear wrote:
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.)
I thought you could get a dead fish sent to you for doing things like
these? ;->
Some comments:
- I think it would be nice if the feature would work only if someone
turned some debug selection in kconfig. i.e zero overhead otherwise.
Agreed, should be easy to do.
- That i dont have to modify the header file every time i want to use
the feature from some other (new) code would be nice.
Clearly dynamic registration for these numbers at init would help (Dave
was saying the same in his email); however, another approach could be
to declare a single number as "unknown" that could be used by all and
another range of IDs that could be used by newer code (sort of like the
10.0.0.0 address range).
I can add a generic value for all 'other' uses. You can also just randomly
pick an odd value and it will work. Even if you clash with something else,
you could narrow down the problem to your module and whatever else is using
that value.
I can add comments that suggest using some value above 0x10000001
for non-well-defined values.
I'd rather not have to deal with dynamic registration...I don't think it
adds enough benefit to be worth the overhead.
- Would it be nice also to see which processor the ref came from?
For unique keys (ie, addresses of pointers to netdevice), this might
be useful. For others, it is not possible to exactly match a particular
get with a put. Also, I'm hoping that if I can pin the exact line that
the lost reference was grabbed at it should be fairly easy to find the
leak after that by auditing the code..
- Hey, why stop at dev refcounts? ;-> There are a lot of other
references that would be nice to have this feature on for debuging ;->
And why stop at refcounts at all - go all the way to locks too. I once
had to chase a tricky SMP lock contention (classical deadlock problem)
and wrote similar code for locks. It helped nail it.
Sure...but one thing at a time :)
- It would be nice to have features like "dump everyone who is holding a
ref count to eth0" kind of operation.
Will add this today if time allows.
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
