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
next prev 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®