On 05/20/2013 03:26 AM, Daniel P. Berrange wrote: > It is worse than that - you can't simply ignore ESRCH. In the same way > that existing processes can exit, new processes can come into live. > The virCgroupMoveTask method doesn't take any of this into account. > Are you talking about the potential for reusing a pid? Remember, cgroups is Linux only, and on Linux, we know the kernel behavior - pids (well, really thread ids) are assigned sequentially to the next available opening, and reusing a tid requires cycling through the entire pid space, something that can't happen in a short amount of time. The problem of pid recycling is more prevalent on other systems, like mingw, where pids are not assigned sequentially, and really can be reused the very next instruction after a previous process pid has been reclaimed. But since we know Linux does not have that behavior, is it really a problem for us? Ignoring ESRCH will solve the problem of a thread that dies between read and write, but like you said, won't solve the problem between a thread being created between read and write. For that, you'd have to repeatedly read the source file until it is empty. > The real problem is that we should not be trying to move QEMU after it > has been started - we should aim to get it into the right place right > away. > It would also be nice if the kernel would allow a rename(old, new) as a way to atomically move a group of thread ids between two cgroups, instead of forcing us to use the racy read/write interfaces. But I don't know enough about kernel development to even know where to propose this idea. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list