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

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Fri, 22 Jan 2016 16:29:40 +0000
   From: Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>

   Part (2) makes ip_encap scale well to many cores, but it stops
   ip_encap from scaling well to many tunnels, because it removes the
   radix tree.  Maybe that's OK -- maybe today, scaling to many cores is
   more important than scaling to many tunnels.

Oops -- I didn't read encap4/6_lookup closely enough.  They *always*
iterate over the entire list of tunnels and call every relevant
function stored there to prioritize matches.  So the radix tree
probably never did help (much) to scale to many tunnels after all, and
my concern was entirely moot!

If you want to skip the radix tree, I suggest committing essentially
the reverse of ip_encap.c 1.45 first (remove old USE_RADIX case),
separately from any MP issues.

That said, it is still not clear to me how you guarantee the tunnel
will continue to exist in encap4/6_input, after pserialize_read_exit
and during the call to psw->pr_input.

I also wonder whether it is OK to call ep->func inside a pserialize
read section: it enters a lot of nested callbacks in the network stack
which don't look safe to me.  For example, gif_encapcheck4 calls
gif_validate4 calls rtalloc1 which doesn't look very safe for
pserialize read to me.