On Thursday, October 24, 2002, at 11:50 PM, Christophe Allie wrote:

No. The refcount doesn't count the filters, but count the protocols.

If an interface is detached, the detach function of your filter is

called,

and then interface detachment continues. You have no way to prevent

that

from a filter.

OK. Since my only copy of the ifnet* is in a member of an object I can reach by casting the cookie I can handle that.

...

for (ifp = ifnet.tqh_first; ifp; ifp = ifp->if_link.tqe_next) {

...

... new InterfaceObject( ... ifp ...);

...

}

I think walking the list of ifnet is unfortunately the only way to

discover

the all ifnet. However, if you do an allocation like new

InterfaceObject,

you can loose the funnel, and potentially the list can be updated by an

other code.

So "new" allocations are done as M_WAITOK? That's unfortunate. (One work around might be to preallocate them. Or I could override the new operator.) But the problem remains if preemption is possible since the thread could exhaust its time quantum.

...

And if that happens, couldn't the interface list change while I'm

...

iterating over it?

That's possible.

This sounds like a kernel panic just waiting to happen. Yet I see these sorts of loops in many places in xnu. (Admittedly they likely don't try to allocate a C++ instance while iterating.) Surely there must be some way to safely iterate over the interface list. Anyone know of a solution to this? Thanks, Mike _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.