cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c

[Julian Elischer]

Brooks Davis wrote:

>On Tue, Oct 19, 2004 at 06:19:10PM -0400, Robert Watson wrote:
>  
>
>>On Tue, 19 Oct 2004, Julian Elischer wrote:
>>
>>    
>>
>>>>>Another point: If you really want to keep the possibility to remove a
>>>>>protocol, you have to introduce some busy counter that pervents removal while
>>>>>the kernel is inside a protocol function. This has to be handled by the
>>>>>protocol itself, but it has to be taken care of somehow.
>>>>>          
>>>>>
>>>each protocol array entry could have either a mutex or a refcount or
>>>both.. 
>>>      
>>>
>>The trick here is to get just enough synchronization to not break, but not
>>enough to hurt.  That's one of the reasons why I feel like the heavier
>>weight approaches taken elsewhere may not be appropriate here.  I guess no
>>one is talking about loading UDP, but at the same time if we're going to
>>have generic loadable protocol support, it would be nice to get a pretty
>>clean API that would meet the requirements of higher volume protocols.  As
>>I mentioned in a previous e-mail, it might almost be desirable to say "no
>>unloading" and simply avoid the hard problems, since atomic add is easy
>>whereas atomic remove is hard.
>>    
>>
>
>One of the things I've been looking at with interfaces is trying to
>squash the really big races (mostly dummynet) by avoiding holding a
>pointer to an interface any longer then necessicary.  Instead I'm
>  
>
>planning to hold interface indexes instead.  
>  
>
I've been against this idea for some time..
there are some situations where interfaces can get created and destroyed 
as some relatively large rate.
(i.e several per second in a worst case.)

In particular I've seen interface reation and deltion on a very dynamic 
manner with some
proprietary VPN solutions with interfaces coming and going on a regular 
basis as links come up and down.


Consider doing the same as we do for PIDS..
in 386bsd. one of the ealiest bugs we saw was traced back originally to 
something using a process
pointer which had been stored somewhere. (The process however could exit)
The fix was to make a hash-table of pids and store the pid instead, (and 
a gen number).
If the process went away you couldn't find it, and the gen number would 
stop you from matching new processes.

I think the same thing here.. rather than storing an index into an array 
(which could change or
become invalid.) store a long interface ID that is always incremented 
and kept in a
small hash table. This allows  the slots in the array to be reused.  
(It's a pity an index is required by
some standards.. maye however they could live with the ID as well).
I'll live with the wrap time for interface creation.. (It'll probably 
outlive me however..)

>I'm planning to introduce a
>"struct ifnet dead_if" to return when the index is no longer valid.  It
>will attempt to have sane no-op values so when the big races are lost it
>doesn't matter.  At least with interface removals, the small races don't
>seem to actually happen much in practice so ignoring them may well be a
>better solution then requiring a refcount every time you need to touch
>an ifp.
>
>Once I get ipfw6 working, I'm planning to take a look at this some more.
>
>-- Brooks
>
>  
>