[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-net
Subject:    Use of pktq_barrier() in if_detach()
From:       Jason Thorpe <thorpej () me ! com>
Date:       2022-08-30 15:49:03
Message-ID: 695C4996-C54D-4E64-B06E-B850A4D9622E () me ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic