kill '_data' in cr_hdr_fd_data name

I'll be adding to this in a moment and it is in a bad place to do that cleanly now.

Also, increase the buffer size.  Most /proc files can output up to a page, so use the same here.

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

---

 linux-2.6.git-dave/fs/proc/base.c |   23 +++++++++++++++--------

 1 file changed, 15 insertions(+), 8 deletions(-)

diff -puN fs/proc/base.c~breakout-fdinfo fs/proc/base.c

fs/proc/base.c   2009-02-27 12:07:37.000000000 -0800 renamed from fs/proc/base.c~breakout-fdinfo        2009-02-27 12:07:37.000000000 -0800 +1 -1

@@ -1632,7 +1632,18 @@ out:
        return ~0U;
  }
 
-#define PROC_FDINFO_MAX 64
+#define PROC_FDINFO_MAX PAGE_SIZE

I'll be adding to this in a moment and it is in a bad place to do that cleanly now.

Also, increase the buffer size.  Most /proc files can output up to a page, so use the same here.

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

---

 linux-2.6.git-dave/fs/proc/base.c |   23 +++++++++++++++--------

 1 file changed, 15 insertions(+), 8 deletions(-)

diff -puN fs/proc/base.c~breakout-fdinfo fs/proc/base.c

fs/proc/base.c   2009-02-27 12:07:37.000000000 -0800 renamed from fs/proc/base.c~breakout-fdinfo        2009-02-27 12:07:37.000000000 -0800 +1 -1

@@ -1632,7 +1632,18 @@ out:
        return ~0U;
  }
 
-#define PROC_FDINFO_MAX 64
+#define PROC_FDINFO_MAX PAGE_SIZE

+#define FS_CHECKPOINTABLE 8

Quoted 1 line · Dave Hansen

+#define FS_CHECKPOINTABLE 8

This will ban all sockets, for instance, until all of them are C/R-ready. And every new socket type must be made C/R-ready from the very beginning, or risk major C/R breakage.

Quoted 1 line · Dave Hansen

+#define FS_CHECKPOINTABLE 8

This will ban all sockets, for instance, until all of them are C/R-ready. And every new socket type must be made C/R-ready from the very beginning, or risk major C/R breakage.

Quoted 4 lines

fs/proc/base.c renamed from fs/proc/base.c~breakout-fdinfo +4 -0

