Probably longer-term we would want to use (more lightweight) process threads per https://reviews.freebsd.org/D39180.
To fix this one specifically I'd probably try to set curtread creds during the thread setup: https://github.com/freebsd/freebsd-src/blob/80726c2257e9d6d79341aac65ba22987f53619bc/sys/netlink/netlink_io.c#L149
df

All good, just a note (mostly to myself) on error handling and atomicity. What we do here (myself included) is sequence on priv-check & execute calls, where we stop abruptly half-way if we lack privilege for 1 out of 10 changes. The outcome (e.g. partial change) is now dependent on the block order inside the function.
What we should do instead is either try to move towards more atomicity (checking all privileges in the beginning and failing) or more overall completion (e.g. don't stop on the first failure), which is harder reporting-wise.
Generally I'd prefer the former approach. I don't think we need to change it here, I'd rather have a separate diff reshuffling error handling approach.

In D51238#1170774, @ivy wrote:

i don't think we can be compatible with Linux due to semantic differences. to take two examples i noticed, their version of VLAN filtering says if it's disabled, the bridge won't process VLANs at all, but our bridge does (it just doesn't filter them), and their vlan protocol mode (802.1q/802.1ad) seems to be for the bridge as a whole, while ours is per-interface.

i think trying to match the Linux API might just end up being more confusing, since it'll appear to work but actually not work in subtle ways.

Thank you for working on that!

Thank you for working on this! Can we add tests here?

Thank you for woking on this!
I agree with Gleb - the root cause here is struct afdata lifecycle and it has to be dealt with.
The code cleanup in the diff LGTM - added a couple of comments.

LGTM, thank you!

LGTM but let’s update the man page as well :-)

Apologies for the delay

Generally LGTM, with the nit around NHF_BROADCAST

Generally LGTM

Let’s make sure that the constants /macro still has the same type as in Linux and check that, for example, net/bird2 compiles without additional warnings after this change

In D47384#1080729, @markj wrote:

In fact, this probably does not go far enough. I'm not sure when it's useful to change the fibnum of a socket after creation time, but it's dangerous in general since the fibnum is also inherited by the inpcb.

What about multi-fib-aware applications? For example, nginx allows to specify a specific fib for each listening socket.

I'm going to come up with a different version of this patch (likely using a new flag rtmsg->rtm_flags to signal RTM_F_FORCE) in a day or two. The current version allows all netlink customers to fully bypass PINNED route protection, which defeats its purpose.

Netlink support has been added, should not be an issue anymore

Thank you for working on this!
Could you please add the patch with context & add a corresponding test?
Thank you!

Ty for working on that! IIRC the idea of rib_decompose_notification was to provide the same handling for both multipath and non-multipath routes for the callers that care only about specific paths. I'd rather add the relevant callback to the rib_decompose_notification() and not touch nd6_subscription_cb code.

Got it. From my pov we're now requiring explicit mental effort (and knowledge) that each field now comes with a bit, and field mutations may need flag updates. Often after some time it ends up with flags not being consistent, leading to hard-to-debug errors..
I don't have a _strong_ opinion on this, so won't object to the current version - and hope there won't be 'I told you so' situation in a year :-)

LGTM, q - would it be possible to introduce ‘ip6po_<set|clear>_<field>’ inline functions and use them so we don’t accidentally miss setting/clearing up the relevant bit?

I’ a bit unsure about this one - as having pointer to bool may introduce

I agree we should rootcase the case. However - why do we need to perform these conditional checks everywhere?
Why can’t t_cc refer to the dummy cc structure? Why can’t the non-implemented/non-needed function point to no-op functions?

Thank you for submitting the patch. I’m not sure I fully understand the problem and the solution.
Could you please provide some examples?

Thank you for updating the interface to netlink!
Generally LGTM, the only concern I have is about using sockaddrs inside netlink..

Thank you for adding it! It's certainly nice to have an integrated solution for PF. Conceptually I'm all up for it.
For the control path implementation I'll second Glebius concern - it's pretty ugly to build a cloner, a bunch of interfaces to allow to use (non-extendable) interface ioctls..
I'd really suggest doing gentlink family with CREATE|UPDATE/DELETE/GET interface, which will be easily extendable. It may even be less code that it is now.

Thanks for working on the idea of improving tests parallelism!
Conceptually I like the idea of auto-jailing, but the details matter :-)
Jails deal nicely with removing some tests-running side-effects, but not all.
Filesystem “virtualization” as well as network “virtualization” has to be set up explicitly to actually provide isolation for the respective tests.

I’d rather avoid doing that. ntohs is fast and branchless, so I’d vote for optimizing for readability here (unless there is a measurable performance gain)

In D42170#962312, @imp wrote:

opt_global.h is ok. Opt_proto just moves th problem.

But we actually have it for inet/inet6 as well. I ran into the similar issues many times..

In D42170#962271, @kp wrote:

Should we do the include in the headers that directly need it instead? That'd be at least netlink_ctl.h, netlink_message_writer.h and route/route_var.h.

This seem a bit contrary to the approach used in the other parts of the kernel. If really want to switch the pattern, I’d ether vote for opt_proto ( or opt_global.h)

In D42170#962265, @markj wrote:

In D42170#962264, @markj wrote:

One caveat of this approach is that netlink/netlink.h has to be included before all headers which might expect NETLINK to be defined. For instance, it'll be a bug for .c files to include netlink.h after netlink_ctl.h. Maybe the solution there is to make netlink_ctl.h include opt_netlink.h as well, I'm not sure.

Another solution is to just define NETLINK in opt_global.h. I've never found having separate option headers to be useful.

I was thinking in a similar way, having opt_proto.h which contains defines for INET, INET6 and NETLINK, so a whole variety of errors would be eliminated..