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
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 potent
On Fri, May 17, 2013 at 10:05:25PM -0600, Eric Blake wrote:
> I found root cause on two nasty races today, but ran out of time to
> write the patches until next week.
>
> 1. We have a TOCTTOU race when moving processes between cgroups.
> virCgroupMoveTask can fail if listing the threads in the par
On 05/17/2013 10:05 PM, Eric Blake wrote:
> I found root cause on two nasty races today, but ran out of time to
> write the patches until next week.
>
>
> 2. We have a (rare) deadlock due to the use of a non-async-signal-safe
> getpwuid_r in between fork and exec.
I was also surprised to learn
I found root cause on two nasty races today, but ran out of time to
write the patches until next week.
1. We have a TOCTTOU race when moving processes between cgroups.
virCgroupMoveTask can fail if listing the threads in the parent group
picks up multiple threads, then one of those threads exits b
