See also https://reviews.freebsd.org/D32847

In D36691#839695, @kp wrote:

What problem does this fix? In other words, what is the motivation for this change?

No known problems.
When I was trying to resolve https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266712, I dug into the privileges design. I checked multiple tunnel interface implementations and found that if_me shares network privilege with if_gre. Intuitively this would confuse consumer. Fortunately there is no other consumers in base system.

Is there a use case for separating the GRE and ME privs? It's conceptually cleaner, but it could (theoretically at least, I doubt anyone actually does this) break existing configurations that rely on granting PRIV_NET_GRE to administer me interfaces.

There is no other consumers (of PRIV_NET_GRE) in base system, except for if_gre and if_me. I have not checked ports yet but it should be easy to fix ( in ports ).

What problem does this fix? In other words, what is the motivation for this change?

The IPv4/IPv6 over IPv6 vxlan looks good after test.

1. Rebase
2. Update as @bryanv suggested.

I would expect there are other avoidable slowdowns which prevent realizing the benefit.

In D36872#837076, @glebius wrote:

Is there any performance increase?

In D36872#837077, @zlei.huang_gmail.com wrote:

For 12.x, i386 is Tier 1 supported platform. The counter_u64_add() still has runtime branches.

There is a long trend in FreeBSD to make struct ifnet as less visible to drivers as possible. Ideally make it fully opaque. That will allow to change struct ifnet without breaking KBI of drivers. Some years ago I was really close, see https://svnweb.freebsd.org/base/projects/ifnet/. Actually today we have less drivers and this project is worth resurrecting, if I or somebody else have time for it.

For 12.x, i386 is Tier 1 supported platform. The counter_u64_add() still has runtime branches.

Is there any performance increase?

This looks sane to me. We really do have to make sure there's enough contiguous data before we access it.

Document the change in man pages.

In D34579#828698, @glebius wrote:

I can't see how this can be used maliciously, e.g. forcing some application outside of jail to send its SCM_RIGHTS to a jail.

In D32820#824395, @zlei.huang_gmail.com wrote:

Hi @melifaro ,
Any chance will this be MFCed into stable/13 ?

I can't see how this can be used maliciously, e.g. forcing some application outside of jail to send its SCM_RIGHTS to a jail. Even if such case exists for a certain application, that would be bug in that application, IMHO. The initial idea of SCM_RIGHTS was actually to grant rights intentionally, so there can be a valid case for a certain application that wants to grant rights to its peer in a jail.

Committed.
https://cgit.freebsd.org/src/commit/?h=vendor/dhcpcd&id=96dba636abec6d5451820add99300bda2ca6d86a

This looks good.

Hi @melifaro ,
Any chance will this be MFCed into stable/13 ?

In D36242#823477, @cy wrote:

Will there be a man page update for this at some point?

Will there be a man page update for this at some point?

I like this (and will commit it soon), but there's two epoch_drain_callbacks() in sys/net/if.c that should also be changed. I'll do that as part of the commit.

fixed file path in diff

Thanks for the review!

Nothing left for me to review here since the manual page was addressed elsewhere, I think.

Ping .

I agree with all the comments above; I can't think of any significance to order of configuration of interfaces now. It might still affect the order of the interface list returned from the kernel, but most things that look at that list now process the whole thing.

Since Mike is still around, added him to confirm :)

This was in 4.3BSD:

The loopback interface should be the last interface configured,
as protocols may use the order of configuration as an indication of priority.
The loopback should \fBnever\fP be configured first unless no hardware
interfaces exist.

which is word-for-word identical, except for markup. It likely was true in the mid 80s, but I agree, it's no longer true or necessary. Mike Karels added it with the unhelpful commit message "warning about order of configuration" in 1986.

The text comes from pre-FreeBSD times.

@melifaro Done!

In D32820#809133, @pauamma_gundo.com wrote:

A few more nits, and https://reviews.freebsd.org/D32820?id=105449#inline-217280 still (and a few more minor nits)

Also: maybe it's worth considering splitting this review into two? Most of the ifconfig.8 changes does not look directly related to the review topic.

A few more nits, and https://reviews.freebsd.org/D32820?id=105449#inline-217280 still (and a few more minor nits)

D35409 and D35384 have been merged. Let's move on :)

Rebased on latest main branch.

Some minor nits found.

Test OK.

Fix bug in m_rcvif_restore() .

Fix whitespace.

Merge in changes from @jhb to sync with his latest "ktls_nic_tls_rx2" branch as of now.

Sorry, missed this one earlier.

Ping .

• Implement crypto state as enum (as suggested by Gleb)
• Remove an unused variable
• Rebased patch.

Protect from concurrent ioctls, and rebase on latest main branch

Rebase patch after @jhb latest crypto additions.

Manual page LGTM as well, English-wise. Can't speak for the rest or for consistency.

For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail.

I'm going to have to sleep on the approach. This is a known escape, but I don't know if the method used can fully plug it. For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail. As is it does solve it for processes which have no way to talk to each other apart from a partially shared fs though.