Date: Thu, 14 Jul 2011 17:27:01 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Gleb Smirnoff <glebius@freebsd.org> Cc: gnn@freebsd.org, bz@freebsd.org, rwatson@freebsd.org, net@freebsd.org Subject: Re: m_pkthdr.rcvif dangling pointer problem Message-ID: <20110715002701.GH1822@funkthat.com> In-Reply-To: <20110714154457.GI70776@FreeBSD.org> References: <20110714154457.GI70776@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff wrote this message on Thu, Jul 14, 2011 at 19:44 +0400: > 2) kib@ suggested to allocate ifnets from a UMA_ZONE_NOFREE zone. > I've made a compilable & working patch: > > http://people.freebsd.org/~glebius/patches/ifnet.no_free > > But on second though I find this a bad idea, this is just fooling > of INVARIANTS. Yes, we avoid thrashing of freed memory and rewriting > it by some other kernel allocation. But still out pointer point to > invalid ifnet. Even, if we make a check for IFF_DYING flag, we still > can not guarantee that an interface had been re-allocated for a new > instance. This would be not a panic condition, but subtle bugs in > firewalls. > > 3) As we now have a straight if_index table that can grow, what about > storing the if_index in the m_pkthdr? Lookup of interface by index > is fast enough if done lockless. Doing it lockless isn't perfect, but > better than current pointer dereferncing. Optionally it could be > done with locking and with putting a reference. To avoid situation > with with getting to a re-allocated interface with the same index, > we can use a unique cookie, that is incremented in if_alloc(). How is this any different than #2? I assume that if_index's are reused causing the same issues w/ the firewall that #2 has. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110715002701.GH1822>