I disagree. If you define an alloc it is only reciprocal that you should define a free.
The code in question that hit this was changed (its in a version of rack that has the rate-limit and TLS code).. but I think these things *should* be balanced.. if you provide an Allocate, you should also provide a Free… R > On Feb 13, 2019, at 12:09 PM, John Baldwin <j...@freebsd.org> wrote: > > On 2/13/19 6:57 AM, Randall Stewart wrote: >> Author: rrs >> Date: Wed Feb 13 14:57:59 2019 >> New Revision: 344099 >> URL: https://svnweb.freebsd.org/changeset/base/344099 >> >> Log: >> This commit adds the missing release mechanism for the >> ratelimiting code. The two modules (lagg and vlan) did have >> allocation routines, and even though they are indirect (and >> vector down to the underlying interfaces) they both need to >> have a free routine (that also vectors down to the actual interface). >> >> Sponsored by: Netflix Inc. >> Differential Revision: https://reviews.freebsd.org/D19032 > > Hmm, I don't understand why you'd ever invoke if_snd_tag_free from anything > but 'tag->ifp' rather than some other ifp. What if the route for a connection > moves so that a tag allocated on cc0 is now on a route that goes over em0? > You can't expect em0 to have an if_snd_tag_free routine that will know to > go invoke cxgbe's snd_tag_free. I think you should always be using > 'tag->ifp->if_snd_tag_free' to free tags and never using any other ifp. > > That is, I think this should be reverted and that instead you need to fix > the code invoking if_snd_tag_free to invoke it on the tag's ifp instead of > some random other ifp. > > -- > John Baldwin > > ------ Randall Stewart r...@netflix.com _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
