Track in-kernel when we expect checkpoint/restart to work

These are just a few simple examples of things we know we can't checkpoint now. There are plenty more, but this should give everyone an idea how this will look in practice.

Signed-off-by Dave Hansen <[email protected]>

---

 linux-2.6.git-dave/fs/aio.c     |    7 +++++++
 linux-2.6.git-dave/ipc/mqueue.c |    3 +++
 linux-2.6.git-dave/net/socket.c |    5 +++++
 3 files changed, 15 insertions(+)

diff -puN fs/aio.c~no-checkpointing-for-sockets fs/aio.c

fs/aio.c renamed from fs/aio.c~no-checkpointing-for-sockets +5 -0

@@ -19,6 +19,7 @@
 
 #define DEBUG 0
 
+#include <linux/checkpoint.h>
 #include <linux/sched.h>
 #include <linux/fs.h>
 #include <linux/file.h>

@@ -1663,6 +1664,8 @@ asmlinkage long sys_io_submit(aio_contex
 	if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)))))
 		return -EFAULT;
 
+	process_deny_checkpointing(current);
+
 	ctx = lookup_ioctx(ctx_id);
 	if (unlikely(!ctx)) {
 		pr_debug("EINVAL: io_submit: invalid context id\n");

@@ -1742,6 +1745,8 @@ asmlinkage long sys_io_cancel(aio_contex
 	if (unlikely(!ctx))
 		return -EINVAL;
 
+	process_deny_checkpointing(current);
+
 	spin_lock_irq(&ctx->ctx_lock);
 	ret = -EAGAIN;
 	kiocb = lookup_kiocb(ctx, iocb, key);

fs/aio.c renamed from fs/aio.c~no-checkpointing-for-sockets +1 -0

+
 	if (likely(ioctx)) {
 		if (likely(min_nr <= nr && min_nr >= 0 && nr >= 0))
 			ret = read_events(ioctx, min_nr, nr, events, timeout);

diff -puN ipc/mqueue.c~no-checkpointing-for-sockets ipc/mqueue.c

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +3 -0

@@ -14,6 +14,7 @@
  */
 
 #include <linux/capability.h>
+#include <linux/checkpoint.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
 #include <linux/file.h>

@@ -655,6 +656,8 @@ asmlinkage long sys_mq_open(const char _
 	char *name;
 	int fd, error;
 
+	process_deny_checkpointing(current);
+
 	error = audit_mq_open(oflag, mode, u_attr);
 	if (error != 0)
 		return error;

diff -puN net/socket.c~no-checkpointing-for-sockets net/socket.c

net/socket.c renamed from net/socket.c~no-checkpointing-for-sockets +5 -0

@@ -87,6 +87,7 @@
 #include <linux/audit.h>
 #include <linux/wireless.h>
 #include <linux/nsproxy.h>
+#include <linux/checkpoint.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>

@@ -1236,6 +1237,8 @@ asmlinkage long sys_socket(int family, i
 	if (SOCK_NONBLOCK != O_NONBLOCK && (flags & SOCK_NONBLOCK))
 		flags = (flags & ~SOCK_NONBLOCK) | O_NONBLOCK;
 
+	process_deny_checkpointing(current);
+
 	retval = sock_create(family, type, protocol, &sock);
 	if (retval < 0)
 		goto out;

@@ -2130,6 +2133,8 @@ asmlinkage long sys_socketcall(int call,
 	a0 = a[0];
 	a1 = a[1];
 
+	process_deny_checkpointing(current);
+
 	switch (call) {
 	case SYS_SOCKET:
 		err = sys_socket(a0, a1, a[2]);

_
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

These are just a few simple examples of things we know we can't checkpoint now. There are plenty more, but this should give everyone an idea how this will look in practice.

Signed-off-by Dave Hansen <[email protected]>

---

 linux-2.6.git-dave/fs/aio.c     |    7 +++++++
 linux-2.6.git-dave/ipc/mqueue.c |    3 +++
 linux-2.6.git-dave/net/socket.c |    5 +++++
 3 files changed, 15 insertions(+)

diff -puN fs/aio.c~no-checkpointing-for-sockets fs/aio.c

fs/aio.c renamed from fs/aio.c~no-checkpointing-for-sockets +5 -0

@@ -19,6 +19,7 @@
 
 #define DEBUG 0
 
+#include <linux/checkpoint.h>
 #include <linux/sched.h>
 #include <linux/fs.h>
 #include <linux/file.h>

@@ -1663,6 +1664,8 @@ asmlinkage long sys_io_submit(aio_contex
 	if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)))))
 		return -EFAULT;
 
+	process_deny_checkpointing(current);
+
 	ctx = lookup_ioctx(ctx_id);
 	if (unlikely(!ctx)) {
 		pr_debug("EINVAL: io_submit: invalid context id\n");

@@ -1742,6 +1745,8 @@ asmlinkage long sys_io_cancel(aio_contex
 	if (unlikely(!ctx))
 		return -EINVAL;
 
+	process_deny_checkpointing(current);
+
 	spin_lock_irq(&ctx->ctx_lock);
 	ret = -EAGAIN;
 	kiocb = lookup_kiocb(ctx, iocb, key);

fs/aio.c renamed from fs/aio.c~no-checkpointing-for-sockets +1 -0

+
 	if (likely(ioctx)) {
 		if (likely(min_nr <= nr && min_nr >= 0 && nr >= 0))
 			ret = read_events(ioctx, min_nr, nr, events, timeout);

diff -puN ipc/mqueue.c~no-checkpointing-for-sockets ipc/mqueue.c

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +3 -0

@@ -14,6 +14,7 @@
  */
 
 #include <linux/capability.h>
+#include <linux/checkpoint.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
 #include <linux/file.h>

@@ -655,6 +656,8 @@ asmlinkage long sys_mq_open(const char _
 	char *name;
 	int fd, error;
 
+	process_deny_checkpointing(current);
+
 	error = audit_mq_open(oflag, mode, u_attr);
 	if (error != 0)
 		return error;

diff -puN net/socket.c~no-checkpointing-for-sockets net/socket.c

net/socket.c renamed from net/socket.c~no-checkpointing-for-sockets +5 -0

@@ -87,6 +87,7 @@
 #include <linux/audit.h>
 #include <linux/wireless.h>
 #include <linux/nsproxy.h>
+#include <linux/checkpoint.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>

@@ -1236,6 +1237,8 @@ asmlinkage long sys_socket(int family, i
 	if (SOCK_NONBLOCK != O_NONBLOCK && (flags & SOCK_NONBLOCK))
 		flags = (flags & ~SOCK_NONBLOCK) | O_NONBLOCK;
 
+	process_deny_checkpointing(current);
+
 	retval = sock_create(family, type, protocol, &sock);
 	if (retval < 0)
 		goto out;

@@ -2130,6 +2133,8 @@ asmlinkage long sys_socketcall(int call,
 	a0 = a[0];
 	a1 = a[1];
 
+	process_deny_checkpointing(current);
+
 	switch (call) {
 	case SYS_SOCKET:
 		err = sys_socket(a0, a1, a[2]);

_
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Quoted 6 lines · Serge E. Hallyn

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Good question. I know nothing, either. :)

My thought was that any process *trying* to do aio stuff of any kind is going to be really confused if it gets checkpointed. Or, it might try to submit an aio right after it checks the list of them. I thought it best to be cautious and say, if you screw with aio, no checkpointing for you!

Quoted 8 lines · Dave Hansen

Quoted 6 lines · Serge E. Hallyn

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Quoted 7 lines

Good question. I know nothing, either. :)

My thought was that any process *trying* to do aio stuff of any kind is going to be really confused if it gets checkpointed. Or, it might try to submit an aio right after it checks the list of them. I thought it best to be cautious and say, if you screw with aio, no checkpointing for you!

as long as there's total transparency and the transition from CR-capable to CR-disabled state is absolutely safe and race-free, that should be fine.

I expect users to quickly cause enough pressure to reduce the NOCR areas of the kernel significantly ;-)

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate?

Quoted 3 lines

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate?

Surely not ACPI-compliant.

Quoted 3 lines

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate?

Surely not ACPI-compliant.

Quoted 5 lines · Rafael J. Wysocki

Quoted 3 lines

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate?

Surely not ACPI-compliant.

what do you mean?

Quoted 3 lines

Quoted 1 line

Surely not ACPI-compliant.

what do you mean?

The ACPI spec says quite specifically what should be done while entering hibernation and during resume from hibernation. We're not following that in the current code, but we can (gradually) update the code to become ACPI-compilant in that respect. However, if we go the checkpointing route, I don't think that will be possible any more.

Quoted 3 lines

Quoted 1 line

Surely not ACPI-compliant.

what do you mean?

The ACPI spec says quite specifically what should be done while entering hibernation and during resume from hibernation. We're not following that in the current code, but we can (gradually) update the code to become ACPI-compilant in that respect. However, if we go the checkpointing route, I don't think that will be possible any more.

Quoted 4 lines · Rafael J. Wysocki

Quoted 3 lines

Quoted 1 line

Surely not ACPI-compliant.

what do you mean?

Quoted 5 lines

The ACPI spec says quite specifically what should be done while entering hibernation and during resume from hibernation. We're not following that in the current code, but we can (gradually) update the code to become ACPI-compilant in that respect. However, if we go the checkpointing route, I don't think that will be possible any more.

ah, i see. I did not mean to utilize any ACPI paths but simple powerdown or reboot.

If we checkpoint all apps to persistent disk areas (which the checkpoint patches in this thread are about), then we can just reboot the kernel and forget all its state.

That capability can be used to build a really robust hibernation implementation IMO: we could "hibernate/kexec" over between different kernel versions transparently. (only a small delay will be noticed by the user - if we do it smartly with in-kernel modesetting then not even the screen contents will be changed over this.)

Quoted 9 lines · Rafael J. Wysocki

Quoted 3 lines

Quoted 1 line

Surely not ACPI-compliant.

what do you mean?

The ACPI spec says quite specifically what should be done while entering hibernation and during resume from hibernation. We're not following that in the current code, but we can (gradually) update the code to become ACPI-compilant in that respect. However, if we go the checkpointing route, I don't think that will be possible any more.

ah, i see. I did not mean to utilize any ACPI paths but simple powerdown or reboot.

If we checkpoint all apps to persistent disk areas (which the checkpoint patches in this thread are about), then we can just reboot the kernel and forget all its state.

That capability can be used to build a really robust hibernation implementation IMO: we could "hibernate/kexec" over between different kernel versions transparently. (only a small delay will be noticed by the user - if we do it smartly with in-kernel modesetting then not even the screen contents will be changed over this.)

Quoted 4 lines · Rafael J. Wysocki

Quoted 3 lines

Quoted 1 line

Surely not ACPI-compliant.

what do you mean?

Quoted 5 lines

The ACPI spec says quite specifically what should be done while entering hibernation and during resume from hibernation. We're not following that in the current code, but we can (gradually) update the code to become ACPI-compilant in that respect. However, if we go the checkpointing route, I don't think that will be possible any more.

ah, i see. I did not mean to utilize any ACPI paths but simple powerdown or reboot.

If we checkpoint all apps to persistent disk areas (which the checkpoint patches in this thread are about), then we can just reboot the kernel and forget all its state.

That capability can be used to build a really robust hibernation implementation IMO: we could "hibernate/kexec" over between different kernel versions transparently. (only a small delay will be noticed by the user - if we do it smartly with in-kernel modesetting then not even the screen contents will be changed over this.)

Quoted 9 lines · Rafael J. Wysocki

Quoted 3 lines

Quoted 1 line

Surely not ACPI-compliant.

what do you mean?

The ACPI spec says quite specifically what should be done while entering hibernation and during resume from hibernation. We're not following that in the current code, but we can (gradually) update the code to become ACPI-compilant in that respect. However, if we go the checkpointing route, I don't think that will be possible any more.

ah, i see. I did not mean to utilize any ACPI paths but simple powerdown or reboot.

If we checkpoint all apps to persistent disk areas (which the checkpoint patches in this thread are about), then we can just reboot the kernel and forget all its state.

That capability can be used to build a really robust hibernation implementation IMO: we could "hibernate/kexec" over between different kernel versions transparently. (only a small delay will be noticed by the user - if we do it smartly with in-kernel modesetting then not even the screen contents will be changed over this.)

Quoted 5 lines · Rafael J. Wysocki

Quoted 3 lines

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate?

Surely not ACPI-compliant.

what do you mean?

Quoted 8 lines · Dave Hansen

Quoted 6 lines · Serge E. Hallyn

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Quoted 7 lines

Good question. I know nothing, either. :)

My thought was that any process *trying* to do aio stuff of any kind is going to be really confused if it gets checkpointed. Or, it might try to submit an aio right after it checks the list of them. I thought it best to be cautious and say, if you screw with aio, no checkpointing for you!

as long as there's total transparency and the transition from CR-capable to CR-disabled state is absolutely safe and race-free, that should be fine.

I expect users to quickly cause enough pressure to reduce the NOCR areas of the kernel significantly ;-)

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate?

Quoted 7 lines

Quoted 6 lines

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Quoted 7 lines

Good question. I know nothing, either. :)

My thought was that any process *trying* to do aio stuff of any kind is going to be really confused if it gets checkpointed. Or, it might try to submit an aio right after it checks the list of them. I thought it best to be cautious and say, if you screw with aio, no checkpointing for you!

as long as there's total transparency and the transition from CR-capable to CR-disabled state is absolutely safe and race-free, that should be fine.

I expect users to quickly cause enough pressure to reduce the NOCR areas of the kernel significantly ;-)

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate? That would be way cool for users and for testing: we could do transparent kernel upgrades/downgrades via this form of hibernation, between CR-compatible kernels (!).

Pie in the sky for sure, but way cool: it could propel Linux kernel testing to completely new areas - new kernels could be tried non-intrusively. (as long as a new kernel does not corrupt the CR data structures - so some good consistency and redundancy checking would be nice in the format!)

Quoted 7 lines

Quoted 6 lines

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Quoted 7 lines

Good question. I know nothing, either. :)

My thought was that any process *trying* to do aio stuff of any kind is going to be really confused if it gets checkpointed. Or, it might try to submit an aio right after it checks the list of them. I thought it best to be cautious and say, if you screw with aio, no checkpointing for you!

as long as there's total transparency and the transition from CR-capable to CR-disabled state is absolutely safe and race-free, that should be fine.

I expect users to quickly cause enough pressure to reduce the NOCR areas of the kernel significantly ;-)

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate? That would be way cool for users and for testing: we could do transparent kernel upgrades/downgrades via this form of hibernation, between CR-compatible kernels (!).

Pie in the sky for sure, but way cool: it could propel Linux kernel testing to completely new areas - new kernels could be tried non-intrusively. (as long as a new kernel does not corrupt the CR data structures - so some good consistency and redundancy checking would be nice in the format!)

Quoted 5 lines

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate? That would be way cool for users and for testing: we could do transparent kernel upgrades/downgrades via this form of hibernation, between CR-compatible kernels (!).

Well, if we could do that, I guess we could also use CR to 'hibernate' your desktop then continue on your notebook. And yes that sounds cool.

Quoted 5 lines

Pie in the sky for sure, but way cool: it could propel Linux kernel testing to completely new areas - new kernels could be tried non-intrusively. (as long as a new kernel does not corrupt the CR data structures - so some good consistency and redundancy checking would be nice in the format!)

Well, for simple apps, it should not be that hard...

Quoted 5 lines

In the long run, could we expect a (experimental) version of hibernation that would just use this checkpointing facility to hibernate? That would be way cool for users and for testing: we could do transparent kernel upgrades/downgrades via this form of hibernation, between CR-compatible kernels (!).

Well, if we could do that, I guess we could also use CR to 'hibernate' your desktop then continue on your notebook. And yes that sounds cool.

Quoted 5 lines

Pie in the sky for sure, but way cool: it could propel Linux kernel testing to completely new areas - new kernels could be tried non-intrusively. (as long as a new kernel does not corrupt the CR data structures - so some good consistency and redundancy checking would be nice in the format!)

Well, for simple apps, it should not be that hard...

Quoted 6 lines · Serge E. Hallyn

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Good question. I know nothing, either. :)

