On Mon, Mar 09, 2020 at 13:39:56 +0100, Michal Privoznik wrote: > On 3/9/20 10:18 AM, Peter Krempa wrote: > > On Mon, Mar 09, 2020 at 09:29:43 +0100, Michal Privoznik wrote: > > > When preparing images for block jobs we modify their seclabels so > > > that QEMU can open them. However, as mentioned in the previous > > > commit, secdrivers base some it their decisions whether the image > > > they are working on is top of of the backing chain. Fortunately, > > > in places where we call secdrivers we know this and the > > > information can be passed to secdrivers. > > > > > > The problem is the following: after the first blockcommit from > > > the base to one of the parents the XATTRs on the base image are > > > not cleared and therefore the second attempt to do another > > > blockcommit fails. This is caused by blockcommit code calling > > > qemuSecuritySetImageLabel() over the base image, possibly > > > multiple times (to ensure RW/RO access). A naive fix would be to > > > call the restore function. But this is not possible, because that > > > would deny QEMU the access to the base image. Fortunately, we > > > can use the fact that seclabels are remembered only for the top > > > of the backing chain and not for the rest of the backing chain. > > > And thanks to the previous commit we can tell secdrivers which > > > images are top of the backing chain. > > > > > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1803551 > > > > > > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > > > --- > > > > Once you fix all of the wrong variable name in this patch as well as in > > the previous one: > > Does isParentChainTop sound good for the variable name? IMO isChainTop should be enough.
