[PATCH] network: Introduce mutex for bridge name generation

Erik Skultety eskultet at redhat.com
Fri Jan 8 07:28:28 UTC 2021


On Thu, Jan 07, 2021 at 07:33:38PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 1/7/21 5:22 PM, Ján Tomko wrote:
> > On a Thursday in 2021, Laine Stump wrote:
> > > On 1/7/21 10:09 AM, Michal Privoznik wrote:
> > > > When defining/creating a network the bridge name may be filled in
> > > > automatically by libvirt (if none provided in the input XML or
> > > > the one provided is a pattern, e.g. "virbr%d"). During the
> > > > bridge name generation process a candidate name is generated
> > > > which is then checked with the rest of already defined/running
> > > > networks for collisions.
> > > > 
> > > > Problem is, that there is no mutex guarding this critical section
> > > > and thus if two threads line up so that they both generate the
> > > > same candidate they won't find any collision and the same name is
> > > > then stored.
> > > > 
> > > > Closes: https://gitlab.com/libvirt/libvirt/-/issues/78
> > > 
> > > 
> > > "Closes:"? I'm guessing other people have also been using this tag to get gitlab to automatically close PRs and I just haven't noticed it until now, but according to this page:
> > > 
> > > https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues
> > > 
> > > "Resolves:" also works, and is a tag that has already been used quite a bit in libvirt in the past.
> > > 
> > 
> > Even for GitLab issues, Resolves is slightly winning at 7 vs 5.
> 
> 
> I'm using 'Resolves: <gitlab bug link>' because I saw someone else doing
> it. I thought that the reasoning behind it is that 'Resolves' is when you
> want to say that 'this fixes the following bug entry', which differs from
> 'Fixes', which is used generally in the format 'Fixes: <commit>' to indicate
> that it's an amend of another commit.

Oops, I just used Fixes: with an issue link and gitlab happily ate it as well
and closed the issue.

Erik




More information about the libvir-list mailing list