My thought was that any process *trying* to do aio stuff of any kind is going to be really confused if it gets checkpointed. Or, it might try to submit an aio right after it checks the list of them. I thought it best to be cautious and say, if you screw with aio, no checkpointing for you!

Quoted 6 lines · Serge E. Hallyn

Hmm, I don't know too much about aio, but is it possible to succeed with io_getevents if we didn't first do a submit? It looks like the contexts are looked up out of current->mm, so I don't think we need this call here.

Otherwise, this is neat.

Good question. I know nothing, either. :)

My thought was that any process *trying* to do aio stuff of any kind is going to be really confused if it gets checkpointed. Or, it might try to submit an aio right after it checks the list of them. I thought it best to be cautious and say, if you screw with aio, no checkpointing for you!

These are just a few simple examples of things we know we can't checkpoint now. There are plenty more, but this should give everyone an idea how this will look in practice.

Signed-off-by Dave Hansen <[email protected]>

---

 linux-2.6.git-dave/fs/aio.c     |    7 +++++++
 linux-2.6.git-dave/ipc/mqueue.c |    3 +++
 linux-2.6.git-dave/net/socket.c |    5 +++++
 3 files changed, 15 insertions(+)

diff -puN fs/aio.c~no-checkpointing-for-sockets fs/aio.c

