mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: "Oren Laadan" <orenl@cs.columbia.edu>
Cc: dave@linux.vnet.ibm.com, arnd@arndb.de, jeremy@goop.org,
	linux-kernel@vger.kernel.org,
	containers@lists.linux-foundation.org
Subject: Re: [RFC v4][PATCH 8/9] File descriprtors (dump)
Date: Tue, 9 Sep 2008 10:23:25 +0200	[thread overview]
Message-ID: <19f34abd0809090123y36c51395pfa694799f7a2afb@mail.gmail.com> (raw)
In-Reply-To: <1220946154-15174-9-git-send-email-orenl@cs.columbia.edu>

Hi,

Below are some concerns, I would be grateful for explanations (or
pointers if I missed them before).

On Tue, Sep 9, 2008 at 9:42 AM, Oren Laadan <orenl@cs.columbia.edu> wrote:
> +/* 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)
> +{
> +       struct cr_hdr h;
> +       struct cr_hdr_fd_data *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_uid = file->f_uid;
> +       hh->f_gid = file->f_gid;
> +       hh->f_version = file->f_version;
> +       /* FIX: need also file->f_owner */
> +
> +       switch (inode->i_mode & S_IFMT) {
> +       case S_IFREG:
> +               fd_type = CR_FD_FILE;
> +               break;
> +       case S_IFDIR:
> +               fd_type = CR_FD_DIR;
> +               break;
> +       case S_IFLNK:
> +               fd_type = CR_FD_LINK;
> +               break;
> +       default:
> +               return -EBADF;
> +       }

Should cr_hbuf_put() come before the return here?

As far as I've understood, "leaking" the buffer size/data isn't
critical (1. because it's just some extra space, and/or 2. the buffer
is discarded on error anyway). The code looks really unbalanced
without it, though. I guess it should at least be documented?

