svn commit: r344099 - head/sys/net

[John Baldwin]

On 2/22/19 8:50 AM, Andrew Gallatin wrote:
> I think the misunderstanding here is that I think he's not getting the 
> ifp from the route.
> 
> My recollection is that he is holding the ifps when he enables HW pacing 
> in BBR.  Due to limitations in different NIC hardware, you can only have 
> N different rates, etc.  So he goes ahead and allocates those N rates up 
> front so that he knows he can reserve them & know that he can always get 
> them.
> 
> Then when the system reboots, BBR has an eventhandler that goes ahead 
> and frees those reservations.  I think that he's using the ifp that he's 
> holding here.
> 
> In the case that tripped him up, that ifp was lagg.
> 
> Your workaround would also work, but Randall does have a point about 
> symmetric alloc/free especially when viewed from his perspective,

But it's not really an alloc.  We have many other places in the kernel where
an alloc routine is actually a "forward" to something else that allocates the
real thing.  For example, when you add a kevent on a file descriptor, that is
routed to the 'file_filtops' in kern/kern_event.c, but that filtops only has
an attach routine, it doesn't have a detach routine because it's attach
routine is a forwarder to other filtops.  It invokes the fo_kqfilter method
that is responsible for setting up the right filtops to use.  For sockets
this routes to one of three filtops that all have detach methods but no
attach methods.  The way this is handled is that anytime a kevent is
detached, the current filtops is used to find the detach event handler.
We don't use the filter's type to get back to the original file_filtops and
require that to forward the detach request on to the real filtops.  Having
the tag save the "real" ifp is similar to knote's storing the real filtops.

Given your specific use case, it does seem that this commit is sufficient,
but it's not the "always works" way to free a tag, and it might be used as a
template that gets copied for use in another case where the extra guarantees
of this specific use case don't hold.  Given that I'd like to explore making
lagg and vlan allocate real interposing tags to handle TLS, this may prove
mostly academic as they would have "real" free routines then since their
alloc routines would just be forwarders.

-- 
John Baldwin