fs/aio.c renamed from fs/aio.c~no-checkpointing-for-sockets +7 -0

@@ -19,6 +19,7 @@
 
 #define DEBUG 0
 
+#include <linux/checkpoint.h>
 #include <linux/sched.h>
 #include <linux/fs.h>
 #include <linux/file.h>

@@ -1663,6 +1664,8 @@ asmlinkage long sys_io_submit(aio_contex
 	if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)))))
 		return -EFAULT;
 
+	process_deny_checkpointing(current);
+
 	ctx = lookup_ioctx(ctx_id);
 	if (unlikely(!ctx)) {
 		pr_debug("EINVAL: io_submit: invalid context id\n");

@@ -1742,6 +1745,8 @@ asmlinkage long sys_io_cancel(aio_contex
 	if (unlikely(!ctx))
 		return -EINVAL;
 
+	process_deny_checkpointing(current);
+
 	spin_lock_irq(&ctx->ctx_lock);
 	ret = -EAGAIN;
 	kiocb = lookup_kiocb(ctx, iocb, key);

@@ -1796,6 +1801,8 @@ asmlinkage long sys_io_getevents(aio_con
 	struct kioctx *ioctx = lookup_ioctx(ctx_id);
 	long ret = -EINVAL;
 
+	process_deny_checkpointing(current);
+
 	if (likely(ioctx)) {
 		if (likely(min_nr <= nr && min_nr >= 0 && nr >= 0))
 			ret = read_events(ioctx, min_nr, nr, events, timeout);

diff -puN ipc/mqueue.c~no-checkpointing-for-sockets ipc/mqueue.c

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +3 -0

@@ -14,6 +14,7 @@
  */
 
 #include <linux/capability.h>
+#include <linux/checkpoint.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
 #include <linux/file.h>

@@ -655,6 +656,8 @@ asmlinkage long sys_mq_open(const char _
 	char *name;
 	int fd, error;
 
+	process_deny_checkpointing(current);
+
 	error = audit_mq_open(oflag, mode, u_attr);
 	if (error != 0)
 		return error;

diff -puN net/socket.c~no-checkpointing-for-sockets net/socket.c

net/socket.c renamed from net/socket.c~no-checkpointing-for-sockets +3 -0

@@ -87,6 +87,7 @@
 #include <linux/audit.h>
 #include <linux/wireless.h>
 #include <linux/nsproxy.h>
+#include <linux/checkpoint.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>

@@ -1236,6 +1237,8 @@ asmlinkage long sys_socket(int family, i
 	if (SOCK_NONBLOCK != O_NONBLOCK && (flags & SOCK_NONBLOCK))
 		flags = (flags & ~SOCK_NONBLOCK) | O_NONBLOCK;
 
+	process_deny_checkpointing(current);
+
 	retval = sock_create(family, type, protocol, &sock);
 	if (retval < 0)
 		goto out;

These are just a few simple examples of things we know we can't checkpoint now. There are plenty more, but this should give everyone an idea how this will look in practice.

Signed-off-by Dave Hansen <[email protected]>

---

 linux-2.6.git-dave/fs/aio.c     |    7 +++++++
 linux-2.6.git-dave/ipc/mqueue.c |    3 +++
 linux-2.6.git-dave/net/socket.c |    5 +++++
 3 files changed, 15 insertions(+)

diff -puN fs/aio.c~no-checkpointing-for-sockets fs/aio.c

fs/aio.c renamed from fs/aio.c~no-checkpointing-for-sockets +7 -0

@@ -19,6 +19,7 @@
 
 #define DEBUG 0
 
+#include <linux/checkpoint.h>
 #include <linux/sched.h>
 #include <linux/fs.h>
 #include <linux/file.h>

@@ -1663,6 +1664,8 @@ asmlinkage long sys_io_submit(aio_contex
 	if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)))))
 		return -EFAULT;
 
+	process_deny_checkpointing(current);
+
 	ctx = lookup_ioctx(ctx_id);
 	if (unlikely(!ctx)) {
 		pr_debug("EINVAL: io_submit: invalid context id\n");

@@ -1742,6 +1745,8 @@ asmlinkage long sys_io_cancel(aio_contex
 	if (unlikely(!ctx))
 		return -EINVAL;
 
+	process_deny_checkpointing(current);
+
 	spin_lock_irq(&ctx->ctx_lock);
 	ret = -EAGAIN;
 	kiocb = lookup_kiocb(ctx, iocb, key);

@@ -1796,6 +1801,8 @@ asmlinkage long sys_io_getevents(aio_con
 	struct kioctx *ioctx = lookup_ioctx(ctx_id);
 	long ret = -EINVAL;
 
+	process_deny_checkpointing(current);
+
 	if (likely(ioctx)) {
 		if (likely(min_nr <= nr && min_nr >= 0 && nr >= 0))
 			ret = read_events(ioctx, min_nr, nr, events, timeout);

diff -puN ipc/mqueue.c~no-checkpointing-for-sockets ipc/mqueue.c

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +3 -0

@@ -14,6 +14,7 @@
  */
 
 #include <linux/capability.h>
+#include <linux/checkpoint.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
 #include <linux/file.h>

@@ -655,6 +656,8 @@ asmlinkage long sys_mq_open(const char _
 	char *name;
 	int fd, error;
 
+	process_deny_checkpointing(current);
+
 	error = audit_mq_open(oflag, mode, u_attr);
 	if (error != 0)
 		return error;

diff -puN net/socket.c~no-checkpointing-for-sockets net/socket.c

net/socket.c renamed from net/socket.c~no-checkpointing-for-sockets +3 -0

@@ -87,6 +87,7 @@
 #include <linux/audit.h>
 #include <linux/wireless.h>
 #include <linux/nsproxy.h>
+#include <linux/checkpoint.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>

@@ -1236,6 +1237,8 @@ asmlinkage long sys_socket(int family, i
 	if (SOCK_NONBLOCK != O_NONBLOCK && (flags & SOCK_NONBLOCK))
 		flags = (flags & ~SOCK_NONBLOCK) | O_NONBLOCK;
 
+	process_deny_checkpointing(current);
+
 	retval = sock_create(family, type, protocol, &sock);
 	if (retval < 0)
 		goto out;

diff -puN ipc/mqueue.c~no-checkpointing-for-sockets ipc/mqueue.c

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +1 -0

@@ -14,6 +14,7 @@
  */
 
 #include <linux/capability.h>
+#include <linux/checkpoint.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
 #include <linux/file.h>

diff -puN ipc/mqueue.c~no-checkpointing-for-sockets ipc/mqueue.c

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +1 -0

@@ -14,6 +14,7 @@
  */
 
 #include <linux/capability.h>
+#include <linux/checkpoint.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
 #include <linux/file.h>

Quoted 15 lines

diff -puN ipc/mqueue.c~no-checkpointing-for-sockets ipc/mqueue.c

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +1 -0

@@ -14,6 +14,7 @@
  */
 
 #include <linux/capability.h>
+#include <linux/checkpoint.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
 #include <linux/file.h>

@@ -655,6 +656,8 @@ asmlinkage long sys_mq_open(const char _
 	char *name;
 	int fd, error;
 

ipc/mqueue.c asmlinkage long sys_mq_open(const char _ · line 660

Quoted 2 lines

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +2 -0

+	process_deny_checkpointing(current);
+

mqueue being a file system, i would put the checks in the inode_operations.

Also, you can't always deny ! I would expect some allow in sys_mq_unlink().

Quoted 15 lines

diff -puN ipc/mqueue.c~no-checkpointing-for-sockets ipc/mqueue.c

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +1 -0

@@ -14,6 +14,7 @@
  */
 
 #include <linux/capability.h>
+#include <linux/checkpoint.h>
 #include <linux/init.h>
 #include <linux/pagemap.h>
 #include <linux/file.h>

@@ -655,6 +656,8 @@ asmlinkage long sys_mq_open(const char _
 	char *name;
 	int fd, error;
 

ipc/mqueue.c asmlinkage long sys_mq_open(const char _ · line 660

Quoted 2 lines

ipc/mqueue.c renamed from ipc/mqueue.c~no-checkpointing-for-sockets +2 -0

+	process_deny_checkpointing(current);
+

mqueue being a file system, i would put the checks in the inode_operations.

Also, you can't always deny ! I would expect some allow in sys_mq_unlink().

Remember a part of Ingo's motivation is to push c/r developers to address the lacking features that users use most, earlier. So the warnings and subsequent email complaints are what we're after. Hence a single 'checkpointable or not' flag.

Given the single flag, how do you know at sys_mq_unlink() whether the process also has an opensocket?

Rather than make this tracking facility more complicated and intrusive, if people complain that they couldn't checkpoint bc of a warning about aio, then we implement aio c/r! We don't just try and reduce the amount of time that you can't checkpoint bc of lack of aio c/r support :)

-serge

Remember a part of Ingo's motivation is to push c/r developers to address the lacking features that users use most, earlier. So the warnings and subsequent email complaints are what we're after. Hence a single 'checkpointable or not' flag.

Given the single flag, how do you know at sys_mq_unlink() whether the process also has an opensocket?

Rather than make this tracking facility more complicated and intrusive, if people complain that they couldn't checkpoint bc of a warning about aio, then we implement aio c/r! We don't just try and reduce the amount of time that you can't checkpoint bc of lack of aio c/r support :)

-serge

Quoted 8 lines · Serge E. Hallyn

Remember a part of Ingo's motivation is to push c/r developers to address the lacking features that users use most, earlier. So the warnings and subsequent email complaints are what we're after. Hence a single 'checkpointable or not' flag.

Given the single flag, how do you know at sys_mq_unlink() whether the process also has an opensocket?

Quoted 6 lines

Rather than make this tracking facility more complicated and intrusive, if people complain that they couldn't checkpoint bc of a warning about aio, then we implement aio c/r! We don't just try and reduce the amount of time that you can't checkpoint bc of lack of aio c/r support :)

-serge

Serge,

It's exactly what I meant before, the tracking facility would be awfully complicated. It cannot be done that way.
But there's also something awkward with the flag thing : can you provide right now an exhaustive list of all the places where you must raise it ?

I'd rather do some heavy checking at checkpoint time.

It's exactly what I meant before, the tracking facility would be awfully complicated. It cannot be done that way.
But there's also something awkward with the flag thing : can you provide right now an exhaustive list of all the places where you must raise it ?

Quoted 8 lines · Serge E. Hallyn

Remember a part of Ingo's motivation is to push c/r developers to address the lacking features that users use most, earlier. So the warnings and subsequent email complaints are what we're after. Hence a single 'checkpointable or not' flag.

Given the single flag, how do you know at sys_mq_unlink() whether the process also has an opensocket?

Quoted 6 lines

Rather than make this tracking facility more complicated and intrusive, if people complain that they couldn't checkpoint bc of a warning about aio, then we implement aio c/r! We don't just try and reduce the amount of time that you can't checkpoint bc of lack of aio c/r support :)

-serge

Serge,

It's exactly what I meant before, the tracking facility would be awfully complicated. It cannot be done that way.
But there's also something awkward with the flag thing : can you provide right now an exhaustive list of all the places where you must raise it ?

I'd rather do some heavy checking at checkpoint time.

It's exactly what I meant before, the tracking facility would be awfully complicated. It cannot be done that way.
But there's also something awkward with the flag thing : can you provide right now an exhaustive list of all the places where you must raise it ?

Quoted 4 lines · Greg Kurz

It's exactly what I meant before, the tracking facility would be awfully complicated. It cannot be done that way.
But there's also something awkward with the flag thing : can you provide right now an exhaustive list of all the places where you must raise it ?

Greg, that's just pure FUD. We don't say that spinlocks are a bad thing because we can't come up with an exhaustive list of places where we need locking.

We'll do plenty of checks at checkpoint time.

We'll do plenty of checks at runtime.

Neither will work completely on its own, and neither will be exhaustive. The way this will work is just as Serge said: in true Linux style, we'll add more places users of process_deny_checkpoint() incrementally as we find them and as people complain. We'll also be incrementally removing them as we add functionality.

-- Dave

Quoted 4 lines · Greg Kurz

It's exactly what I meant before, the tracking facility would be awfully complicated. It cannot be done that way.
But there's also something awkward with the flag thing : can you provide right now an exhaustive list of all the places where you must raise it ?

Greg, that's just pure FUD. We don't say that spinlocks are a bad thing because we can't come up with an exhaustive list of places where we need locking.

We'll do plenty of checks at checkpoint time.

We'll do plenty of checks at runtime.

Neither will work completely on its own, and neither will be exhaustive. The way this will work is just as Serge said: in true Linux style, we'll add more places users of process_deny_checkpoint() incrementally as we find them and as people complain. We'll also be incrementally removing them as we add functionality.

-- Dave

Suggested by Ingo.

Checkpoint/restart is going to be a long effort to get things working. We're going to have a lot of things that we know just don't work for a long time. That doesn't mean that it will be useless, it just means that there's some complicated features that we are going to have to work incrementally to fix.

This patch introduces a new mechanism to help the checkpoint/restart developers. A new function pair: task/process_deny_checkpoint() is created. When called, these tell the kernel that we *know* that the process has performed some activity that will keep it from being properly checkpointed.

The 'flag' is an atomic_t for now so that we can have some level of atomicity and make sure to only warn once.

For now, this is a one-way trip. Once a process is no longer 'may_checkpoint' capable, neither it nor its children ever will be. This can, of course, be fixed up in the future. We might want to reset the flag when a new pid namespace is created, for instance.

Signed-off-by Dave Hansen <[email protected]>

---

 linux-2.6.git-dave/include/linux/checkpoint.h |   31 +++++++++++++++++++++++++-
 linux-2.6.git-dave/include/linux/sched.h      |    3 ++
 linux-2.6.git-dave/kernel/fork.c              |   10 ++++++++
 3 files changed, 43 insertions(+), 1 deletion(-)

diff -puN include/linux/checkpoint.h~flag include/linux/checkpoint.h

include/linux/checkpoint.h renamed from include/linux/checkpoint.h~flag +30 -1

@@ -10,8 +10,11 @@
  *  distribution for more details.
  */
 
-#include <linux/path.h>
 #include <linux/fs.h>
+#include <linux/path.h>
+#include <linux/sched.h>
+
+#ifdef CONFIG_CHECKPOINT_RESTART
 
 #define CR_VERSION  2
 

@@ -94,4 +97,30 @@ extern void file_pos_write(struct file *
 #define cr_debug(fmt, args...)  \
 	pr_debug("[CR:%s] " fmt, __func__, ## args)
 
+static inline void __task_deny_checkpointing(struct task_struct *task,
+		char *file, int line)
+{
+	if(!atomic_dec_and_test(&task->may_checkpoint))
+		return;
+	printk(KERN_INFO "process performed an action that can not be "
+			"checkpointed at: %s:%d\n", file, line);
+	WARN_ON(1);
+}
+#define process_deny_checkpointing(p) __task_deny_checkpointing(p, __FILE__, __LINE__)
+
+/*
+ * For now, we're not going to have a distinction between
+ * tasks and processes for the purpose of c/r.  But, allow
+ * these two calls anyway to make new users at least think
+ * about it.
+ */
+#define task_deny_checkpointing(p) __task_deny_checkpointing(p, __FILE__, __LINE__)
+
+#else
+
+static inline void task_deny_checkpointing(struct task_struct *task) {}
+static inline void process_deny_checkpointing(struct task_struct *task) {}
+
+#endif
+
 #endif /* _CHECKPOINT_CKPT_H_ */

diff -puN include/linux/sched.h~flag include/linux/sched.h

include/linux/sched.h renamed from include/linux/sched.h~flag +3 -0

@@ -1301,6 +1301,9 @@ struct task_struct {
 	int latency_record_count;
 	struct latency_record latency_record[LT_SAVECOUNT];
 #endif
+#ifdef CONFIG_CHECKPOINT_RESTART
+	atomic_t may_checkpoint;
+#endif
 };
 
 /*

diff -puN kernel/fork.c~flag kernel/fork.c

kernel/fork.c renamed from kernel/fork.c~flag +10 -0

@@ -194,6 +194,13 @@ void __init fork_init(unsigned long memp
 	init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
 	init_task.signal->rlim[RLIMIT_SIGPENDING] =
 		init_task.signal->rlim[RLIMIT_NPROC];
+
+#ifdef CONFIG_CHECKPOINT_RESTART
+	/*
+	 * This probably won't stay set for long...
+	 */
+	atomic_set(&init_task.may_checkpoint, 1);
+#endif
 }
 
 int __attribute__((weak)) arch_dup_task_struct(struct task_struct *dst,

@@ -244,6 +251,9 @@ static struct task_struct *dup_task_stru
 	tsk->btrace_seq = 0;
 #endif
 	tsk->splice_pipe = NULL;
+#ifdef CONFIG_CHECKPOINT_RESTART
+	atomic_set(&tsk->may_checkpoint, atomic_read(&orig->may_checkpoint));
+#endif
 	return tsk;
 
 out:

_
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Suggested by Ingo.

Checkpoint/restart is going to be a long effort to get things working. We're going to have a lot of things that we know just don't work for a long time. That doesn't mean that it will be useless, it just means that there's some complicated features that we are going to have to work incrementally to fix.

This patch introduces a new mechanism to help the checkpoint/restart developers. A new function pair: task/process_deny_checkpoint() is created. When called, these tell the kernel that we *know* that the process has performed some activity that will keep it from being properly checkpointed.

The 'flag' is an atomic_t for now so that we can have some level of atomicity and make sure to only warn once.

For now, this is a one-way trip. Once a process is no longer 'may_checkpoint' capable, neither it nor its children ever will be. This can, of course, be fixed up in the future. We might want to reset the flag when a new pid namespace is created, for instance.

Signed-off-by Dave Hansen <[email protected]>

---

 linux-2.6.git-dave/include/linux/checkpoint.h |   31 +++++++++++++++++++++++++-
 linux-2.6.git-dave/include/linux/sched.h      |    3 ++
 linux-2.6.git-dave/kernel/fork.c              |   10 ++++++++
 3 files changed, 43 insertions(+), 1 deletion(-)

diff -puN include/linux/checkpoint.h~flag include/linux/checkpoint.h

include/linux/checkpoint.h renamed from include/linux/checkpoint.h~flag +30 -1

@@ -10,8 +10,11 @@
  *  distribution for more details.
  */
 
-#include <linux/path.h>
 #include <linux/fs.h>
+#include <linux/path.h>
+#include <linux/sched.h>
+
+#ifdef CONFIG_CHECKPOINT_RESTART
 
 #define CR_VERSION  2
 

@@ -94,4 +97,30 @@ extern void file_pos_write(struct file *
 #define cr_debug(fmt, args...)  \
 	pr_debug("[CR:%s] " fmt, __func__, ## args)
 
+static inline void __task_deny_checkpointing(struct task_struct *task,
+		char *file, int line)
+{
+	if(!atomic_dec_and_test(&task->may_checkpoint))
+		return;
+	printk(KERN_INFO "process performed an action that can not be "
+			"checkpointed at: %s:%d\n", file, line);
+	WARN_ON(1);
+}
+#define process_deny_checkpointing(p) __task_deny_checkpointing(p, __FILE__, __LINE__)
+
+/*
+ * For now, we're not going to have a distinction between
+ * tasks and processes for the purpose of c/r.  But, allow
+ * these two calls anyway to make new users at least think
+ * about it.
+ */
+#define task_deny_checkpointing(p) __task_deny_checkpointing(p, __FILE__, __LINE__)
+
+#else
+
+static inline void task_deny_checkpointing(struct task_struct *task) {}
+static inline void process_deny_checkpointing(struct task_struct *task) {}
+
+#endif
+
 #endif /* _CHECKPOINT_CKPT_H_ */

diff -puN include/linux/sched.h~flag include/linux/sched.h

include/linux/sched.h renamed from include/linux/sched.h~flag +3 -0

@@ -1301,6 +1301,9 @@ struct task_struct {
 	int latency_record_count;
 	struct latency_record latency_record[LT_SAVECOUNT];
 #endif
+#ifdef CONFIG_CHECKPOINT_RESTART
+	atomic_t may_checkpoint;
+#endif
 };
 
 /*

diff -puN kernel/fork.c~flag kernel/fork.c

kernel/fork.c renamed from kernel/fork.c~flag +10 -0

@@ -194,6 +194,13 @@ void __init fork_init(unsigned long memp
 	init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
 	init_task.signal->rlim[RLIMIT_SIGPENDING] =
 		init_task.signal->rlim[RLIMIT_NPROC];
+
+#ifdef CONFIG_CHECKPOINT_RESTART
+	/*
+	 * This probably won't stay set for long...
+	 */
+	atomic_set(&init_task.may_checkpoint, 1);
+#endif
 }
 
 int __attribute__((weak)) arch_dup_task_struct(struct task_struct *dst,

@@ -244,6 +251,9 @@ static struct task_struct *dup_task_stru
 	tsk->btrace_seq = 0;
 #endif
 	tsk->splice_pipe = NULL;
+#ifdef CONFIG_CHECKPOINT_RESTART
+	atomic_set(&tsk->may_checkpoint, atomic_read(&orig->may_checkpoint));
+#endif
 	return tsk;
 
 out:

_
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers

Quoted 14 lines · Dave Hansen

Suggested by Ingo.

Checkpoint/restart is going to be a long effort to get things working. We're going to have a lot of things that we know just don't work for a long time. That doesn't mean that it will be useless, it just means that there's some complicated features that we are going to have to work incrementally to fix.

This patch introduces a new mechanism to help the checkpoint/restart developers. A new function pair: task/process_deny_checkpoint() is created. When called, these tell the kernel that we *know* that the process has performed some activity that will keep it from being properly checkpointed.

Quoted 8 lines

The 'flag' is an atomic_t for now so that we can have some level of atomicity and make sure to only warn once.

For now, this is a one-way trip. Once a process is no longer 'may_checkpoint' capable, neither it nor its children ever will be. This can, of course, be fixed up in the future. We might want to reset the flag when a new pid namespace is created, for instance.

Then this patch should be described as:

Track in-kernel when we expect checkpoint/restart to fail.

By the way, why don't you introduce the reverse operation ?

Quoted 14 lines · Dave Hansen

Suggested by Ingo.

Checkpoint/restart is going to be a long effort to get things working. We're going to have a lot of things that we know just don't work for a long time. That doesn't mean that it will be useless, it just means that there's some complicated features that we are going to have to work incrementally to fix.

This patch introduces a new mechanism to help the checkpoint/restart developers. A new function pair: task/process_deny_checkpoint() is created. When called, these tell the kernel that we *know* that the process has performed some activity that will keep it from being properly checkpointed.

Quoted 8 lines

The 'flag' is an atomic_t for now so that we can have some level of atomicity and make sure to only warn once.

For now, this is a one-way trip. Once a process is no longer 'may_checkpoint' capable, neither it nor its children ever will be. This can, of course, be fixed up in the future. We might want to reset the flag when a new pid namespace is created, for instance.

Then this patch should be described as:

Track in-kernel when we expect checkpoint/restart to fail.

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

For example, you create a socket, the process becomes uncheckpointable, you close (via sys_close) the socket, you have to track this close to be related to the socket which made the process uncheckpointable in order to make the operation reversible.

Let's imagine you implement this reverse operation anyway, you have a process which creates a TCP connection, writes data and close the socket (so you are again checkpointable), but in the namespace there is the orphan socket which is not checkpointable yet and you missed this case.

Quoted 23 lines · Greg Kurz

Quoted 14 lines · Dave Hansen

Suggested by Ingo.

Checkpoint/restart is going to be a long effort to get things working. We're going to have a lot of things that we know just don't work for a long time. That doesn't mean that it will be useless, it just means that there's some complicated features that we are going to have to work incrementally to fix.

This patch introduces a new mechanism to help the checkpoint/restart developers. A new function pair: task/process_deny_checkpoint() is created. When called, these tell the kernel that we *know* that the process has performed some activity that will keep it from being properly checkpointed.

Quoted 8 lines

The 'flag' is an atomic_t for now so that we can have some level of atomicity and make sure to only warn once.

For now, this is a one-way trip. Once a process is no longer 'may_checkpoint' capable, neither it nor its children ever will be. This can, of course, be fixed up in the future. We might want to reset the flag when a new pid namespace is created, for instance.

Quoted 5 lines

Then this patch should be described as:

Track in-kernel when we expect checkpoint/restart to fail.

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

For example, you create a socket, the process becomes uncheckpointable, you close (via sys_close) the socket, you have to track this close to be related to the socket which made the process uncheckpointable in order to make the operation reversible.

Let's imagine you implement this reverse operation anyway, you have a process which creates a TCP connection, writes data and close the socket (so you are again checkpointable), but in the namespace there is the orphan socket which is not checkpointable yet and you missed this case.
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Quoted 1 line

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

Quoted 23 lines · Greg Kurz

Quoted 14 lines · Dave Hansen

Suggested by Ingo.

Checkpoint/restart is going to be a long effort to get things working. We're going to have a lot of things that we know just don't work for a long time. That doesn't mean that it will be useless, it just means that there's some complicated features that we are going to have to work incrementally to fix.

This patch introduces a new mechanism to help the checkpoint/restart developers. A new function pair: task/process_deny_checkpoint() is created. When called, these tell the kernel that we *know* that the process has performed some activity that will keep it from being properly checkpointed.

Quoted 8 lines

The 'flag' is an atomic_t for now so that we can have some level of atomicity and make sure to only warn once.

For now, this is a one-way trip. Once a process is no longer 'may_checkpoint' capable, neither it nor its children ever will be. This can, of course, be fixed up in the future. We might want to reset the flag when a new pid namespace is created, for instance.

Quoted 5 lines

Then this patch should be described as:

Track in-kernel when we expect checkpoint/restart to fail.

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

For example, you create a socket, the process becomes uncheckpointable, you close (via sys_close) the socket, you have to track this close to be related to the socket which made the process uncheckpointable in order to make the operation reversible.

Let's imagine you implement this reverse operation anyway, you have a process which creates a TCP connection, writes data and close the socket (so you are again checkpointable), but in the namespace there is the orphan socket which is not checkpointable yet and you missed this case.
_______________________________________________
Containers mailing list [email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers

Quoted 1 line

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

Quoted 5 lines · Daniel Lezcano

Quoted 1 line

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

it's also a not too interesting case. The end goal is to just be able to checkpoint everything that matters - in the long run there simply wont be many places that are marked 'cannot checkpoint'.

So the ability to deny a checkpoint is a transitional feature - a flexible CR todo list in essence - but also needed for applications/users that want to rely on CR being a dependable facility.

It would be bad for most of the practical usecases of checkpointing to allow the checkpointing of an app, just to see it break on restore due to lost context.

Ingo
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Quoted 5 lines · Daniel Lezcano

Quoted 1 line

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

it's also a not too interesting case. The end goal is to just be able to checkpoint everything that matters - in the long run there simply wont be many places that are marked 'cannot checkpoint'.

So the ability to deny a checkpoint is a transitional feature - a flexible CR todo list in essence - but also needed for applications/users that want to rely on CR being a dependable facility.

It would be bad for most of the practical usecases of checkpointing to allow the checkpointing of an app, just to see it break on restore due to lost context.

Ingo
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers

Quoted 16 lines · Ingo Molnar

Quoted 5 lines · Daniel Lezcano

Quoted 1 line

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

it's also a not too interesting case. The end goal is to just be able to checkpoint everything that matters - in the long run there simply wont be many places that are marked 'cannot checkpoint'.

So the ability to deny a checkpoint is a transitional feature - a flexible CR todo list in essence - but also needed for applications/users that want to rely on CR being a dependable facility.

Quoted 3 lines

It would be bad for most of the practical usecases of checkpointing to allow the checkpointing of an app, just to see it break on restore due to lost context.

Actually it need not wait for restore to fail - it can fail during the checkpoint, as soon as the unsupported feature is encountered.

Quoted 16 lines · Ingo Molnar

Quoted 5 lines · Daniel Lezcano

Quoted 1 line

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

it's also a not too interesting case. The end goal is to just be able to checkpoint everything that matters - in the long run there simply wont be many places that are marked 'cannot checkpoint'.

So the ability to deny a checkpoint is a transitional feature - a flexible CR todo list in essence - but also needed for applications/users that want to rely on CR being a dependable facility.

Quoted 3 lines

It would be bad for most of the practical usecases of checkpointing to allow the checkpointing of an app, just to see it break on restore due to lost context.

Actually it need not wait for restore to fail - it can fail during the checkpoint, as soon as the unsupported feature is encountered.

Adding that flag of what you suggest will help make it more vocal and obvious that a feature isn't supported, even without the user actually trying to take a checkpoint. I like that I idea.

Quoted 16 lines · Ingo Molnar

Quoted 5 lines · Daniel Lezcano

Quoted 1 line

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

it's also a not too interesting case. The end goal is to just be able to checkpoint everything that matters - in the long run there simply wont be many places that are marked 'cannot checkpoint'.

So the ability to deny a checkpoint is a transitional feature - a flexible CR todo list in essence - but also needed for applications/users that want to rely on CR being a dependable facility.

Quoted 3 lines

It would be bad for most of the practical usecases of checkpointing to allow the checkpointing of an app, just to see it break on restore due to lost context.

Actually it need not wait for restore to fail - it can fail during the checkpoint, as soon as the unsupported feature is encountered.

Quoted 16 lines · Ingo Molnar

Quoted 5 lines · Daniel Lezcano

Quoted 1 line

By the way, why don't you introduce the reverse operation ?

I think implementing the reverse operation will be a nightmare, IMHO it is safe to say we deny checkpointing for the process life-cycle either if the created resource was destroyed before we initiate the checkpoint.

it's also a not too interesting case. The end goal is to just be able to checkpoint everything that matters - in the long run there simply wont be many places that are marked 'cannot checkpoint'.

So the ability to deny a checkpoint is a transitional feature - a flexible CR todo list in essence - but also needed for applications/users that want to rely on CR being a dependable facility.

Quoted 3 lines

It would be bad for most of the practical usecases of checkpointing to allow the checkpointing of an app, just to see it break on restore due to lost context.

Actually it need not wait for restore to fail - it can fail during the checkpoint, as soon as the unsupported feature is encountered.

Adding that flag of what you suggest will help make it more vocal and obvious that a feature isn't supported, even without the user actually trying to take a checkpoint. I like that I idea.

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

Quoted 4 lines · Greg Kurz

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

Cool, so everyone agrees the patch is useful!

Quoted 4 lines · Greg Kurz

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

Cool, so everyone agrees the patch is useful!

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

Quoted 4 lines · Greg Kurz

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

I don't think it's true that it gives "absolutly no hint".

If the flag is not set, then checkpoint will succeed, right? Whereas if

the flag is set, then it's an indication that checkpoint could fail (but may still succeed if whatever condition caused the flag to be set is no longer true).

Chris

Quoted 4 lines · Greg Kurz

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

I don't think it's true that it gives "absolutly no hint".

If the flag is not set, then checkpoint will succeed, right? Whereas if

the flag is set, then it's an indication that checkpoint could fail (but may still succeed if whatever condition caused the flag to be set is no longer true).

Chris

Quoted 7 lines · Chris Friesen

Quoted 4 lines · Greg Kurz

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

Quoted 3 lines

I don't think it's true that it gives "absolutly no hint".

If the flag is not set, then checkpoint will succeed, right? Whereas if

Wrong. Unless you test_and_checkpoint atomically, the flag doesn't help.

Quoted 6 lines

the flag is set, then it's an indication that checkpoint could fail (but may still succeed if whatever condition caused the flag to be set is no longer true).

Chris

Signature · 11 lines

Gregory Kurz                                     gkurz-NmTC/[email protected]
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)534 638 479                           Fax +33 (0)561 400 420

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Quoted 7 lines · Chris Friesen

Quoted 4 lines · Greg Kurz

This flag is weak... testing it gives absolutly no hint whether the checkpoint may succeed or not. As it is designed now, a user can only be aware that checkpoint is *forever* denied. I agree that it's only useful as a "flexible CR todo list".

Quoted 3 lines

I don't think it's true that it gives "absolutly no hint".

If the flag is not set, then checkpoint will succeed, right? Whereas if

Wrong. Unless you test_and_checkpoint atomically, the flag doesn't help.

Quoted 6 lines

the flag is set, then it's an indication that checkpoint could fail (but may still succeed if whatever condition caused the flag to be set is no longer true).

Chris

Signature · 11 lines

Gregory Kurz                                     [email protected]
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)534 638 479                           Fax +33 (0)561 400 420

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers

For example, you create a socket, the process becomes uncheckpointable, you close (via sys_close) the socket, you have to track this close to be related to the socket which made the process uncheckpointable in order to make the operation reversible.