From: Paolo Bonzini <pbonzini@redhat.com>
To: Michal Privoznik <mprivozn@redhat.com>,
Jie Wang <wangjie88@huawei.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: eric.fangyi@huawei.com
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] pr-manager-helper: fix pr process been killed when reconectting
Date: Thu, 30 May 2019 12:59:05 +0200 [thread overview]
Message-ID: <b8a358ee-eb1f-14ca-b406-295ef668bb55@redhat.com> (raw)
In-Reply-To: <f9b6dd9e-3e58-add9-c5ab-da1a883a0a4b@redhat.com>
On 30/05/19 12:08, Michal Privoznik wrote:
>>> 1) Try to acquire (lock) pidfile
>>> 2) unlink(socket)
>>> 3) spawn pr-helper process (this yields child's PID)
>>> 4) wait some time until socket is created
>>> 5) some follow up work (move child's PID into same cgroup as qemu's main
>>> thread, relabel the socket so that qemu can access it)
>>
>> Note that qemu-pr-helper supports the systemd socket activation
>> protocol. Would it help if libvirt used it?
>
> Thing is, libvirt creates a mount namespace for domains (one namespace
> for one domain). In this namespace a dummy /dev is mounted and only
> nodes that qemu is configured to have are created. For instance, you
> won't see /dev/sda there unless your domain has it as a disk. Then,
> libvirt moves pr-helper process into the same cgroups as the qemu's main
> thread. This is all done so that pr-helper has the same view of the
> system as qemu. I don't think that he same result can be achieved using
> socket activation.
Why? The only difference with "normal" behavior and socket activation
is who creates the socket and calls listen() on it. Everything else is
entirely the same.
> Also, libvirt spawns one pr-helper per domain (so that the socket can be
> private and share seclabel with qemu process it's attached to).
Yes, that is why I thought the socket could be moved in advance to the
right security label, prior to exec. Also, perhaps could the child move
itself to the right cgroup before dropping privileges. This would
remove the window between 3 and 5, by moving all the work *before*
qemu-pr-helper is exec-ed.
Paolo
next prev parent reply other threads:[~2019-05-30 10:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-28 13:06 [Qemu-devel] [PATCH] pr-manager-helper: fix pr process been killed when reconectting Jie Wang
2019-05-28 17:45 ` [Qemu-devel] [Qemu-block] " Paolo Bonzini
2019-05-29 7:33 ` Michal Privoznik
2019-05-29 8:37 ` Jie Wang
2019-05-29 9:37 ` Paolo Bonzini
2019-05-29 9:34 ` Paolo Bonzini
2019-05-30 10:08 ` Michal Privoznik
2019-05-30 10:59 ` Paolo Bonzini [this message]
2019-06-11 13:51 ` wangjie (P)
2019-06-11 14:46 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8a358ee-eb1f-14ca-b406-295ef668bb55@redhat.com \
--to=pbonzini@redhat.com \
--cc=eric.fangyi@huawei.com \
--cc=mprivozn@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wangjie88@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).