[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] two nasty races

On Mon, May 20, 2013 at 10:09:20AM -0600, Eric Blake wrote:
> 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.

No, i mean that the code does

    pids = read(tasks file in old group)
    write(pids, tasks file in new group)

In between step 1 and 2, more tasks can have been added to the
old group. So you'll not have moved everything out of the old
group when you're done.

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]