[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [PATCH] pr-manager-helper: fix pr process
From: |
Jie Wang |
Subject: |
Re: [Qemu-devel] [Qemu-block] [PATCH] pr-manager-helper: fix pr process been killed when reconectting |
Date: |
Wed, 29 May 2019 16:37:55 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 |
Hi, Paolo and Michal:
Let me add some details about this problem.
reappear steps:
1. in Host, execute the following command many times quickly:
"ps aux|grep helper|grep -v grep|grep -v qemu-kvm|awk '{print $2}';ps aux|grep
helper|grep -v grep|grep -v qemu-kvm|awk '{print $2}'|xargs -n1 kill -9"
2. at the same time , execute PR command continuously in Guest
just execute step 1 and 2 for a moment, the problem will appear.
when the problem appeared:
1. qemu will initialize pr-helper and connect to it cyclically, but always
failed because no running pr-helper process to connect.
2. libvirt will always waiting for connected event, but will never to start new
pr-helper process because not receive disconnect event.
I'm not found the best way to solve this problem, can you give me some
suggestion?
On 2019/5/29 15:33, Michal Privoznik wrote:
> On 5/28/19 7:45 PM, Paolo Bonzini wrote:
>> On 28/05/19 15:06, Jie Wang wrote:
>>> if pr-helper been killed and qemu send disconnect event to libvirt
>>> and libvirt started a new pr-helper process, the new pr-heleper
>>> been killed again when qemu is connectting to the new pr-helper,
>>> qemu will never send disconnect to libvirt, and libvirt will never
>>> receive connected event.
>>
>> I think this would let a guest "spam" events just by sending a lot PR
>> commands. Also, as you said, in this case QEMU has never sent a
>> "connected" event, so I'm not sure why it should send a disconnection event.
>
> So pr manager is initialized on the first PR command and not when qemu is
> starting?
>
> If a user inside the guest could somehow kill pr-helper process in the host
> then yes, they could spam libvirt/qemu. But if a user from inside a guest can
> kill a process in the host that is much bigger problem than spaming libvirt.
>
>>
>> Does libvirt monitor at all the pr-helper to check if it dies? Or does
>> it rely exclusively on QEMU's events?
>
> Libvirt relies solely on QEMU's events. Just like with qemu process itself,
> libvirt can't rely on SIGCHILD because the daemon might be restarted which
> would reparent all qemu and pr-helper processes rendering libvirt wait for
> SIGCHILD useless.
>
> But there is an exception to this: when libvirt is spawning pr-helper it does
> so by following these steps:
>
> 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)
>
> If any of these steps fails then child is killed. However, the PID is not
> recorded anywhere and thus is forgotten once control jumps out of the
> function.
>
> Michal
>
> .
>