[libvirt PATCH 2/3] util: assign macvtap names using a monotonically increasing integer

[Michal Privoznik]

On 8/24/20 6:23 AM, Laine Stump wrote:
> There have been some reports that, due to libvirt always trying to
> assign the lowest numbered macvtap / tap device name possible, a new
> guest would sometimes be started using the same tap device name as
> previously used by another guest that is in the process of being destroyed *as the new guest is starting.

Realign please :-)

> 
> In some cases this has led to, for example, the old guest's
> qemuProcessStop() code deleting a port from an OVS switch that had
> just been re-added by the new guest (because the port name is based on
> only the device name using the port). Similar problems can happen (and
> I believe have) with nwfilter rules and bandwidth rules (which are
> both instantiated based on the name of the tap device).
> 
> A couple patches have been previously proposed to change the ordering
> of startup and shutdown processing, or to put a mutex around
> everything related to the tap/macvtap device name usage, but in the
> end no matter what you do there will still be possible holes, because
> the device could be deleted outside libvirt's control (for example,
> regular tap devices are automatically deleted when the qemu process
> terminates, and that isn't always initiated by libvirt but could
> instead happen completely asynchronously - libvirt then has no control
> over the ordering of shutdown operations, and no opportunity to
> protect it with a mutex.)
> 
> But this only happens if a new device is created at the same time as
> one is being deleted. We can effectively eliminate the chance of this
> happening if we end the practice of always looking for the lowest
> numbered available device name, and instead just keep an integer that
> is incremented each time we need a new device name. At some point it
> will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
> character limit if nothing else), and we can't guarantee that the new
> name really will be the *least* recently used name, but "math"
> suggests that it will be *much* less common that we'll try to re-use
> the *most* recently used name.
> 
> This patch implements such a counter for macvtap/macvlan only. It does
> it on top of the existing "ID reservation" system (I'm thinking about
> making a followup that gets rid of the bitmap, as it's now overkill
> and just serves to make the code more confusing).
> 
> Signed-off-by: Laine Stump <laine at redhat.com>
> ---
>   src/util/virnetdevmacvlan.c | 67 +++++++++++++++++++++++++++----------
>   1 file changed, 50 insertions(+), 17 deletions(-)

Michal