Thanks!

Address review feedback

In D49395#1126219, @kib wrote:

What is the purpose of this change?

Awesome, thanks! Let me know if you need help with the process- I'd like others to be comfortable with updating the caroot bundle as I'd never intended to be the long-term maintainer of it, but I've failed repeatedly to entice anyone else into dealing with it.

In D49294#1124880, @michaelo wrote:

In D49294#1124877, @kevans wrote:

This looks reasonable to me, thanks! We'll want an associated EN, as well- are you OK with preparing for that?

I must admit that I have no idea how to create an EN. Whould that apply only to stable branches?

This looks reasonable to me, thanks! We'll want an associated EN, as well- are you OK with preparing for that?

LGTM, thanks!

Yes, sorry, I forgot that arc doesn't update commit messages. This is what I have locally:

Seems reasonable to me, thanks

Address feedback:

• Use RO_GET_FAMILY() to be more technically correct
• Assert that we get the same answer from the encapsulated ip hdr
• Fix the text description since we can't route ipv4 over an ipv6 nexthop

In D49172#1122101, @zlei wrote:

IPv6 packets can be routed via an IPv4 nexthop

IIRC that has not been implemented / supported yet, as IPv6 has much richer addresses, e.g., IPv6 via IPv6 LL nexthop, we do not need IPv6 via IPv4 nexthop.

Ninja cleanup address assignments in the test

In D48464#1120848, @arrowd wrote:

Or is it only for children of the root filesystem (nested under the BE)?

Yes, it is a child of a user's home dataset, which is encrypted.

I completely forgot about this... LGTM.

In D48766#1112402, @mhorne wrote:

Yes, this is smarter.

I kind of regret adding this thing. Although it is conceptually helpful/correct, its positive practical impact has so far been zero, while it has created several headaches.

Whoops, good catch, thanks

Highlights:

• Cache the catpages
• Limit rights(4) on UDP sockets immediately post-bind(2), rather than repeatedly- we shouldn't need higher privileges anymore
• Better explain setup_ctrl_caps()
• Switch the discard UDP service to enter capability mode, as a means of demonstrating that it does work for UDP services as well

In D48483#1106209, @emaste wrote:

This looks reasonable to me but could it be that whatever base64 exists on typical Linux distros allows "incorrect" argument order?

I'm doing a more thorough review of vt_window_switch() after thinking more on jhb's comment in D48413... the lock moved in that one is for a branch that's effectively dead code after this change and should've been removed here anyways. Right now I just get a frozen UI if I panic with xfce in focus on ttyv9 (but no nested panic), and I'm not sure I'm convinced that that would play out any differently even if we could attempt most of the rest of vt_window_switch() while panicking.

In D48414#1104253, @jhb wrote:

I'm fine with this. Don't the locking implementations just bail without panicking though if a panic is already active, or is the nested panic not inside a lock but elsewhere?