On Mon, Jul 26, 2010 at 11:12 AM, Kay Sievers kay.siev...@vrfy.org wrote:
On Mon, Jul 26, 2010 at 11:08, Dhaval Giani dhaval.li...@thegianis.in wrote:
On Thu, Jul 22, 2010 at 8:36 PM, Greg KH gre...@suse.de wrote:
On Thu, Jul 22, 2010 at 11:31:07AM -0700, Paul Menage wrote:
On Thu, Jul 22,
Hi John,
Please try the following patch - it should be applied _instead_ of the
patch I sent on 7/20.
The previous patch was still insufficient when the root task has not only
threads, but also a child (the child was a ghost task used temporarily
during restart). I believe this patch
OL diff --git a/kernel/checkpoint/sys.c b/kernel/checkpoint/sys.c
OL index 171c867..c5517c2 100644
OL --- a/kernel/checkpoint/sys.c
OL +++ b/kernel/checkpoint/sys.c
OL @@ -625,8 +625,11 @@ int walk_task_subtree(struct task_struct *root,
OL }
OL /* if we arrive at root
It works for me as well. Thanks for your help Oren.
JP
On Mon, Jul 26, 2010 at 1:11 PM, Dan Smith da...@us.ibm.com wrote:
OL diff --git a/kernel/checkpoint/sys.c b/kernel/checkpoint/sys.c
OL index 171c867..c5517c2 100644
OL --- a/kernel/checkpoint/sys.c
OL +++ b/kernel/checkpoint/sys.c
Great.
Pushed fixes to ckpt-v22-dev.
Oren.
On 07/26/2010 01:56 PM, John Paul Walters wrote:
It works for me as well. Thanks for your help Oren.
JP
On Mon, Jul 26, 2010 at 1:11 PM, Dan Smith da...@us.ibm.com wrote:
OL diff --git a/kernel/checkpoint/sys.c b/kernel/checkpoint/sys.c
user-cr's restart program creates a thread to pipe the checkpoint image
into the sys_restart file descriptor. This is a thread created with
clone(2) and it shares its address space with the coordinator.
While glibc has internal mechanisms to ensure thread safety, these work
only with threads
On Mon, Jul 26, 2010 at 11:13:14AM +0200, Dhaval Giani wrote:
On Mon, Jul 26, 2010 at 11:12 AM, Kay Sievers kay.siev...@vrfy.org wrote:
On Mon, Jul 26, 2010 at 11:08, Dhaval Giani dhaval.li...@thegianis.in
wrote:
On Thu, Jul 22, 2010 at 8:36 PM, Greg KH gre...@suse.de wrote:
On Thu, Jul
On Mon, Jul 26, 2010 at 2:28 PM, Greg KH gre...@suse.de wrote:
Ok, again, after all of this, who is going to be applying this patch to
their tree for the .36 merge window?
There's no specific cgroups tree - cgroups patches generally go via akpm.
Or should I apply it to my driver-core one?
On Mon, Jul 26, 2010 at 02:55:18PM -0700, Paul Menage wrote:
On Mon, Jul 26, 2010 at 2:28 PM, Greg KH gre...@suse.de wrote:
Ok, again, after all of this, who is going to be applying this patch to
their tree for the .36 merge window?
There's no specific cgroups tree - cgroups patches
On Tue, Jul 27, 2010 at 12:05 AM, Greg KH gre...@suse.de wrote:
On Mon, Jul 26, 2010 at 02:55:18PM -0700, Paul Menage wrote:
On Mon, Jul 26, 2010 at 2:28 PM, Greg KH gre...@suse.de wrote:
Ok, again, after all of this, who is going to be applying this patch to
their tree for the .36 merge
On Mon, Jul 26, 2010 at 3:05 PM, Greg KH gre...@suse.de wrote:
Wonderful, can I get some acks from the cgroups maintainers? I'll
gladly take it through my tree.
Sure.
Acked-by: Paul Menage men...@google.com
Paul
___
Containers mailing list
On Tue, Jul 27, 2010 at 12:08:03AM +0200, Dhaval Giani wrote:
On Tue, Jul 27, 2010 at 12:05 AM, Greg KH gre...@suse.de wrote:
On Mon, Jul 26, 2010 at 02:55:18PM -0700, Paul Menage wrote:
On Mon, Jul 26, 2010 at 2:28 PM, Greg KH gre...@suse.de wrote:
Ok, again, after all of this, who is
12 matches
Mail list logo
