I think that if_maddr_rlock + accessing list head on ifnet is just a plain wrong KPI. The if_maddr_count+if_maddr_array is a bit better, but requires to allocate memory, while usually being used in a context where we can't wait.
Tue, Jun 25
Jun 4 2019
May 29 2019
May 24 2019
May 16 2019
I also see that as contrary to intent of epoch.
May 10 2019
May 8 2019
Apr 16 2019
Bjoern, you comment can be reduced to "Packets can be lost anywhere... so let's just drop them instead of further complicating reassembly code". :(
You didn't convince me guys. Can you please elaborate why removal of an interface should free packets that once came through this interface? Packet has arrived all the way to its last bit, it is legitimate packet. If you think it should be freed, then why are we flushing only fragment reassembly queues? Why don't flush TCP reassembly queues, socket buffers? Ah, we don't usually dereference m_pkthdr.rcvif for these kinds of queues, right, so we don't panic.
Apr 15 2019
Sorry, I withdraw my approval. The more I think about this, the more I dislike it. What the patch does - it fixes the panic in a most straightforward way. But let's look at it from standpoint of network engineer, not kernel developer.
Although I still think that the problem of departing ifnets and queued/in-flight mbufs should be solved in a generic way, I'm fine with this patch. It closes one case out of many, but in non-disruptive way.
Apr 10 2019
Yes, as a separate change.
Apr 9 2019
Apr 4 2019
- Remove spare, since nh_ia was added.
Apr 3 2019
- Copy RTF_HOST to NHF_HOST.
- Export in_ifaddr as nh_ia. This allows to fix ifa packets/bytes accounting
More comments & fix a bug with broadcast.
After I spent sometime around this code, I support melifaro@'s suggestion.
Apr 2 2019
Mar 25 2019
Mar 21 2019
I think that while in flight problem can be fixed with epoch, the queueing problem should be fixed in a radical way - do not store mbufs with rcvif in reassembly queues. Just grab the ND_IFINFO(m->m_pkthdr.rcvif)->chlim or whatever you need before putting buffer on queue.
I absolutely agree with Bjoern. This is fix for just one particular case of problem that an interface goes away and mbufs pointing at it with m_pkthdr.rcvif are still queued, or worse - in flight. This problem needs to be addressed as a whole.
Mar 17 2019
Mar 15 2019
Mar 14 2019
Mar 13 2019
Update to cover panics discovered by pf test suite.
Mar 12 2019
- Use existing difference between ip and eh pointers to calculate
Mar 11 2019
Style - no functional change.
Parse VLAN headers.
Optionally use m->m_pkthdr.rcvif for iif on output packets.
Rebase since some changes are already in head.
Mar 10 2019
Mar 3 2019
Feb 25 2019
Feb 23 2019
Feb 21 2019
- In pfi_initialize_vnet() rely on IFNET_RLOCK() which is sx(9) for stability of ifnet and ifgroup lists. First allocate enough pfi_kif structs, then enter epoch and attach them.
- pfi_get_ifaces() NET_EPOCH_ENTER since pfi_skip_if() traverses ifgroup list.
Feb 20 2019
Feb 18 2019
Feb 15 2019
Feb 11 2019
The plan is to not be in epoch during full ifattach/ifclone event since these events have many places that allocate memory. Needs to be more fine grained. I'll ponder more over that.
- Enter epoch in DAD timer.
- Revert entering epoch for setsockopt. This needs to be fine grained.
Feb 9 2019
Feb 8 2019
Feb 7 2019
Feb 3 2019
Feb 2 2019
Feb 1 2019
Jan 31 2019
- Remove "all rights reserved" from new files.
- Obsolete MLINKS.
- My copyrights.
- Address ae@ review, fix multiple mismerges and bugs in ip_fw_pfil.
- Set max names length to MAXPFILNAME equal to 64.
- Go through all pfil_run_hooks() and properly compare against PFIL_PASS
Jan 29 2019
Did you happen to do any benchmarking on this? I'd have expected "Sync pfil hooks epoch(9)" to give us a (small) performance improvement, but my initial test shows a small reduction in forwarding performance (with pf loaded).
- Improve wording. 
- Fix two .Nd present. Since mdoc(7) says that .Nd doesn't accept
- Create /dev/pfil only for the default VNET.
- Corrections from Mateusz.
- mandoc -T lint
This panics during the netipsec and pf regression tests:
Jan 25 2019
Jan 24 2019
- Remove sbytes from the API.
To be clear, this approach induces a certain amount of pain, and it should not be undertaken unless the benefits are worth it. Some justification based on actual users of sendfile() is needed. If it's not worth it, then this problem is just a wart.