tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Use of pktq_barrier() in if_detach()
When a network interface is detached from the system, one of the main tasks that must be performed is the removal of any dangling references to the interface that might be lingering, either in the routing table, the various protocol data structures, or in the protocol input packet queues. For the purposes of this discussion, I’ll ignore the routing tables.
For the protocol data structures that might have references, we call pr_purgeif() for any protocol marked PR_PURGEIF. Afterwards, we deal with the protocol input packet queues.
For packet queues, we currently have 2 flavors … the traditional ifqueue protocol queues and the modern pktqueue protocol queues.
For the traditional ifqueue type, we call if_detach_queues() for each input queue listed by the domain. This function runs through the queues, looking for packets that reference the detaching interface, and removes (and frees) them.
For the modern pktqueue type, we call pktq_barrier(). pktq_barrier() works differently. What it does is ensure that all packets in the queue before the call to pktq_barrier() have been processed before pktq_barrier() returns. Combined with “no new packets arrive on detaching interfaces”, we can be sure that the queue no longer references the detaching interface.
The problem, though, is that processing these packets might cause the PR_PURGEIF protocols to take additional references to the interface.
I think the right order is to clear out the packet queues **before** dealing with PR_PURGEIF. This would ensure that there is no way for the protocol to take additional references on the interface after PR_PURGEIF has been called.
Thoughts?
-- thorpej
Home |
Main Index |
Thread Index |
Old Index