I also see that as contrary to intent of epoch.

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.

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.

Yes, as a separate change.

• Remove spare, since nh_ia was added.

• 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.

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.

Update to cover panics discovered by pf test suite.

• Use existing difference between ip and eh pointers to calculate

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.

• 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.

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.

Rebase on top of r343619.

• Remove "all rights reserved" from new files.

• Obsolete MLINKS.
• My copyrights.

This is a rebase.

• 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

In D18951#406615, @kristof wrote:

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. [1]
• Fix two .Nd present. Since mdoc(7) says that .Nd doesn't accept

Very happy to see this.

• Create /dev/pfil only for the default VNET.
• Corrections from Mateusz.
• mandoc -T lint
• igor

This panics during the netipsec and pf regression tests:

2. 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.