+static void proc_fd_write_info(struct file *file, char *info)
+{
+       int max = PROC_FDINFO_MAX;
+       int p = 0;

fs/proc/base.c out: · line 1645

Quoted 5 lines

fs/proc/base.c renamed from fs/proc/base.c~breakout-fdinfo +5 -0

+       if (!info)
+               return;
+
+       p += snprintf(info+p, max-p, "pos:\t%lli\n", (long long) file->f_pos);
+       p += snprintf(info+p, max-p, "flags:\t0%o\n", file->f_flags);

Actually, snprintf() is not the right function to use here. scnprintf(), perhaps?

Quoted 4 lines

fs/proc/base.c renamed from fs/proc/base.c~breakout-fdinfo +4 -0

+static void proc_fd_write_info(struct file *file, char *info)
+{
+       int max = PROC_FDINFO_MAX;
+       int p = 0;

fs/proc/base.c out: · line 1645

Quoted 5 lines

fs/proc/base.c renamed from fs/proc/base.c~breakout-fdinfo +5 -0

+       if (!info)
+               return;
+
+       p += snprintf(info+p, max-p, "pos:\t%lli\n", (long long) file->f_pos);
+       p += snprintf(info+p, max-p, "flags:\t0%o\n", file->f_flags);

Actually, snprintf() is not the right function to use here. scnprintf(), perhaps?

Dave Hansen [[email protected]] wrote:

| +int cr_file_supported(struct file *file)
| +{
| +	struct inode *inode = file->f_dentry->d_inode;
| +	struct file_system_type *fs_type = inode->i_sb->s_type;
| +
| +	if (fs_is_cr_able(fs_type))
| +		return 0;

Should this be if (!fs_is_cr_able(fs_type)) ?

Dave Hansen [[email protected]] wrote:

| +int cr_file_supported(struct file *file)
| +{
| +	struct inode *inode = file->f_dentry->d_inode;
| +	struct file_system_type *fs_type = inode->i_sb->s_type;
| +
| +	if (fs_is_cr_able(fs_type))
| +		return 0;

Should this be if (!fs_is_cr_able(fs_type)) ?

Quoted 9 lines · Sukadev Bhattiprolu

Dave Hansen [[email protected]] wrote:

| +int cr_file_supported(struct file *file)
| +{
| +   struct inode *inode = file->f_dentry->d_inode;
| +   struct file_system_type *fs_type = inode->i_sb->s_type;
| +
| +   if (fs_is_cr_able(fs_type))
| +           return 0;

Quoted 1 line

Should this be if (!fs_is_cr_able(fs_type)) ?

Yes. I did find and fix that at some point, but it appears I didn't manage to integrate it into what I sent out.

Quoted 9 lines · Sukadev Bhattiprolu

Dave Hansen [[email protected]] wrote:

| +int cr_file_supported(struct file *file)
| +{
| +   struct inode *inode = file->f_dentry->d_inode;
| +   struct file_system_type *fs_type = inode->i_sb->s_type;
| +
| +   if (fs_is_cr_able(fs_type))
| +           return 0;

Quoted 1 line

Should this be if (!fs_is_cr_able(fs_type)) ?

Yes. I did find and fix that at some point, but it appears I didn't manage to integrate it into what I sent out.

| -int cr_file_supported(struct file *file)
| +typedef int (do_checkpoint_t)(struct file *, struct cr_ctx *,
| +			      struct cr_hdr_fd *);
| +
| +int generic_file_checkpoint(struct file *file, struct cr_ctx *ctx,
| +			 struct cr_hdr_fd *hh)
| +{
| +	/*
| +	 * A NULL hh means to make a trial run not
| +	 * actually writing data.  Just determine
| +	 * if the file is checkpointable.
| +	 */
| +	if (!hh)
| +		return 0;
| +
| +	hh->f_flags = file->f_flags;
| +	hh->f_mode = file->f_mode;
| +	hh->f_pos = file->f_pos;
| +	hh->f_version = file->f_version;
| +	/* FIX: need also file->uid, file->gid, file->f_owner, etc */
| +
| +	return 0;
| +}
| +
| +do_checkpoint_t *cr_file_get_func(struct file *file)
|  {

Do we really need this helper ? IOW do callers need this function pointer itself ? Or can we have a more generic helper that callers can use both check if checkpoint is possible (pass NULL in ctx and hh) and to actually checkpoint. Something like:

	int cr_file_checkpoint(file, ctx, hh)
	{
		int rc = -1;

		if (!cr_fs_checkpointable(fstype))
			return rc;
		
		if (!cr_file_checkpointable(file))
			return rc;

		if (special_file(file))

			return rc;

		op = file->f_op->checkpoint;
		if (!op)
			op = generic_file_checkpoint;

		return (*op)(file, ctx, hh);
	}

|  	struct inode *inode = file->f_dentry->d_inode;
|  	struct file_system_type *fs_type = inode->i_sb->s_type;
| 
| -	if (fs_is_cr_able(fs_type))
| -		return 0;
| +	if (file->f_op->checkpoint)
| +		return file->f_op->checkpoint;
| +
| +	if (!fs_is_cr_able(fs_type))
| +		return NULL;
| 
|  	if (special_file(inode->i_mode))
| -		return 0;
| +		return NULL;
| 
| -	return 1;
| +	return generic_file_checkpoint;
| +}
| +
| +int cr_file_supported(struct file *file)
| +{
| +	do_checkpoint_t *func = cr_file_get_func(file);
| +
| +	if (func)
| +		return !func(file, NULL, NULL);
| +
| +	return 0;
|  }
| 
|  /* cr_write_fd_data - dump the state of a given file pointer */
|  static int cr_write_fd_data(struct cr_ctx *ctx, struct file *file, int parent)
|  {
| +	do_checkpoint_t *ckpt_func;
|  	struct cr_hdr h;
|  	struct cr_hdr_fd *hh = cr_hbuf_get(ctx, sizeof(*hh));
| -	struct dentry *dent = file->f_dentry;
| -	struct inode *inode = dent->d_inode;
| -	enum fd_type fd_type;
|  	int ret;
| 
|  	h.type = CR_HDR_FD_DATA;
|  	h.len = sizeof(*hh);
|  	h.parent = parent;
| 
| -	hh->f_flags = file->f_flags;
| -	hh->f_mode = file->f_mode;
| -	hh->f_pos = file->f_pos;
| -	hh->f_version = file->f_version;
| -	/* FIX: need also file->uid, file->gid, file->f_owner, etc */
| -
| -	switch (inode->i_mode & S_IFMT) {
| -	case S_IFREG:
| -		fd_type = CR_FD_FILE;
| -		break;
| -	case S_IFDIR:
| -		fd_type = CR_FD_DIR;
| -		break;
| -	default:
| -		cr_hbuf_put(ctx, sizeof(*hh));
| -		return -EBADF;
| -	}
| +	ckpt_func = cr_file_get_func(file);
| +	ret = -EBADF;
| +	if (!ckpt_func)
| +		goto out;
| 
| -	/* FIX: check if the file/dir/link is unlinked */
| -	hh->fd_type = fd_type;
| +	ret = ckpt_func(file, ctx, hh);
| +	if (ret)
| +		goto out;

So we can combine these two steps into just one ?

	ret = -EBADF;
	hh->fd_type = fd_type;
	if (cr_file_checkpoint(file, ctx, hh))
		goto out;

| -int cr_file_supported(struct file *file)
| +typedef int (do_checkpoint_t)(struct file *, struct cr_ctx *,
| +			      struct cr_hdr_fd *);
| +
| +int generic_file_checkpoint(struct file *file, struct cr_ctx *ctx,
| +			 struct cr_hdr_fd *hh)
| +{
| +	/*
| +	 * A NULL hh means to make a trial run not
| +	 * actually writing data.  Just determine
| +	 * if the file is checkpointable.
| +	 */
| +	if (!hh)
| +		return 0;
| +
| +	hh->f_flags = file->f_flags;
| +	hh->f_mode = file->f_mode;
| +	hh->f_pos = file->f_pos;
| +	hh->f_version = file->f_version;
| +	/* FIX: need also file->uid, file->gid, file->f_owner, etc */
| +
| +	return 0;
| +}
| +
| +do_checkpoint_t *cr_file_get_func(struct file *file)
|  {

Do we really need this helper ? IOW do callers need this function pointer itself ? Or can we have a more generic helper that callers can use both check if checkpoint is possible (pass NULL in ctx and hh) and to actually checkpoint. Something like:

	int cr_file_checkpoint(file, ctx, hh)
	{
		int rc = -1;

		if (!cr_fs_checkpointable(fstype))
			return rc;
		
		if (!cr_file_checkpointable(file))
			return rc;

		if (special_file(file))

			return rc;

		op = file->f_op->checkpoint;
		if (!op)
			op = generic_file_checkpoint;

		return (*op)(file, ctx, hh);
	}

|  	struct inode *inode = file->f_dentry->d_inode;
|  	struct file_system_type *fs_type = inode->i_sb->s_type;
| 
| -	if (fs_is_cr_able(fs_type))
| -		return 0;
| +	if (file->f_op->checkpoint)
| +		return file->f_op->checkpoint;
| +
| +	if (!fs_is_cr_able(fs_type))
| +		return NULL;
| 
|  	if (special_file(inode->i_mode))
| -		return 0;
| +		return NULL;
| 
| -	return 1;
| +	return generic_file_checkpoint;
| +}
| +
| +int cr_file_supported(struct file *file)
| +{
| +	do_checkpoint_t *func = cr_file_get_func(file);
| +
| +	if (func)
| +		return !func(file, NULL, NULL);
| +
| +	return 0;
|  }
| 
|  /* cr_write_fd_data - dump the state of a given file pointer */
|  static int cr_write_fd_data(struct cr_ctx *ctx, struct file *file, int parent)
|  {
| +	do_checkpoint_t *ckpt_func;
|  	struct cr_hdr h;
|  	struct cr_hdr_fd *hh = cr_hbuf_get(ctx, sizeof(*hh));
| -	struct dentry *dent = file->f_dentry;
| -	struct inode *inode = dent->d_inode;
| -	enum fd_type fd_type;
|  	int ret;
| 
|  	h.type = CR_HDR_FD_DATA;
|  	h.len = sizeof(*hh);
|  	h.parent = parent;
| 
| -	hh->f_flags = file->f_flags;
| -	hh->f_mode = file->f_mode;
| -	hh->f_pos = file->f_pos;
| -	hh->f_version = file->f_version;
| -	/* FIX: need also file->uid, file->gid, file->f_owner, etc */
| -
| -	switch (inode->i_mode & S_IFMT) {
| -	case S_IFREG:
| -		fd_type = CR_FD_FILE;
| -		break;
| -	case S_IFDIR:
| -		fd_type = CR_FD_DIR;
| -		break;
| -	default:
| -		cr_hbuf_put(ctx, sizeof(*hh));
| -		return -EBADF;
| -	}
| +	ckpt_func = cr_file_get_func(file);
| +	ret = -EBADF;
| +	if (!ckpt_func)
| +		goto out;
| 
| -	/* FIX: check if the file/dir/link is unlinked */
| -	hh->fd_type = fd_type;
| +	ret = ckpt_func(file, ctx, hh);
| +	if (ret)
| +		goto out;

So we can combine these two steps into just one ?

	ret = -EBADF;
	hh->fd_type = fd_type;
	if (cr_file_checkpoint(file, ctx, hh))
		goto out;

We have set up sane defaults for how filesystems should be checkpointed. However, as usual in the VFS, there are specialized places that will always need an ability to override these defaults.

This adds a new 'file_operations' function for checkpointing a file. I did this under the assumption that we should have a dirt-simple way to make something (un)checkpointable that fits in with current code.

As you can see in the /dev/null patch in a second, all that we have to do to make something like /dev/null supported is add a single "generic" f_op entry.

We have set up sane defaults for how filesystems should be checkpointed. However, as usual in the VFS, there are specialized places that will always need an ability to override these defaults.

This adds a new 'file_operations' function for checkpointing a file. I did this under the assumption that we should have a dirt-simple way to make something (un)checkpointable that fits in with current code.

As you can see in the /dev/null patch in a second, all that we have to do to make something like /dev/null supported is add a single "generic" f_op entry.

Quoted 10 lines · Dave Hansen

We have set up sane defaults for how filesystems should be checkpointed. However, as usual in the VFS, there are specialized places that will always need an ability to override these defaults.

This adds a new 'file_operations' function for checkpointing a file. I did this under the assumption that we should have a dirt-simple way to make something (un)checkpointable that fits in with current code.

Quoted 3 lines

As you can see in the /dev/null patch in a second, all that we have to do to make something like /dev/null supported is add a single "generic" f_op entry.

Please don't do the fallback to allow checkpointing without file operations. We've never had luck with these fallbacks, and I'm in the process of getting of the last default file operation (llseek, which has a very bad default) currently.

Incidentally that should also allow you to get rid of the per-fs flag by just checking for the presence of the operation to check if checkpointing is allowed.

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

Quoted 10 lines · Dave Hansen

We have set up sane defaults for how filesystems should be checkpointed. However, as usual in the VFS, there are specialized places that will always need an ability to override these defaults.

This adds a new 'file_operations' function for checkpointing a file. I did this under the assumption that we should have a dirt-simple way to make something (un)checkpointable that fits in with current code.

Quoted 3 lines

As you can see in the /dev/null patch in a second, all that we have to do to make something like /dev/null supported is add a single "generic" f_op entry.

Please don't do the fallback to allow checkpointing without file operations. We've never had luck with these fallbacks, and I'm in the process of getting of the last default file operation (llseek, which has a very bad default) currently.

Incidentally that should also allow you to get rid of the per-fs flag by just checking for the presence of the operation to check if checkpointing is allowed.

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

Quoted 3 lines

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

No, I don't have any good concrete ones. The first thing that comes to mind is something like a pipe. We can checkpoint when there's no data, but must refuse when there's data in the pipe. In practice, pipes are fixable, but it is the kind of situation where I expected it to get used.

Quoted 3 lines

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

No, I don't have any good concrete ones. The first thing that comes to mind is something like a pipe. We can checkpoint when there's no data, but must refuse when there's data in the pipe. In practice, pipes are fixable, but it is the kind of situation where I expected it to get used.

Dave Hansen [[email protected]] wrote:

| 
| Introduce a files_struct counter to indicate whether a particular
| file_struct has ever contained a file which can not be
| checkpointed.  This flag is a one-way trip; once it is set, it may
| not be unset.
| 
| We assume at allocation that a new files_struct is clean and may
| be checkpointed.  However, as soon as it has had its files filled
| from its parent's, we check it for real in __scan_files_for_cr().
| At that point, we mark it if it contained any uncheckpointable
| files.

Hmm. Why not just copy ->may_checkpoint setting from parent (or old) files_struct ? If parent is not checkpointable, then child won't be and vice-versa - no ?

Dave Hansen [[email protected]] wrote:

| 
| Introduce a files_struct counter to indicate whether a particular
| file_struct has ever contained a file which can not be
| checkpointed.  This flag is a one-way trip; once it is set, it may
| not be unset.
| 
| We assume at allocation that a new files_struct is clean and may
| be checkpointed.  However, as soon as it has had its files filled
| from its parent's, we check it for real in __scan_files_for_cr().
| At that point, we mark it if it contained any uncheckpointable
| files.

Hmm. Why not just copy ->may_checkpoint setting from parent (or old) files_struct ? If parent is not checkpointable, then child won't be and vice-versa - no ?

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

---

 linux-2.6.git-dave/fs/file.c                  |   19 +++++++++++++++++++
 linux-2.6.git-dave/fs/open.c                  |    5 +++++
 linux-2.6.git-dave/include/linux/checkpoint.h |   14 ++++++++++++++
 linux-2.6.git-dave/include/linux/fdtable.h    |    3 +++
 4 files changed, 41 insertions(+)

diff -puN fs/file.c~track-files_struct-checkpointability fs/file.c

fs/file.c renamed from fs/file.c~track-files_struct-checkpointability +19 -0

@@ -15,6 +15,7 @@
 #include <linux/file.h>
 #include <linux/fdtable.h>
 #include <linux/bitops.h>
+#include <linux/checkpoint.h>
 #include <linux/interrupt.h>
 #include <linux/spinlock.h>
 #include <linux/rcupdate.h>

@@ -285,6 +286,20 @@ static int count_open_files(struct fdtab
 	return i;
 }
 
+static void __scan_files_for_cr(struct files_struct *files)
+{
+	int i;
+
+	for (i = 0; i < files->fdtab.max_fds; i++) {
+		struct file *f = fcheck_files(files, i);
+		if (!f)
+			continue;
+		if (cr_file_supported(f))
+			continue;
+		files_deny_checkpointing(files);
+	}
+}
+
 /*
  * Allocate a new files structure and copy contents from the
  * passed in files structure.

@@ -303,6 +318,9 @@ struct files_struct *dup_fd(struct files
 		goto out;
 
 	atomic_set(&newf->count, 1);
+#ifdef CONFIG_CHECKPOINT_RESTART
+	newf->may_checkpoint = 1;
+#endif
 
 	spin_lock_init(&newf->file_lock);
 	newf->next_fd = 0;

@@ -396,6 +414,7 @@ struct files_struct *dup_fd(struct files
 
 	rcu_assign_pointer(newf->fdt, new_fdt);
 
+	__scan_files_for_cr(newf);
 	return newf;
 
 out_release:

diff -puN fs/open.c~track-files_struct-checkpointability fs/open.c

fs/open.c renamed from fs/open.c~track-files_struct-checkpointability +5 -0

@@ -29,6 +29,7 @@
 #include <linux/rcupdate.h>
 #include <linux/audit.h>
 #include <linux/falloc.h>
+#include <linux/checkpoint.h>
 
 int vfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 {

@@ -1015,6 +1016,10 @@ void fd_install(unsigned int fd, struct 
 {
 	struct files_struct *files = current->files;
 	struct fdtable *fdt;
+
+	if (!cr_file_supported(file))
+		files_deny_checkpointing(files);
+
 	spin_lock(&files->file_lock);
 	fdt = files_fdtable(files);
 	BUG_ON(fdt->fd[fd] != NULL);

diff -puN include/linux/checkpoint.h~track-files_struct-checkpointability include/linux/checkpoint.h

include/linux/checkpoint.h renamed from include/linux/checkpoint.h~track-files_struct-checkpointability +1 -0

@@ -12,6 +12,7 @@
 
 #include <linux/path.h>
 #include <linux/fs.h>
+#include <linux/fdtable.h>
 
 #ifdef CONFIG_CHECKPOINT_RESTART
 

@@ -102,6 +103,18 @@ extern int cr_read_files(struct cr_ctx *
 

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

---

 linux-2.6.git-dave/fs/file.c                  |   19 +++++++++++++++++++
 linux-2.6.git-dave/fs/open.c                  |    5 +++++
 linux-2.6.git-dave/include/linux/checkpoint.h |   14 ++++++++++++++
 linux-2.6.git-dave/include/linux/fdtable.h    |    3 +++
 4 files changed, 41 insertions(+)

diff -puN fs/file.c~track-files_struct-checkpointability fs/file.c

fs/file.c renamed from fs/file.c~track-files_struct-checkpointability +19 -0

@@ -15,6 +15,7 @@
 #include <linux/file.h>
 #include <linux/fdtable.h>
 #include <linux/bitops.h>
+#include <linux/checkpoint.h>
 #include <linux/interrupt.h>
 #include <linux/spinlock.h>
 #include <linux/rcupdate.h>

@@ -285,6 +286,20 @@ static int count_open_files(struct fdtab
 	return i;
 }
 
+static void __scan_files_for_cr(struct files_struct *files)
+{
+	int i;
+
+	for (i = 0; i < files->fdtab.max_fds; i++) {
+		struct file *f = fcheck_files(files, i);
+		if (!f)
+			continue;
+		if (cr_file_supported(f))
+			continue;
+		files_deny_checkpointing(files);
+	}
+}
+
 /*
  * Allocate a new files structure and copy contents from the
  * passed in files structure.

@@ -303,6 +318,9 @@ struct files_struct *dup_fd(struct files
 		goto out;
 
 	atomic_set(&newf->count, 1);
+#ifdef CONFIG_CHECKPOINT_RESTART
+	newf->may_checkpoint = 1;
+#endif
 
 	spin_lock_init(&newf->file_lock);
 	newf->next_fd = 0;

@@ -396,6 +414,7 @@ struct files_struct *dup_fd(struct files
 
 	rcu_assign_pointer(newf->fdt, new_fdt);
 
+	__scan_files_for_cr(newf);
 	return newf;
 
 out_release:

diff -puN fs/open.c~track-files_struct-checkpointability fs/open.c

fs/open.c renamed from fs/open.c~track-files_struct-checkpointability +5 -0

@@ -29,6 +29,7 @@
 #include <linux/rcupdate.h>
 #include <linux/audit.h>
 #include <linux/falloc.h>
+#include <linux/checkpoint.h>
 
 int vfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 {

@@ -1015,6 +1016,10 @@ void fd_install(unsigned int fd, struct 
 {
 	struct files_struct *files = current->files;
 	struct fdtable *fdt;
+
+	if (!cr_file_supported(file))
+		files_deny_checkpointing(files);
+
 	spin_lock(&files->file_lock);
 	fdt = files_fdtable(files);
 	BUG_ON(fdt->fd[fd] != NULL);

diff -puN include/linux/checkpoint.h~track-files_struct-checkpointability include/linux/checkpoint.h

include/linux/checkpoint.h renamed from include/linux/checkpoint.h~track-files_struct-checkpointability +1 -0

@@ -12,6 +12,7 @@
 
 #include <linux/path.h>
 #include <linux/fs.h>
+#include <linux/fdtable.h>
 
 #ifdef CONFIG_CHECKPOINT_RESTART
 

@@ -102,6 +103,18 @@ extern int cr_read_files(struct cr_ctx *
 

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

Quoted 12 lines · Dave Hansen

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

Quoted 5 lines

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

Quoted 12 lines · Dave Hansen

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

Quoted 5 lines

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

Quoted 12 lines · Dave Hansen

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

Quoted 5 lines

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

Quoted 12 lines · Dave Hansen

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

Quoted 5 lines

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

Quoted 6 lines · On Mon, 2 Mar 2009 07:37:54 -0600 "Serge E. Hallyn"…

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

Quoted 3 lines

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

With respect to /proc/$x/* where $x is the pid the restarted task wants, is that not a chicken-and-egg problem?

Quoted 6 lines · On Mon, 2 Mar 2009 07:37:54 -0600 "Serge E. Hallyn" <[email protected]> wrote:

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

Quoted 3 lines

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

With respect to /proc/$x/* where $x is the pid the restarted task wants, is that not a chicken-and-egg problem?

Quoted 25 lines · On Mon, 2 Mar 2009 07:37:54 -0600 "Serge E. Hallyn"…

Quoted 12 lines · Dave Hansen

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

Quoted 5 lines

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

Quoted 3 lines

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

With respect to /proc/$x/* where $x is the pid the restarted task wants, is that not a chicken-and-egg problem?

Quoted 25 lines · On Mon, 2 Mar 2009 07:37:54 -0600 "Serge E. Hallyn" <[email protected]> wrote:

Quoted 12 lines · Dave Hansen

Introduce a files_struct counter to indicate whether a particular file_struct has ever contained a file which can not be checkpointed. This flag is a one-way trip; once it is set, it may not be unset.

We assume at allocation that a new files_struct is clean and may be checkpointed. However, as soon as it has had its files filled from its parent's, we check it for real in __scan_files_for_cr(). At that point, we mark it if it contained any uncheckpointable files.

Quoted 5 lines

We also check each 'struct file' when it is installed in a fd slot. This way, if anyone open()s or managed to dup() an unsuppored file, we can catch it.

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

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

Quoted 3 lines

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

With respect to /proc/$x/* where $x is the pid the restarted task wants, is that not a chicken-and-egg problem?

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

Quoted 12 lines · Nathan Lynch

Quoted 9 lines · On Mon, 2 Mar 2009 07:37:54 -0600 "Serge E. Hallyn"…

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

Quoted 2 lines

With respect to /proc/$x/* where $x is the pid the restarted task wants, is that not a chicken-and-egg problem?

Do you mean that we have to go look into /proc to figure out which task we want before we can checkpoint it? That makes the process *doing* the checkpoint uncheckpointable, but no the process being examined.

Quoted 12 lines · Nathan Lynch

Quoted 9 lines · On Mon, 2 Mar 2009 07:37:54 -0600 "Serge E. Hallyn" <[email protected]> wrote:

So on a practical note, Ingo's scheme appears to be paying off. In order for any program's files_struct to be checkpointable right now, it must be statically compiled, else ld.so (I assume) looks up /proc/$$/status. So since proc is not checkpointable, the result is irreversibly non-checkpointable.

So... does it make sense to mark proc as checkpointable? Do we reasonably assume that the same procfile will be available at restart?

Quoted 2 lines

With respect to /proc/$x/* where $x is the pid the restarted task wants, is that not a chicken-and-egg problem?

Do you mean that we have to go look into /proc to figure out which task we want before we can checkpoint it? That makes the process *doing* the checkpoint uncheckpointable, but no the process being examined.

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

Quoted 6 lines · Nathan Lynch

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

Heh, that's a good one.

It does mean that we can't do restore like this:

	for_each_cr_task()
		restore_task_struct()
		restore_files()
		...

We have to do:

	for_each_cr_task()
		restore_task_struct()
	for_each_cr_task()
		restore_files()

-- Dave

Quoted 6 lines · Nathan Lynch

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

Heh, that's a good one.

It does mean that we can't do restore like this:

	for_each_cr_task()
		restore_task_struct()
		restore_files()
		...

We have to do:

	for_each_cr_task()
		restore_task_struct()
	for_each_cr_task()
		restore_files()

-- Dave

Which is what we actually do, right?

Actually we have userspace create the tasks first, and then each task calls sys_restart which does restore_files().

Restarting of multiple processes expects all restarting tasks to call sys_restart(). Once inside the system call, each task will restart itself at the same order that they were saved. The internals of the syscall will take care of in-kernel synchronization bewteen tasks.

Which is what we actually do, right?

Actually we have userspace create the tasks first, and then each task calls sys_restart which does restore_files().

Restarting of multiple processes expects all restarting tasks to call sys_restart(). Once inside the system call, each task will restart itself at the same order that they were saved. The internals of the syscall will take care of in-kernel synchronization bewteen tasks.

Quoted 17 lines · Dave Hansen

Quoted 6 lines · Nathan Lynch

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

Heh, that's a good one.

It does mean that we can't do restore like this:

	for_each_cr_task()
		restore_task_struct()
		restore_files()
		...

Quoted 7 lines

We have to do:

	for_each_cr_task()
		restore_task_struct()
	for_each_cr_task()
		restore_files()

Which is what we actually do, right?

Quoted 18 lines · Serge E. Hallyn

Quoted 17 lines · Dave Hansen

Quoted 6 lines · Nathan Lynch

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

Heh, that's a good one.

It does mean that we can't do restore like this:

	for_each_cr_task()
		restore_task_struct()
		restore_files()
		...

Quoted 8 lines

Quoted 7 lines

We have to do:

	for_each_cr_task()
		restore_task_struct()
	for_each_cr_task()
		restore_files()

Which is what we actually do, right?

OK, I have a really evil one.

What if task 1234 does:

	open(O_RDONLY, "/proc/5678/fdinfo/44");

and task 5678 does:

	open(O_RDONLY, "/proc/5678/fdinfo/55");

Quoted 18 lines · Serge E. Hallyn

Quoted 17 lines · Dave Hansen

Quoted 6 lines · Nathan Lynch

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

Heh, that's a good one.

It does mean that we can't do restore like this:

	for_each_cr_task()
		restore_task_struct()
		restore_files()
		...

Quoted 8 lines

Quoted 7 lines

We have to do:

	for_each_cr_task()
		restore_task_struct()
	for_each_cr_task()
		restore_files()

Which is what we actually do, right?

OK, I have a really evil one.

What if task 1234 does:

	open(O_RDONLY, "/proc/5678/fdinfo/44");

and task 5678 does:

	open(O_RDONLY, "/proc/5678/fdinfo/55");

Quoted 3 lines · Christoph Hellwig

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

I'm still reaching here...

I was thinking of /proc. Opening your own /proc/$$/* would certainly be considered OK. But, doing it for some other process not in your pid namespace would not be OK and would not be checkpointable.

I know we're not quite in real-life territory here, yet, but I'm still thinking.

Quoted 3 lines · Christoph Hellwig

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

I'm still reaching here...

I was thinking of /proc. Opening your own /proc/$$/* would certainly be considered OK. But, doing it for some other process not in your pid namespace would not be OK and would not be checkpointable.

I know we're not quite in real-life territory here, yet, but I'm still thinking.

Dave Hansen [[email protected]] wrote:

| 
| Introduce a files_struct counter to indicate whether a particular
| file_struct has ever contained a file which can not be
| checkpointed.  This flag is a one-way trip; once it is set, it may
| not be unset.
| 
| We assume at allocation that a new files_struct is clean and may
| be checkpointed.  However, as soon as it has had its files filled
| from its parent's, we check it for real in __scan_files_for_cr().
| At that point, we mark it if it contained any uncheckpointable
| files.

Hmm. Why not just copy ->may_checkpoint setting from parent (or old) files_struct ? If parent is not checkpointable, then child won't be and vice-versa - no ?

| +static void __scan_files_for_cr(struct files_struct *files)
| +{
| +	int i;
| +
| +	for (i = 0; i < files->fdtab.max_fds; i++) {
| +		struct file *f = fcheck_files(files, i);
| +		if (!f)
| +			continue;
| +		if (cr_file_supported(f))
| +			continue;
| +		files_deny_checkpointing(files);
| +	}
| +}
| +

A version of __scan_files_for_cr() for CONFIG_CHECKPOINT_RESTART=n or...

|  /*
|   * Allocate a new files structure and copy contents from the
|   * passed in files structure.
| @@ -303,6 +318,9 @@ struct files_struct *dup_fd(struct files
|  		goto out;
| 
|  	atomic_set(&newf->count, 1);
| +#ifdef CONFIG_CHECKPOINT_RESTART
| +	newf->may_checkpoint = 1;
| +#endif
| 
|  	spin_lock_init(&newf->file_lock);
|  	newf->next_fd = 0;
| @@ -396,6 +414,7 @@ struct files_struct *dup_fd(struct files
| 
|  	rcu_assign_pointer(newf->fdt, new_fdt);
| 
| +	__scan_files_for_cr(newf);

... #ifdef CONFIG_CHECKPOINT_RESTART here ?

Dave Hansen [[email protected]] wrote:

| 
| Introduce a files_struct counter to indicate whether a particular
| file_struct has ever contained a file which can not be
| checkpointed.  This flag is a one-way trip; once it is set, it may
| not be unset.
| 
| We assume at allocation that a new files_struct is clean and may
| be checkpointed.  However, as soon as it has had its files filled
| from its parent's, we check it for real in __scan_files_for_cr().
| At that point, we mark it if it contained any uncheckpointable
| files.

Hmm. Why not just copy ->may_checkpoint setting from parent (or old) files_struct ? If parent is not checkpointable, then child won't be and vice-versa - no ?

| +static void __scan_files_for_cr(struct files_struct *files)
| +{
| +	int i;
| +
| +	for (i = 0; i < files->fdtab.max_fds; i++) {
| +		struct file *f = fcheck_files(files, i);
| +		if (!f)
| +			continue;
| +		if (cr_file_supported(f))
| +			continue;
| +		files_deny_checkpointing(files);
| +	}
| +}
| +

A version of __scan_files_for_cr() for CONFIG_CHECKPOINT_RESTART=n or...

|  /*
|   * Allocate a new files structure and copy contents from the
|   * passed in files structure.
| @@ -303,6 +318,9 @@ struct files_struct *dup_fd(struct files
|  		goto out;
| 
|  	atomic_set(&newf->count, 1);
| +#ifdef CONFIG_CHECKPOINT_RESTART
| +	newf->may_checkpoint = 1;
| +#endif
| 
|  	spin_lock_init(&newf->file_lock);
|  	newf->next_fd = 0;
| @@ -396,6 +414,7 @@ struct files_struct *dup_fd(struct files
| 
|  	rcu_assign_pointer(newf->fdt, new_fdt);
| 
| +	__scan_files_for_cr(newf);

... #ifdef CONFIG_CHECKPOINT_RESTART here ?

Quoted 17 lines · Serge E. Hallyn

Quoted 16 lines · Dave Hansen

Quoted 6 lines · Nathan Lynch

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

Heh, that's a good one.

It does mean that we can't do restore like this:

	for_each_cr_task()
		restore_task_struct()
		restore_files()
		...

Quoted 8 lines

Quoted 7 lines

We have to do:

	for_each_cr_task()
		restore_task_struct()
	for_each_cr_task()
		restore_files()

Which is what we actually do, right?

OK, I have a really evil one.

What if task 1234 does:

	open(O_RDONLY, "/proc/5678/fdinfo/44");

and task 5678 does:

	open(O_RDONLY, "/proc/5678/fdinfo/55");

There is no right order.

The only right way I can think to do it is that we have to loop on the restore and defer files that we can't seem to find right now, hoping that they'll show up as the restore progresses.

Basically:

	for_each_cr_task()
		deferred_files = restore_files()
retry:
	making_progress = 0
	for_each(deferred_file)
		restore(deferred_file)
	if (making_progress)
		goto retry;

Quoted 17 lines · Serge E. Hallyn

Quoted 16 lines · Dave Hansen

Quoted 6 lines · Nathan Lynch

No.. I mean what if a process 1234 does

f = fopen("/proc/1234/stat", "r");

and is then checkpointed. Can that path be resolved during restart, before pid 1234 is alive?

Heh, that's a good one.

It does mean that we can't do restore like this:

	for_each_cr_task()
		restore_task_struct()
		restore_files()
		...

Quoted 8 lines

Quoted 7 lines

We have to do:

	for_each_cr_task()
		restore_task_struct()
	for_each_cr_task()
		restore_files()

Which is what we actually do, right?

OK, I have a really evil one.

What if task 1234 does:

	open(O_RDONLY, "/proc/5678/fdinfo/44");

and task 5678 does:

	open(O_RDONLY, "/proc/5678/fdinfo/55");

There is no right order.

The only right way I can think to do it is that we have to loop on the restore and defer files that we can't seem to find right now, hoping that they'll show up as the restore progresses.

Basically:

	for_each_cr_task()
		deferred_files = restore_files()
retry:
	making_progress = 0
	for_each(deferred_file)
		restore(deferred_file)
	if (making_progress)
		goto retry;

Quoted 11 lines · Dave Hansen

Quoted 3 lines · Christoph Hellwig

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

I'm still reaching here...

I was thinking of /proc. Opening your own /proc/$$/* would certainly be considered OK. But, doing it for some other process not in your pid namespace would not be OK and would not be checkpointable.

Quoted 2 lines

I know we're not quite in real-life territory here, yet, but I'm still thinking.

That mighr be a good enough excuse, I was just wondering what the use case was.

Quoted 11 lines · Dave Hansen

Quoted 3 lines · Christoph Hellwig

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

I'm still reaching here...

I was thinking of /proc. Opening your own /proc/$$/* would certainly be considered OK. But, doing it for some other process not in your pid namespace would not be OK and would not be checkpointable.

Quoted 2 lines

I know we're not quite in real-life territory here, yet, but I'm still thinking.

That mighr be a good enough excuse, I was just wondering what the use case was.

Quoted 11 lines · Christoph Hellwig

Quoted 10 lines · Dave Hansen

Quoted 3 lines · Christoph Hellwig

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

I'm still reaching here...

I was thinking of /proc. Opening your own /proc/$$/* would certainly be considered OK. But, doing it for some other process not in your pid namespace would not be OK and would not be checkpointable.

Quoted 4 lines

Quoted 2 lines

I know we're not quite in real-life territory here, yet, but I'm still thinking.

That mighr be a good enough excuse, I was just wondering what the use case was.

I just thought of another one: unlinked files and directories. They're a pain to checkpoint and won't be supported for a while. Holding open an unlinked file would make a process uncheckpointable for a bit.

-- Dave

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

Quoted 11 lines · Christoph Hellwig

Quoted 10 lines · Dave Hansen

Quoted 3 lines · Christoph Hellwig

Also the double-use of the op seem not very nice to me. Is there any real life use case were you would have the operation on a file but sometimes not allow checkpoiting?

I'm still reaching here...

I was thinking of /proc. Opening your own /proc/$$/* would certainly be considered OK. But, doing it for some other process not in your pid namespace would not be OK and would not be checkpointable.

Quoted 4 lines

Quoted 2 lines

I know we're not quite in real-life territory here, yet, but I'm still thinking.

That mighr be a good enough excuse, I was just wondering what the use case was.

I just thought of another one: unlinked files and directories. They're a pain to checkpoint and won't be supported for a while. Holding open an unlinked file would make a process uncheckpointable for a bit.

-- Dave

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