David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 07 Feb 2006 16:29:34 -0800
In the realm of straw ideas, how often are netdevs added and
removed, and would leaving a tombstone behind consume too much
memory?
That could work.
Another idea is to revisit the scheme of storing just the
ifindex in the SKB instead of the device pointer.
That means extra lookups of interface name to device pointer right? Would that
even be sufficient to keep a reference-count free netdev from being yanked out
from under someone?
The only thing that worries me about tombstones is someone with a QA test that
adds and removes a device over and over again, and fills the cemetery as it
were. It is afterall something of a deliberate memory leak.
Is there some way for a daemon or somesuch to try to "garbage collect" the
tombstones? I guess that gets back to knowing where things that might have a
reference to the netdev happen to be, which would be just about the same as the
suggestion to call into them somehow so it becomes known that none of them have
a reference...
Unless there is some sort of event where it is known that when it happens all
netdev references have been refreshed - something short of reboot of course.
What sort of pain and suffering would happen if an old tombstone were brought
back to life for a new device? Would that cause code referencing it to get all
bent out of shape? Is there anything that would "naturally" inform the entity
dereferencing to the newly undead that they were resurrected?
just thinking while typing
rick jones
-
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
