Re: Using ifnet pointers safely
Re: Using ifnet pointers safely
- Subject: Re: Using ifnet pointers safely
- From: Michael Cashwell <email@hidden>
- Date: Fri, 25 Oct 2002 01:49:43 -0400
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.