| 156322384789_532260007483 | Oren Laadan |
|
From: Nathan Lynch <ntl@xxxxxxxxx
A checkpointed task image may specify a value for the DABR (Data
Access Breakpoint Register). The restart code needs to validate this
value before making any c |
|
| |
| 178925654526_531060007288 | Li Zefan |
|
From: Dan Smith <danms@xxxxxxxxxx
Implement the s390 arch-specific checkpoint/restart helpers. This
is on top of Oren Laadans c/r code.
With these, I am able to checkpoint and restart simple p |
|
| |
| 125420674804_581060007646 | Li Zefan |
|
From: Dan Smith <danms@xxxxxxxxxx
Implement the s390 arch-specific checkpoint/restart helpers. This
is on top of Oren Laadans c/r code.
With these, I am able to checkpoint and restart simple p |
|
| |
| 103324084598_583360007440 | Andrew Morton |
|
Quoting Li Zefan (lizf@xxxxxxxxxxxxxx):
While walking through the whitelist, if the DEV_ALL item is found,
no more check is needed.
Right, because the DEV_ALL item always has all permissions.
|
|
| |
| 192921504959_595260007956 | Andrew Morton |
|
Quoting Li Zefan (lizf@xxxxxxxxxxxxxx):
While walking through the whitelist, if the DEV_ALL item is found,
no more check is needed.
Right, because the DEV_ALL item always has all permissions.
|
|
| |
| 168424184193_547260007190 | Chris R Jones |
|
Andrew Morton wrote:
On Tue, 07 Apr 2009 13:47:16 +0800
Li Zefan <lizf@xxxxxxxxxxxxxx wrote:
While walking through the whitelist, if the DEV_ALL item is found,
no more check is neede |
|
| |
| 195525294755_548160007021 | Chris R Jones |
|
Andrew Morton wrote:
On Tue, 07 Apr 2009 13:47:16 +0800
Li Zefan <lizf@xxxxxxxxxxxxxx wrote:
While walking through the whitelist, if the DEV_ALL item is found,
no more check is neede |
|
| |
| 177020944088_557360007001 | Serge E Hallyn |
|
Quoting Chris R. Jones (chris@xxxxxxxxxxxxx):
One more question for the experts:
Is there any roadmap out there for when we can see containers support in
kernels for the major distributions |
|
| |
| 121929374409_581760007663 | Serge E Hallyn |
|
Quoting Chris R. Jones (chris@xxxxxxxxxxxxx):
One more question for the experts:
Is there any roadmap out there for when we can see containers support in
kernels for the major distributions |
|
| |
| 125726984813_521660007668 | Serge E Hallyn |
|
On s390, all tasks have READ_IMPLIES_EXEC set in current- personality,
which causes the restart process to map things like the stack and heap as
executable. During the restart process, remove this b |
|
| |
| 117123324086_536560007827 | Serge E Hallyn |
|
On s390, all tasks have READ_IMPLIES_EXEC set in current- personality,
which causes the restart process to map things like the stack and heap as
executable. During the restart process, remove this b |
|
| |
| 155527604356_531060007195 | Oren Laadan |
|
Serge E. Hallyn wrote:
Quoting Dan Smith (danms@xxxxxxxxxx):
On s390, all tasks have READ_IMPLIES_EXEC set in current- personality,
which causes the restart process to map things like the s |
|
| |
| 133120104289_542060007193 | Oren Laadan |
|
Serge E. Hallyn wrote:
Quoting Dan Smith (danms@xxxxxxxxxx):
On s390, all tasks have READ_IMPLIES_EXEC set in current- personality,
which causes the restart process to map things like the s |
|
| |
| 142128024130_583060007900 | Oren Laadan |
|
OL In fact, if elsewhere we restore current- personality of the task,
OL then unless we move it to cr_read_mm(), it will overwrite it :(
Should we move it or just remove RIE before we start the re |
|
| |
| 149228774597_530560007246 | Serge E Hallyn |
|
Dan,
Now after the rework of the patchset, its probably a good time
to add support for this.
Im unsure if the personality can affect other restore actions
that take place elsewhere If so, probably |
|
| |
| 197422634579_505960007383 | Ryo Tsuruta |
|
Ok, applied.
Serge E. Hallyn wrote:
Make x86 support depend on it (for now).
Signed-off-by: Serge E. Hallyn <serue@xxxxxxxxxx
---
arch/x86/Kconfig | 1 +
1 files changed, 1 ins |
|
| |
| 188721834143_524260007384 | Sukadev Bhattiprolu |
|
Hi all,
Im pleased to announce that the new dm-ioband RPM package (v1.12.0)
has been released at:
rel="nofollow" sourceforge.net/apps/trac/ioband/wiki/dm-ioband sourceforge.net/apps/trac/iob |
|
| |
| 143828244394_572760007978 | Sukadev Bhattiprolu |
|
Suka,
can you please post the entire test program so I can try to reproduce
it here ?
thanks,
Oren.
Sukadev Bhattiprolu wrote:
Tried this with v14-rc2. This is probably not implemented yet...
|
|
| |
| 192126654780_505060007399 | Sukadev Bhattiprolu |
|
I just posted v14-rc3 which includes the c/r of restart-blocks.
That should improve the situation.
However, depending on which syscalls one uses, process may still
seem "stuck" after rest |
|
| |
| 195129884275_554760007367 | Mark Ryden |
|
Hi,
Sukadev Bhattiprolu wrote:
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
|
| I just posted v14-rc3 which includes the c/r of restart-blocks.
| That should improve the situation.
|
| H |
|
| |
| 179422654631_537260007259 | Mark Ryden |
|
On Wed, Apr 01, 2009 at 01:00:53PM +0300, Mark Ryden wrote:
Hello,
I am back to it and I just want to ask if there are any news with
sysfs tagged directory support patch. Is it merged now ?
|
|
| |
| 175622124442_589960007936 | Oren Laadan |
|
Quoting Mark Ryden (markryde@xxxxxxxxx):
Hello,
I am sorry to hear that it is not merged yet.I hoped to try to start a
project with network namespaces.
Sysfs tagged directories are not support |
|
| |
| 128328934760_567760007003 | Serge E Hallyn |
|
Checkpoint of sysvipc shared memory is performed in two steps: first,
the entire ipc namespace is dumped as a whole by iterating through all
shm objects and dumping the contents of each one. The shme |
|
| |
| 165525404668_543560007162 | Oren Laadan |
|
Serge E. Hallyn wrote:
Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx):
...
int cr_write_ipc(struct cr_ctx *ctx, struct nsproxy *nsproxy)
{
- return 0;
+ return cr_write_ipc_shm(ctx, |
|
| |
| 183425414150_510960007442 | Oren Laadan |
|
During restart, an ipc shared region may have SHM_DEST, indicating
that it has been originally deleted (while still active). In this
case the task of deleting the region after restoring it is postpon |
|
| |
| 147728824707_510760007032 | Oren Laadan |
|
Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx):
-int ipc_addid(struct ipc_ids* ids, struct kern_ipc_perm* new, int size)
+int
+ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int size, i |
|
| |
| 136620094244_580960007699 | Oren Laadan |
|
Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx):
Serge E. Hallyn wrote:
Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx):
-int ipc_addid(struct ipc_ids* ids, struct kern_ipc_perm* new, int si |
|
| |
| 174421914591_550360007210 | Oren Laadan |
|
On Tue, Mar 31, 2009 at 01:32:31AM -0400, Oren Laadan wrote:
Signed-off-by: Oren Laadan <orenl@xxxxxxxxxxxxxxx
The description is empty and this patch is rather pointless without 7/7.
Any reas |
|
| |
| 150625244750_517460007340 | Matt Helsley |
|
Like chekcpoint, restart of sysvipc shared memory is also performed in
two steps: first, the entire ipc namespace is restored as a whole, by
restoring each shm object read from the checkpoint image. |
|
| |
| 133727934882_548760007970 | Dave Hansen |
|
Add a interface to postpone an action until the end of the entire
checkpoint or restart operation. This is useful when during the
scan of tasks an operation cannot be performed in place, to avoid
the |
|
| |
| 192923784851_563660007104 | Oren Laadan |
|
Dave Hansen wrote:
On Tue, 2009-03-31 at 01:32 -0400, Oren Laadan wrote:
Add a interface to postpone an action until the end of the entire
checkpoint or restart operation. This is useful whe |
|
| |
| 166928524114_591360007022 | Oren Laadan |
|
These two are used in the next patch when calling vfs_read/write()
Signed-off-by: Oren Laadan <orenl@xxxxxxxxxxxxxxx
---
fs/read_write.c | 10 ----------
include/linux/fs.h | 10 ++++++++ |
|
| |
| 161124034214_520260007082 | Serge E Hallyn |
|
If ext2/3/4 is compiled as a kernel module, apply this patch to
successfully compile this c/r patchset.
Oren.
diff --git a/checkpoint/ckpt_file.c b/checkpoint/ckpt_file.c
index 0fe68bf..df6bb3d 10 |
|
| |
| 141224134606_516260007565 | Oren Laadan |
|
A minor comment and a nit.
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From d832bfba9a50789fbfadf8486fbdfbd8b498a9ea Mon Sep 17 00:00:00 2001
| From: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx
| Date |
|
| |
| 150329254357_538460007259 | Oren Laadan |
|
A minor comment and a nit.
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From d832bfba9a50789fbfadf8486fbdfbd8b498a9ea Mon Sep 17 00:00:00 2001
| From: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx
| Date |
|
| |
| 135323404637_520460007122 | Oren Laadan |
|
Infrastructure to handle objects that may be shared and referenced by
multiple tasks or other objects, e..g open files, memory address space
etc.
The state of shared objects is saved once. On the fi |
|
| |
| 130926454975_542360007634 | Oren Laadan |
|
Infrastructure to handle objects that may be shared and referenced by
multiple tasks or other objects, e..g open files, memory address space
etc.
The state of shared objects is saved once. On the fi |
|
| |
| 144521694037_566060007945 | Oren Laadan |
|
Create trivial sys_checkpoint and sys_restore system calls. They will
enable to checkpoint and restart an entire container, to and from a
checkpoint image file descriptor.
The syscalls take a file d |
|
| |
| 174227834357_534860007945 | Oren Laadan |
|
Create trivial sys_checkpoint and sys_restore system calls. They will
enable to checkpoint and restart an entire container, to and from a
checkpoint image file descriptor.
The syscalls take a file d |
|
| |
| 191424484870_527060007281 | Oren Laadan |
|
Minor comment:
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From 26e7a012d3ff04d64a59e629f2427dfa2b49792b Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, 30 Mar |
|
| |
| 153021854621_516760007598 | Oren Laadan |
|
Minor comment:
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From 26e7a012d3ff04d64a59e629f2427dfa2b49792b Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, 30 Mar |
|
| |
| 129026984242_526460007800 | Oren Laadan |
|
A few minor comments.
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From 6f0a1dc1db8fdac766b00f90e04e06a5827af459 Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, |
|
| |
| 189925664970_593760007340 | Oren Laadan |
|
A few minor comments.
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From 6f0a1dc1db8fdac766b00f90e04e06a5827af459 Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, |
|
| |
| 188129694123_523860007068 | Oren Laadan |
|
Just a nit:
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From 6f5483b085b1fb675a8445c65ddbeb7b38187865 Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, 30 Mar 2 |
|
| |
| 118322304516_505360007348 | Oren Laadan |
|
Just a nit:
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From 6f5483b085b1fb675a8445c65ddbeb7b38187865 Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, 30 Mar 2 |
|
| |
| 133420304533_595560007923 | Oren Laadan |
|
One comment below.
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From eed3f074ed035c93eb49d05cc1491ee680956906 Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, 30 |
|
| |
| 155224874620_579560007742 | Oren Laadan |
|
From: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx
This marks ext[234] as being checkpointable. There will be many
more to do this to, but this is a start.
Signed-off-by: Dave Hansen <dave@xxxxxxxx |
|
| |
| 159526504307_556460007534 | Oren Laadan |
|
Couple of nits:
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From f5dec38baa6a2cc2a88783db3a9afd676821d293 Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, 30 Mar |
|
| |
| 190424684502_502660007819 | Oren Laadan |
|
Minor comment.
Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote:
| From 7bb32901eb8cefba38bd06bea8a1630ac0dd5051 Mon Sep 17 00:00:00 2001
| From: Oren Laadan <orenl@xxxxxxxxxxxxxxx
| Date: Mon, 30 Mar |
|
| |
| 109528904048_561160007549 | Serge E Hallyn |
|
A pipe is essentially a double-headed inode with a buffer attached to
it. We checkpoint the pipe buffer only once, as soon as we hit one
side of the pipe, regardless whether it is read- or write- end |
|
| |
