svn commit: r344099 - head/sys/net
Randall Stewart
rrs at netflix.com
Wed Feb 13 18:02:42 UTC 2019
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 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
rrs at netflix.com
More information about the svn-src-all
mailing list