fix gif(4)'s softint(9) contract violation [was Re: RFC: gif(4) MP-ify]

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2016/01/12 18:54, Kengo NAKAHARA wrote:
> On 2016/01/11 14:48, Taylor R Campbell wrote:
>> I think the following protocol should be simpler and safer:
>>
>> - One global interruptible lock for the system's gif(4) configuration.
>> - No per-gif(4) locks at all.
>> - Split gif_encap_detach (and in/in6_gif_detach) into two parts:
>>   . gif_encap_pause: prevent further use of gif_output (encap_detach)
>>   . gif_encap_detach: destroy data structures associated with it (rtcache_free)
>> - Make gif_set_tunnel do:
>>   1. acquire global lock
>>   2. check invariant -- reject duplicate gif src/dst addresses
>>   3. gif_encap_pause
>>   4. softint_disestablish
>>   5. gif_encap_detach, sockaddr_free
>>   6. gif_encap_attach
>>   7. softint_establish
>>   8. release global lock
>> - Make gif_delete_tunnel do:
>>   1. acquire global lock
>>   2. gif_encap_pause
>>   3. softint_disestablish
>>   4. gif_encap_detach, sockaddr_free
>>   5. release global lock
> 
> Hmm... ip_encap.c(encap_attach and encap_detach) is used by
> not only gif(4) but also stf(4) for now, so I think the global
> interruptible lock might be the common lock among gif(4), stf(4)
> and other interfaces which will use ip_encap.c.
> 
> Except it, the processing seems excellent.

I implement this processing. Here is the patch.
    http://netbsd.org/~knakahara/fix-gif-softint/fix-gif-softint.patch

The patch includes reverting cvs kern_softint.c:r1.42. Furthermore, 
the patch fixes the race between encap[46]_lookup(rnh->rnh_matchaddr)
and encap_detach(rnh->rnh_deladdr) keeping packet processing path
lockless.
# I think radix tree must be required lock.

However, this patch doesn't make gif(4) mp-ify yet. I will send gif(4)
mp-ify patch later.

Could you comment this patch?


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>