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 > > . >