On 3/19/19 9:49 AM, Michal Privoznik wrote: > If there are two concurrent threads, one of which is removing an > nwfilter from the list and the other is trying to add it back they > may serialize in the following order: > > 1) obj->removing is set and @obj is unlocked. > 2) The tread that's trying to add the nwfilter onto the list locks > the list and tries to find, if the nwfilter already exists. > 3) Our lookup functions say it doesn't, so the thread proceeds to > virHashAddEntry() which fails with 'Duplicate key' error. > > This is obviously not helpful error message at all. > > The problem lies in our lookup function > (virNWFilterBindingObjListFindByPortDevLocked()) which return > NULL even if the object is still on the list. They do this so > that the object is not mistakenly looked up by some API. The fix > consists of moving 'removing' check one level up and thus > allowing virNWFilterBindingObjListAddLocked() to produce > meaningful error message. > > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> - Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
