public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Andrey Mirkin <major@openvz.org>
Cc: containers@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, Pavel Emelyanov <xemul@openvz.org>
Subject: Re: [PATCH 03/10] Introduce context structure needed during checkpointing/restart
Date: Mon, 20 Oct 2008 10:02:24 -0700	[thread overview]
Message-ID: <1224522144.1848.115.camel@nimitz> (raw)
In-Reply-To: <1224285098-573-4-git-send-email-major@openvz.org>

On Sat, 2008-10-18 at 03:11 +0400, Andrey Mirkin wrote:
> +typedef struct cpt_context
> +{
> +	pid_t		pid;		/* should be changed to ctid later */
> +	int		ctx_id;		/* context id */
> +	struct list_head ctx_list;
> +	int		refcount;
> +	int		ctx_state;
> +	struct semaphore main_sem;

Does this really need to be a semaphore or is a mutex OK?

> +	int		errno;

Could you hold off on adding these things to the struct until the patch
where they're actually used?  It's hard to judge this without seeing
what you do with it.

> +	struct file	*file;
> +	loff_t		current_object;
> +
> +	struct list_head object_array[CPT_OBJ_MAX];
> +
> +	int		(*write)(const void *addr, size_t count, struct cpt_context *ctx);
> +	int		(*read)(void *addr, size_t count, struct cpt_context *ctx);
> +} cpt_context_t;

Man, this is hard to review.  I was going to try and make sure that your
refcounting was right and atomic, but there's no use of it in this patch
except for the initialization and accessor functions.  Darn.

> +extern int debug_level;

I'm going to go out on a limb here and say that "debug_level" is
probably a wee bit too generic of a variable name.

> +#define cpt_printk(lvl, fmt, args...)	do {	\
> +		if (lvl <= debug_level)		\
> +			printk(fmt, ##args);	\
> +	} while (0)

I think you can use pr_debug() here, too, just like Oren did.

> +struct cpt_context * context_alloc(void)
> +{
> +	struct cpt_context *ctx;
> +	int i;
> +
> +	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return NULL;
> +
> +	init_MUTEX(&ctx->main_sem);
> +	ctx->refcount = 1;
> +
> +	ctx->current_object = -1;
> +	ctx->write = file_write;
> +	ctx->read = file_read;
> +	for (i = 0; i < CPT_OBJ_MAX; i++) {
> +		INIT_LIST_HEAD(&ctx->object_array[i]);
> +	}
> +
> +	return ctx;
> +}
> +
> +void context_release(struct cpt_context *ctx)
> +{
> +	ctx->ctx_state = CPT_CTX_ERROR;
> +
> +	kfree(ctx);
> +}
> +
> +static void context_put(struct cpt_context *ctx)
> +{
> +	if (!--ctx->refcount)
> +		context_release(ctx);
> +}
> +
>  static int checkpoint(pid_t pid, int fd, unsigned long flags)
>  {
> -	return -ENOSYS; 
> +	struct file *file;
> +	struct cpt_context *ctx;
> +	int err;
> +
> +	err = -EBADF;
> +	file = fget(fd);
> +	if (!file)
> +		goto out;
> +
> +	err = -ENOMEM;
> +	ctx = context_alloc();
> +	if (!ctx)
> +		goto out_file;
> +
> +	ctx->file = file;
> +	ctx->ctx_state = CPT_CTX_DUMPING;
> +
> +	/* checkpoint */
> +	err = -ENOSYS;
> +
> +	context_put(ctx);
> +
> +out_file:
> +	fput(file);
> +out:
> +	return err; 
>  }

So, where is context_get()?  Is there only single-threaded access to the
refcount?  If so, why do we even need it?  We should probably just use
context_release() driectly.

If there is multithreaded access to context_put() or the refcount, then
they're unsafe without additional locking.

