svn commit: r344099 - head/sys/net

Randall Stewart rrs at
Wed Feb 13 18:03:54 UTC 2019

oh and one other thing..

It was *not* a random IFP.. it was the IFP to the lagg.

I.e. an alloc() was done to the lagg.. and the free was
done back to the same IFP (that provided the allocate).


> On Feb 13, 2019, at 1:02 PM, Randall Stewart <rrs at> wrote:
> 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 <jhb at> 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:
>>> 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:
>> 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
> rrs at

Randall Stewart
rrs at

More information about the svn-src-all mailing list