> +
> +       /* FIX: check if the file/dir/link is unlinked */
> +       hh->fd_type = fd_type;
> +
> +       ret = cr_write_obj(ctx, &h, hh);
> +       cr_hbuf_put(ctx, sizeof(*hh));
> +       if (ret < 0)
> +               return ret;
> +
> +       return cr_write_fname(ctx, &file->f_path, ctx->vfsroot);
> +}
> +
> +/**
> + * cr_write_fd_ent - dump the state of a given file descriptor
> + * @ctx: checkpoint context
> + * @files: files_struct pointer
> + * @fd: file descriptor
> + *
> + * Save the state of the file descriptor; look up the actual file pointer
> + * in the hash table, and if found save the matching objref, otherwise call
> + * cr_write_fd_data to dump the file pointer too.
> + */
> +static int
> +cr_write_fd_ent(struct cr_ctx *ctx, struct files_struct *files, int fd)
> +{
> +       struct cr_hdr h;
> +       struct cr_hdr_fd_ent *hh = cr_hbuf_get(ctx, sizeof(*hh));
> +       struct file *file = NULL;
> +       struct fdtable *fdt;
> +       int coe, objref, new, ret;
> +
> +       rcu_read_lock();
> +       fdt = files_fdtable(files);
> +       file = fcheck_files(files, fd);
> +       if (file) {
> +               coe = FD_ISSET(fd, fdt->close_on_exec);
> +               get_file(file);
> +       }
> +       rcu_read_unlock();
> +
> +       /* sanity check (although this shouldn't happen) */
> +       if (!file)
> +               return -EBADF;
> +
> +       new = cr_obj_add_ptr(ctx, (void *) file, &objref, CR_OBJ_FILE, 0);
> +       cr_debug("fd %d objref %d file %p c-o-e %d)\n", fd, objref, file, coe);
> +
> +       if (new < 0)
> +               return new;

fput() and/or cr_hbuf_put()?

> +
> +       h.type = CR_HDR_FD_ENT;
> +       h.len = sizeof(*hh);
> +       h.parent = 0;
> +
> +       hh->objref = objref;
> +       hh->fd = fd;
> +       hh->close_on_exec = coe;
> +
> +       ret = cr_write_obj(ctx, &h, hh);
> +       cr_hbuf_put(ctx, sizeof(*hh));
> +       if (ret < 0)
> +               return ret;
> +
> +       /* new==1 if-and-only-if file was newly added to hash */
> +       if (new)
> +               ret = cr_write_fd_data(ctx, file, objref);
> +
> +       fput(file);
> +       return ret;
> +}
> +
> +int cr_write_files(struct cr_ctx *ctx, struct task_struct *t)
> +{
> +       struct cr_hdr h;
> +       struct cr_hdr_files *hh = cr_hbuf_get(ctx, sizeof(*hh));
> +       struct files_struct *files;
> +       int *fdtable;
> +       int nfds, n, ret;
> +
> +       h.type = CR_HDR_FILES;
> +       h.len = sizeof(*hh);
> +       h.parent = task_pid_vnr(t);
> +
> +       files = get_files_struct(t);
> +
> +       hh->objref = 0; /* will be meaningful with multiple processes */
> +
> +       nfds = cr_scan_fds(files, &fdtable);
> +       if (nfds < 0) {
> +               ret = nfds;

cr_hbuf_put()?

> +               goto out;
> +       }
> +
> +       hh->nfds = nfds;
> +
> +       ret = cr_write_obj(ctx, &h, hh);
> +       cr_hbuf_put(ctx, sizeof(*hh));
> +       if (ret < 0)
> +               goto clean;
> +
> +       cr_debug("nfds %d\n", nfds);
> +       for (n = 0; n < nfds; n++) {
> +               ret = cr_write_fd_ent(ctx, files, n);
> +               if (ret < 0)
> +                       break;
> +       }
> +
> + clean:
> +       kfree(fdtable);
> + out:
> +       put_files_struct(files);
> +
> +       return ret;
> +}


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

  parent reply	other threads:[~2008-09-09  8:23 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-09  7:42 [RFC v4][PATCH 0/9] Kernel based checkpoint/restart` Oren Laadan
2008-09-09  7:42 ` [RFC v4][PATCH 1/9] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-09-09  7:42 ` [RFC v4][PATCH 2/9] General infrastructure for checkpoint restart Oren Laadan
2008-09-10  6:10   ` MinChan Kim
2008-09-10 18:36     ` Oren Laadan
2008-09-10 22:54       ` MinChan Kim
2008-09-11  6:44         ` Oren Laadan
2008-09-09  7:42 ` [RFC v4][PATCH 3/9] x86 support for checkpoint/restart Oren Laadan
2008-09-09  8:17   ` Ingo Molnar
2008-09-09 23:23     ` Oren Laadan
2008-09-09  7:42 ` [RFC v4][PATCH 4/9] Memory management (dump) Oren Laadan
2008-09-09  9:22   ` Vegard Nossum
2008-09-10  7:51   ` MinChan Kim
2008-09-10 23:49     ` MinChan Kim
2008-09-10 16:55   ` Dave Hansen
2008-09-10 17:45     ` Dave Hansen
2008-09-10 18:28     ` Oren Laadan
2008-09-10 21:03       ` Cleanups for [PATCH " Dave Hansen
2008-09-10 21:38   ` [RFC v4][PATCH " Dave Hansen
2008-09-12 16:57   ` Dave Hansen
2008-09-09  7:42 ` [RFC v4][PATCH 5/9] Memory managemnet (restore) Oren Laadan
2008-09-09 16:07   ` Serge E. Hallyn
2008-09-09 23:35     ` Oren Laadan
2008-09-10 15:00       ` Serge E. Hallyn
2008-09-10 19:31   ` Dave Hansen
2008-09-10 19:48     ` Oren Laadan
2008-09-10 20:49       ` Dave Hansen
2008-09-11  6:59         ` Oren Laadan
2008-09-09  7:42 ` [RFC v4][PATCH 6/9] Checkpoint/restart: initial documentation Oren Laadan
2008-09-10  7:13   ` MinChan Kim
2008-09-09  7:42 ` [RFC v4][PATCH 7/9] Infrastructure for shared objects Oren Laadan
2008-09-09  7:42 ` [RFC v4][PATCH 8/9] File descriprtors (dump) Oren Laadan
2008-09-09  8:06   ` Vegard Nossum
2008-09-09  8:23   ` Vegard Nossum [this message]
2008-09-10  2:01     ` Oren Laadan
2008-09-11  5:02   ` MinChan Kim
2008-09-11  6:37     ` Oren Laadan
2008-09-09  7:42 ` [RFC v4][PATCH 9/9] File descriprtors (restore) Oren Laadan
2008-09-09 16:26   ` Dave Hansen
2008-09-10  1:49     ` Oren Laadan
2008-09-10 16:09       ` Dave Hansen
2008-09-10 18:55         ` Oren Laadan
2008-09-09 18:06 ` [RFC v4][PATCH 0/9] Kernel based checkpoint/restart` Dave Hansen

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=19f34abd0809090123y36c51395pfa694799f7a2afb@mail.gmail.com \
    --to=vegard.nossum@gmail.com \
    --cc=arnd@arndb.de \
    --cc=containers@lists.linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®