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
