В Чт, 18/06/2015 в 21:26 +0300, Cyrill Gorcunov пишет:
On Tue, Jun 16, 2015 at 07:51:52PM +0300, Cyrill Gorcunov wrote:
If we have any problems because of this, the solution is good.
OK. Gimme sometime (util tomorrow probably) to think of. This issue
not critical at the moment
On Fri, Jun 19, 2015 at 01:15:31PM +0300, Kirill Tkhai wrote:
Ok, I have no objections. The only thing is we need to carefully
use direct task_ve in the future. All current place, where we use
it, are safe.
Sure. I'll prepare the patch once time permit.
On Tue, Jun 16, 2015 at 07:51:52PM +0300, Cyrill Gorcunov wrote:
If we have any problems because of this, the solution is good.
OK. Gimme sometime (util tomorrow probably) to think of. This issue
not critical at the moment because we know that we're moving one
task only (from vzctl). So
On Tue, Jun 16, 2015 at 06:19:44PM +0300, Kirill Tkhai wrote:
This patch brings a couple of problems. The first one is if we're setting
a ve cgroup for a forking task, it's possible the parent and the child
fall into different cgroups. For example, parent is inside CT, while
child is in ve0.
Hm. How about stop_machine?
Bad idea.
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
В Вт, 16/06/2015 в 19:07 +0300, Cyrill Gorcunov пишет:
On Tue, Jun 16, 2015 at 06:19:44PM +0300, Kirill Tkhai wrote:
This patch brings a couple of problems. The first one is if we're setting
a ve cgroup for a forking task, it's possible the parent and the child
fall into different
В Чт, 14/05/2015 в 19:52 +0300, Cyrill Gorcunov пишет:
In vzctl/libvzctl bundle we restore container like
- create ve/$ctid cgroup
- move self into this cgroup
- run criu from inside
So that kernel code passes ve_can_attach test. In turn for
our P.Haul project (which is managing live
On Tue, Jun 16, 2015 at 06:19:44PM +0300, Kirill Tkhai wrote:
This patch brings a couple of problems. The first one is if we're setting
a ve cgroup for a forking task, it's possible the parent and the child
fall into different cgroups. For example, parent is inside CT, while
child is in ve0.
On Tue, Jun 16, 2015 at 07:25:48PM +0300, Kirill Tkhai wrote:
May not we simply add into ve cgroup?
.can_attach
...
spin_lock(task-sighand-siglock);
.cance_attach
...
spin_unlock(task-sighand-siglock);
.attach
...
spin_unlock(task-sighand-siglock);
В Вт, 16/06/2015 в 19:36 +0300, Cyrill Gorcunov пишет:
On Tue, Jun 16, 2015 at 07:25:48PM +0300, Kirill Tkhai wrote:
May not we simply add into ve cgroup?
.can_attach
...
spin_lock(task-sighand-siglock);
.cance_attach
...
spin_unlock(task-sighand-siglock);
On Tue, Jun 16, 2015 at 07:44:08PM +0300, Kirill Tkhai wrote:
We gonna move only one task in container start time so I think
this is not critical in timing.
As to #2 -- yes, I think rcu-readlock with sync should do the trick.
Also I need to check in details what Vladimir suggested,
On 05/14/2015 07:52 PM, Cyrill Gorcunov wrote:
In vzctl/libvzctl bundle we restore container like
- create ve/$ctid cgroup
- move self into this cgroup
- run criu from inside
So that kernel code passes ve_can_attach test. In turn for
our P.Haul project (which is managing live
In vzctl/libvzctl bundle we restore container like
- create ve/$ctid cgroup
- move self into this cgroup
- run criu from inside
So that kernel code passes ve_can_attach test. In turn for
our P.Haul project (which is managing live migration) the
situation is different -- it opens ve/$ctid but
13 matches
Mail list logo