-- Dave


  parent reply	other threads:[~2008-10-20 17:02 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-17 23:11 [PATCH 0/10] OpenVZ kernel based checkpointing/restart (v2) Andrey Mirkin
2008-10-17 23:11 ` [PATCH 01/10] Introduce trivial sys_checkpoint and sys_restore system calls Andrey Mirkin
2008-10-17 23:11   ` [PATCH 02/10] Make checkpoint/restart functionality modular Andrey Mirkin
2008-10-17 23:11     ` [PATCH 03/10] Introduce context structure needed during checkpointing/restart Andrey Mirkin
2008-10-17 23:11       ` [PATCH 04/10] Introduce container dump function Andrey Mirkin
2008-10-17 23:11         ` [PATCH 05/10] Introduce function to dump process Andrey Mirkin
2008-10-17 23:11           ` [PATCH 06/10] Introduce functions to dump mm Andrey Mirkin
2008-10-17 23:11             ` [PATCH 07/10] Introduce function for restarting a container Andrey Mirkin
2008-10-17 23:11               ` [PATCH 08/10] Introduce functions to restart a process Andrey Mirkin
2008-10-17 23:11                 ` [PATCH 09/10] Introduce functions to restore mm Andrey Mirkin
2008-10-17 23:11                   ` [PATCH 10/10] Add support for multiple processes Andrey Mirkin
2008-10-27 15:58                     ` Oren Laadan
2008-10-30  4:55                       ` [Devel] " Andrey Mirkin
2008-10-20  9:23                 ` [PATCH 08/10] Introduce functions to restart a process Cedric Le Goater
2008-10-22  8:49                   ` [Devel] " Andrey Mirkin
2008-10-22  9:25                     ` Louis Rilling
2008-10-22 10:06                       ` Greg Kurz
2008-10-22 10:44                         ` Louis Rilling
2008-10-22 12:44                           ` Greg Kurz
2008-10-22 10:12                       ` Andrey Mirkin
2008-10-22 10:46                         ` Louis Rilling
2008-10-23  8:53                           ` Andrey Mirkin
2008-10-22 15:25                         ` Oren Laadan
2008-10-23  9:00                           ` Andrey Mirkin
2008-10-23 13:57                             ` Dave Hansen
2008-10-24  3:57                               ` Andrey Mirkin
2008-10-25 21:10                                 ` Oren Laadan
2008-10-29 14:52                                   ` Andrey Mirkin
2008-10-30 15:59                                     ` Oren Laadan
2008-10-22 12:47                     ` Cedric Le Goater
2008-10-23  9:54                       ` Andrey Mirkin
2008-10-23 13:49                         ` Dave Hansen
2008-10-24  4:04                           ` Andrey Mirkin
2008-10-20 13:25                 ` Louis Rilling
2008-10-23 10:56                   ` [Devel] " Andrey Mirkin
2008-10-20 12:25             ` [PATCH 06/10] Introduce functions to dump mm Louis Rilling
2008-10-22  8:58               ` [Devel] " Andrey Mirkin
2008-10-20 17:21             ` Dave Hansen
2008-10-23  8:43               ` [Devel] " Andrey Mirkin
2008-10-23 13:51                 ` Dave Hansen
2008-10-24  4:07                   ` Andrey Mirkin
2008-10-20 11:02           ` [PATCH 05/10] Introduce function to dump process Louis Rilling
2008-10-24  4:15             ` [Devel] " Andrey Mirkin
2008-10-20 17:48           ` Serge E. Hallyn
2008-10-24  4:40             ` [Devel] " Andrey Mirkin
2008-10-20 17:02       ` Dave Hansen [this message]
2008-10-29 15:30         ` [Devel] Re: [PATCH 03/10] Introduce context structure needed during checkpointing/restart Andrey Mirkin
2008-10-20 16:51     ` [PATCH 02/10] Make checkpoint/restart functionality modular Dave Hansen
2008-10-20 16:59     ` 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=1224522144.1848.115.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=major@openvz.org \
    --cc=xemul@openvz.org \
    /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