• Fixup missing bif_chkdir method for radiotap.

In D53871#1239268, @zlei wrote:

I uploaded the patch to https://reviews.freebsd.org/F139754092 . I might miss some drivers but that should be almost completed. While working on this, I'm not fully convinced this is a good approach. I'd argue the bpf part is too tightly coupled with the net epoch.

In D53871#1238332, @zlei wrote:

Indeed I have WIP to remove NET_EPOCH_ENTER / NET_EPOCH_EXIT from bpf.c and that is almost identical to your work. Well I must admit that I never finished it as there' re too many places to check manual.

$ grep -Er 'BPF_[M]?TAP|bpf_[m]?tap' sys
.... lots of drivers

I'll try to find them all and send you a patch.

@zlei thanks for all these findings! It seems that at least few of them were violating epoch even before the suggested bpf change. Are you going to commit the fixes? I can help. To me some of these fixes do not look related to bpf at all.

The patch as is definitely brings correct behavior. But, IMHO, we should try to propagate the cred change as deeper in the call stack as possible. It seems trivial while we are withing netlink, as nlp carries correct cred. But once we go from netlink to if_clone.c, we lose it. Let's hear from @melifaro

There're other consumers of ifnet_arrival_event. I'm a little worried that they may expect a fully constructed ifnet, i.e. consumers see that the if_inet and if_inet6 are also initialized.

In D54175#1237696, @markj wrote:

That's what I thought, but other software ifnet implementations I looked at (gif, wg, bridge, epair) all seem to behave like this.

In D54175#1237688, @markj wrote:

So, if we want MOD_UNLOAD to autodestruct all if_ovpn interfaces, I think the current approach makes sense. Probably this should share code with ovpn_prison_remove().

• Documentation and ipfw(8) update.

• Documentation and rc(8) update.

I'd like to push D53870 through D53877 this week. More review is appreciated.

Looks correct! Thanks. What did happen before? This command failed?

No objection.

• Make the netlink_writer cookie an honest const ifnet pointer.
• Refactor some code to provide the new constness constraint.

• Address the fact that many rules can have the same number.
• Support 32-bit rule numbers.

• Rebase + unsignigicant changes.

• Address USB.

The d_promisc appears to be locked by the global BPF_LOCK(). Thus, remove it
from this changes. This addresses Mark's comments.

My understanding. First, qsort() itself never passes NULL pointer. Second, could a map[] entry within p->pm_count be NULL or not? The new code assumes it can't be. Then we also have a case with lacp_port that has NULL lp_ifp, which is covered.

If pointers in the map[] can be NULL, then you removed too much, didn't you?

• Apply Mark's suggestion

AFAIU, when arptimer() finds entry in state ARP_LLINFO_REACHABLE it gives it arp_rexmit time (1 second) to get feedback from the forwarding path and sets its state to ARP_LLINFO_VERIFY. In 1 second if feedback was collected, it will issue arprequest(). My concern is that the jitter is bigger than 1 second. I could be wrong, and my concern is erroneous. I just wanted to make sure that this specific behavior is checked to persist. I don't think we have a regression test for it.