LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Oren Laadan <orenl@cs.columbia.edu>
Cc: Linus Torvalds <torvalds@osdl.org>,
containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-api@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC v8][PATCH 09/12] Dump open file descriptors
Date: Mon, 3 Nov 2008 14:57:41 -0600 [thread overview]
Message-ID: <20081103205741.GA27841@us.ibm.com> (raw)
In-Reply-To: <1225374675-22850-10-git-send-email-orenl@cs.columbia.edu>
I'm still trying to figure out the cause of my BUG at dcache.c:666,
so as I walk through the code a few more nitpicks:
Quoting Oren Laadan (orenl@cs.columbia.edu):
> +int cr_scan_fds(struct files_struct *files, int **fdtable)
> +{
> + struct fdtable *fdt;
> + int *fds;
> + int i, n = 0;
> + int tot = CR_DEFAULT_FDTABLE;
> +
> + fds = kmalloc(tot * sizeof(*fds), GFP_KERNEL);
> + if (!fds)
> + return -ENOMEM;
> +
> + /*
> + * We assume that the target task is frozen (or that we checkpoint
> + * ourselves), so we can safely proceed after krealloc() from where
> + * we left off; in the worst cases restart will fail.
> + */
> +
> + spin_lock(&files->file_lock);
> + rcu_read_lock();
> + fdt = files_fdtable(files);
> + for (i = 0; i < fdt->max_fds; i++) {
> + if (!fcheck_files(files, i))
> + continue;
> + if (n == tot) {
> + /*
> + * fcheck_files() is safe with drop/re-acquire
> + * of the lock, because it tests: fd < max_fds
> + */
> + spin_unlock(&files->file_lock);
> + rcu_read_unlock();
> + tot *= 2; /* won't overflow: kmalloc will fail */
> + fds = krealloc(fds, tot * sizeof(*fds), GFP_KERNEL);
> + if (!fds) {
> + kfree(fds);
If !fds kfree(fds) :)
> + return -ENOMEM;
> + }
> + rcu_read_lock();
> + spin_lock(&files->file_lock);
> + }
> + fds[n++] = i;
> + }
> + rcu_read_unlock();
> + spin_unlock(&files->file_lock);
> +
> + *fdtable = fds;
> + return n;
> +}
> +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 objref, new, ret;
> + int coe = 0; /* avoid gcc warning */
> +
> + 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) {
> + ret = -EBADF;
(As mentioned on irc - and probably already fixed in your v9 - you to an
fput(NULL) in this case which will bomb)
> + goto out;
> + }
> +
> + new = cr_obj_add_ptr(ctx, 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) {
> + ret = new;
> + goto out;
> + }
> +
> + 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);
> + if (ret < 0)
> + goto out;
> +
> + /* new==1 if-and-only-if file was newly added to hash */
> + if (new)
> + ret = cr_write_fd_data(ctx, file, objref);
> +
> +out:
> + cr_hbuf_put(ctx, sizeof(*hh));
> + 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);
> +
> + nfds = cr_scan_fds(files, &fdtable);
> + if (nfds < 0) {
> + put_files_struct(files);
need a cr_hbuf_put()
> + return nfds;
> + }
> +
(Cause of my BUG() doesn't appear to be here :( )
thanks,
-serge
next prev parent reply other threads:[~2008-11-03 20:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-30 13:51 [RFC v8][PATCH 0/12] Kernel based checkpoint/restart Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 01/12] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 02/12] Checkpoint/restart: initial documentation Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 03/12] Make file_pos_read/write() public Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 04/12] General infrastructure for checkpoint restart Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 05/12] x86 support for checkpoint/restart Oren Laadan
2008-11-04 9:30 ` Masahiko Takahashi
2008-11-04 15:32 ` Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 06/12] Dump memory address space Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 07/12] Restore " Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 08/12] Infrastructure for shared objects Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 09/12] Dump open file descriptors Oren Laadan
2008-11-03 20:57 ` Serge E. Hallyn [this message]
2008-10-30 13:51 ` [RFC v8][PATCH 10/12] Restore open file descriprtors Oren Laadan
2008-10-30 13:51 ` [RFC v8][PATCH 11/12] External checkpoint of a task other than ourself Oren Laadan
2008-10-31 2:41 ` Serge E. Hallyn
2008-10-31 13:58 ` Serge E. Hallyn
2008-10-30 13:51 ` [RFC v8][PATCH 12/12] Track in-kernel when we expect checkpoint/restart to work Oren Laadan
2008-10-30 14:45 ` [Devel] [RFC v8][PATCH 0/12] Kernel based checkpoint/restart Andrey Mirkin
2008-10-30 15:59 ` Oren Laadan
2008-11-04 18:44 ` Serge E. Hallyn
2008-11-04 21:38 ` Serge E. Hallyn
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=20081103205741.GA27841@us.ibm.com \
--to=serue@us.ibm.com \
--cc=containers@lists.linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=orenl@cs.columbia.edu \
--cc=tglx@linutronix.de \
--cc=torvalds@osdl.org \
--cc=viro@zeniv.linux.org.uk \
--subject='Re: [RFC v8][PATCH 09/12] Dump open file descriptors' \
/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
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).