David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>

All the list stuff gets compiled out unless we're debugging.
So this netdev_pointer degenerates into a fancy pointer.

We can use a "struct list_head" to avoid the unlink complexity.

Ok, glad to see it can be compiled away as needed.

The list-head actually fixes the O(N) unlink problem, or it just is
less code to re-implement?

Right, but we want to catch the cases where someone forgets, so the
pointer object cannot be on the stack (we need something to reference
X time later when we try to free the device and want to know who has
a handle.)  This implies kmalloc to me, since setting any static amount
of them in the netdevice is just asking for trouble (or known failure
mode, to use your term :)


Maybe these cases are so "obvious" that they don't need the tracking
code.

Well, I've found at least one of these already just by auditing
the code, and there may be more that are lurking that were
not so easy to spot.  I'm fine with paying the malloc price if
that is what is required to get total coverage.

It will also take more invasive changes to implement your
method, I believe.  That is fine if it gets the job done, but
after tangling with some of this code, there is little chance
that I can convert many of the more complex modules in a reasonable
time frame.  It's just too hard to flow where things are acquired
and released (it is often NOT just where the assignment to foo->dev is made).

For what it's worth, here is the link to my patch with cleaned up
white space and less capitals.  It also instruments the entire
kernel (make allyesconfig builds, haven't actually tested most
of the stranger protocols.)
This patch also implements the bulk malloc logic I spoke of.
Compiles but not tested:  I'm going to start testing again
tomorrow and try to reproduce and track down that leak I saw
earlier in neighbor.c

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

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