[libvirt] two nasty races

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130520/3b4b7c9f/attachment-0001.sig>