Re: [PATCH] network: Fix a race condition when shutdown & start vm at the same time

On 6/19/20 12:26 PM, Daniel P. Berrangé wrote: > Maintain a global "int nextTapID" counter, and just iterate on this. > NIC names can be upto 16 bytes, so we'll create billions of devices > before we have any chance of wrapping around and risking a collision > with a concurrently shutting down guest. I remember I tried doing a monotonically increasing "next" counter for macvtap (never actually pushed, but shown to [some users, I forget who, maybe ovirt devs?], and they didn't like it because the devices ended up with long difficult-for-a-human-to-remember/pick-out/recite names like macvtap42301 and macvtap43021. So instead we keep track of the names that are in use, and always look for the lowest available number when creating a new one. (of course doing that would greatly increase the likelyhood of exposing any race conditions, so...) Definitely if we change the behavior in this way we're going to hear about it, though :-)

Another issue I remember from macvtap is the possibility of a different process (not libvirt) having already created a macvtap device with the name that we are wanting to use. That is easily solved in the case of macvtap by just iterating through until we find one that we can create without failure. So basically you have the list/bitmap/whatever of devicenames currently in use, use that as a starting point to pick a name for the new device, but then also allow for that name to already be used, and retry.

Also, in the name of backward compatibility, we will need to support tap device names from the config that have %d in the name, e.g. the default name we send is "vnet%d", but we allow for someone to specify "mytap%d".