linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Helsley <matthltc@us.ibm.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Oren Laadan <orenl@cs.columbia.edu>,
	linux-fsdevel@vger.kernel.org,
	containers@lists.linux-foundation.org,
	Matt Helsley <matthltc@us.ibm.com>,
	Andreas Dilger <adilger@sun.com>
Subject: Re: [C/R v20][PATCH 37/96] c/r: introduce new 'file_operations': ->checkpoint, ->collect()
Date: Mon, 22 Mar 2010 03:16:35 -0700	[thread overview]
Message-ID: <20100322101635.GC20796@count0.beaverton.ibm.com> (raw)
In-Reply-To: <20100322063428.GE17637@laptop>

On Mon, Mar 22, 2010 at 05:34:28PM +1100, Nick Piggin wrote:
> On Thu, Mar 18, 2010 at 08:59:46PM -0400, Oren Laadan wrote:
> > While we assume all normal files and directories can be checkpointed,
> > there are, as usual in the VFS, specialized places that will always
> > need an ability to override these defaults. Although we could do this
> > completely in the checkpoint code, that would bitrot quickly.
> > 
> > This adds a new 'file_operations' function for checkpointing a file.
> > It is assumed that there should be a dirt-simple way to make something
> > (un)checkpointable that fits in with current code.
> > 
> > As you can see in the ext[234] patches down the road, all that we have
> > to do to make something simple be supported is add a single "generic"
> > f_op entry.
> > 
> > Also adds a new 'file_operations' function for 'collecting' a file for
> > leak-detection during full-container checkpoint. This is useful for
> > those files that hold references to other "collectable" objects. Two
> > examples are pty files that point to corresponding tty objects, and
> > eventpoll files that refer to the files they are monitoring.
> > 
> > Finally, this patch introduces vfs_fcntl() so that it can be called
> > from restart (see patch adding restart of files).
> > 
> > Changelog[v17]
> >   - Introduce 'collect' method
> > Changelog[v17]
> >   - Forward-declare 'ckpt_ctx' et-al, don't use checkpoint_types.h
> > 
> > Signed-off-by: Oren Laadan <orenl@cs.columbia.edu>
> > Acked-by: Serge E. Hallyn <serue@us.ibm.com>
> > Tested-by: Serge E. Hallyn <serue@us.ibm.com>
> > ---
> >  fs/fcntl.c         |   21 +++++++++++++--------
> >  include/linux/fs.h |    7 +++++++
> >  2 files changed, 20 insertions(+), 8 deletions(-)
> > 
> > diff --git a/fs/fcntl.c b/fs/fcntl.c
> > index 97e01dc..e1f02ca 100644
> > --- a/fs/fcntl.c
> > +++ b/fs/fcntl.c
> > @@ -418,6 +418,18 @@ static long do_fcntl(int fd, unsigned int cmd, unsigned long arg,
> >  	return err;
> >  }
> >  
> > +int vfs_fcntl(int fd, unsigned int cmd, unsigned long arg, struct file *filp)
> > +{
> > +	int err;
> > +
> > +	err = security_file_fcntl(filp, cmd, arg);
> > +	if (err)
> > +		goto out;
> > +	err = do_fcntl(fd, cmd, arg, filp);
> > + out:
> > +	return err;
> > +}
> > +
> >  SYSCALL_DEFINE3(fcntl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
> >  {	
> >  	struct file *filp;
> > @@ -427,14 +439,7 @@ SYSCALL_DEFINE3(fcntl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
> >  	if (!filp)
> >  		goto out;
> >  
> > -	err = security_file_fcntl(filp, cmd, arg);
> > -	if (err) {
> > -		fput(filp);
> > -		return err;
> > -	}
> > -
> > -	err = do_fcntl(fd, cmd, arg, filp);
> > -
> > +	err = vfs_fcntl(fd, cmd, arg, filp);
> >   	fput(filp);
> >  out:
> >  	return err;
> 
> There is no point combining these two logically distinct patches.

Good point.

> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 6c08df2..65ebec5 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -394,6 +394,7 @@ struct kstatfs;
> >  struct vm_area_struct;
> >  struct vfsmount;
> >  struct cred;
> > +struct ckpt_ctx;
> >  
> >  extern void __init inode_init(void);
> >  extern void __init inode_init_early(void);
> > @@ -1093,6 +1094,8 @@ struct file_lock {
> >  
> >  #include <linux/fcntl.h>
> >  
> > +extern int vfs_fcntl(int fd, unsigned cmd, unsigned long arg, struct file *fp);
> > +
> >  extern void send_sigio(struct fown_struct *fown, int fd, int band);
> >  
> >  #ifdef CONFIG_FILE_LOCKING
> > @@ -1504,6 +1507,8 @@ struct file_operations {
> >  	ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
> >  	ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
> >  	int (*setlease)(struct file *, long, struct file_lock **);
> > +	int (*checkpoint)(struct ckpt_ctx *, struct file *);
> > +	int (*collect)(struct ckpt_ctx *, struct file *);
> >  };
> >  
> >  struct inode_operations {
> 
> You didn't add any documentation for this (unless it is in a following
> patch, which it shouldn't be).

Another good point -- we should have added that to
Documentation/filesystems/vfs.txt

> 
> > @@ -2313,6 +2318,8 @@ void inode_sub_bytes(struct inode *inode, loff_t bytes);
> >  loff_t inode_get_bytes(struct inode *inode);
> >  void inode_set_bytes(struct inode *inode, loff_t bytes);
> >  
> > +#define generic_file_checkpoint NULL
> > +
> >  extern int vfs_readdir(struct file *, filldir_t, void *);
> >  
> >  extern int vfs_stat(char __user *, struct kstat *);
> 
> Hmm, what does generic_file_checkpoint mean? A NULL checkpoint op means
> that checkpointing is allowed, and no action is required? Shouldn't it
> be an opt-in operation, where NULL means not allowed?

generic_file_checkpoint is for files that have a seek operation and can be
backed up or restored with a simple copy.

A NULL checkpoint op means "not allowed" as you thought it should. What
gave you the impression it was otherwise? Here's the relevant snippet
from checkpoint/files.c:

/* checkpoint callback for file pointer */
int checkpoint_file(struct ckpt_ctx *ctx, void *ptr)
{
        struct file *file = (struct file *) ptr;
        int ret;

        if (!file->f_op || !file->f_op->checkpoint) {
                ckpt_err(ctx, -EBADF, "%(T)%(P)%(V)f_op lacks checkpoint\n",
                               file, file->f_op);
                return -EBADF;
        }

> Either way, I don't know if you need to have this #define, provided you
> have sufficient documentation.

We need it (or a suitable replacement) to avoid adding #ifdef around
assignments to the operation in every filesystem. It's used if
CONFIG_CHECKPOINT is not defined.

Thanks for the review.

Cheers,
	-Matt Helsley

  reply	other threads:[~2010-03-22 10:16 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19  0:59 [C/R v20][PATCH 00/96] Linux Checkpoint-Restart - v20 Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 20/96] c/r: make file_pos_read/write() public Oren Laadan
2010-03-22  6:31   ` Nick Piggin
2010-03-23  0:12     ` Oren Laadan
2010-03-23  0:43       ` Nick Piggin
2010-03-23  0:56         ` Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 37/96] c/r: introduce new 'file_operations': ->checkpoint, ->collect() Oren Laadan
2010-03-22  6:34   ` Nick Piggin
2010-03-22 10:16     ` Matt Helsley [this message]
2010-03-22 11:00       ` Nick Piggin
2010-03-19  0:59 ` [C/R v20][PATCH 38/96] c/r: dump open file descriptors Oren Laadan
2010-03-19 23:19   ` Andreas Dilger
2010-03-20  4:43     ` Matt Helsley
2010-03-21 17:27       ` Jamie Lokier
2010-03-21 19:40         ` Serge E. Hallyn
2010-03-21 20:58           ` Daniel Lezcano
2010-03-21 21:36             ` Oren Laadan
     [not found]               ` <4BA6914D.8040007-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-21 23:31                 ` xing lin
2010-03-22  8:40               ` Daniel Lezcano
2010-03-22  2:12             ` Matt Helsley
2010-03-22 13:51               ` Jamie Lokier
2010-03-22 23:18               ` Andreas Dilger
2010-03-22  1:06         ` Matt Helsley
2010-03-22  2:20           ` Jamie Lokier
2010-03-22  3:37             ` Matt Helsley
2010-03-22 14:13               ` Jamie Lokier
2010-03-22  2:55           ` Serge E. Hallyn
     [not found]   ` <1268960401-16680-4-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-03-22 10:30     ` Nick Piggin
2010-03-22 13:22       ` Matt Helsley
2010-03-22 13:38         ` Nick Piggin
2010-03-19  0:59 ` [C/R v20][PATCH 39/96] c/r: restore " Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 40/96] c/r: introduce method '->checkpoint()' in struct vm_operations_struct Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 44/96] c/r: add generic '->checkpoint' f_op to ext fses Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 45/96] c/r: add generic '->checkpoint()' f_op to simple devices Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 46/96] c/r: add checkpoint operation for opened files of generic filesystems Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 50/96] splice: export pipe/file-to-pipe/file functionality Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 51/96] c/r: support for open pipes Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 52/96] c/r: checkpoint and restore FIFOs Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 53/96] c/r: refuse to checkpoint if monitoring directories with dnotify Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 66/96] c/r: restore file->f_cred Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 82/96] c/r: checkpoint/restart epoll sets Oren Laadan
2010-03-19  0:59 ` [C/R v20][PATCH 83/96] c/r: checkpoint/restart eventfd Oren Laadan
2010-03-19  1:00 ` [C/R v20][PATCH 84/96] c/r: restore task fs_root and pwd (v3) Oren Laadan
2010-03-19  1:00 ` [C/R v20][PATCH 85/96] c/r: preliminary support mounts namespace Oren Laadan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100322101635.GC20796@count0.beaverton.ibm.com \
    --to=matthltc@us.ibm.com \
    --cc=adilger@sun.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=orenl@cs.columbia.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).