Re: [libvirt] [PATCH v2 7/7] qemu_security: Lock metadata while relabelling
On 08/23/2018 05:51 PM, Daniel P. Berrangé wrote:
On Thu, Aug 23, 2018 at 05:45:42PM +0200, Michal Privoznik wrote:
> On 08/23/2018 05:01 PM, Daniel P. Berrangé wrote:
>> On Thu, Aug 23, 2018 at 04:54:01PM +0200, Michal Privoznik wrote:
>>> On 08/20/2018 07:17 PM, Michal Prívozník wrote:
>>>> On 08/20/2018 05:16 PM, Daniel P. Berrangé wrote:
>>>>> On Tue, Aug 14, 2018 at 01:19:43PM +0200, Michal Privoznik wrote:
>>>>>> Fortunately, we have qemu wrappers so it's sufficient to put
>>>>>> lock/unlock call only there.
>>>>>>
>>>>>> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
>>>>>> ---
>>>>>> src/qemu/qemu_security.c | 107
+++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 107 insertions(+)
>>>>>>
>>>
>>>
Oh right, yes, that kills the idea of using a WAIT flag for lockspaces,
unless we want to introduce threads ingto virtlockd, but we can't do
that because Linux has totally fubard locking across execve() :-(
But we need WAIT. I guess we do not want to do:
lockForMetadata(const char *path) {
int retries;
while (retries) {
rc = try_lock(path, wait=false);
if (!rc) break;
if (errno = EAGAIN && retries--) {sleep(.1); continue;}
errorOut();
}
}
However, if we make sure that virtlockd never forks() nor execs() we
have nothing to fear about. Or am I missing something? And to be 100%
sure we can always provide dummy impl for fork() + execve() in
src/locking/lock_daemon.c which fails everytime.
Michal