Re: [RFC][PATCH 2/6] sysvmsg: containerize

[Chris Wright <chrisw@sous-sol.org>]

* Dave Hansen (haveblue@us.ibm.com) wrote:
> --- work/include/linux/init_task.h~sysvmsg-container	2006-03-06 15:41:56.000000000 -0800
> +++ work-dave/include/linux/init_task.h	2006-03-06 15:41:56.000000000 -0800
> @@ -2,6 +2,7 @@
>  #define _LINUX__INIT_TASK_H
>  
>  #include <linux/file.h>
> +#include <linux/ipc.h>
>  #include <linux/rcupdate.h>
>  
>  #define INIT_FDTABLE \

missing INIT_IPC_CONTEXT type of macro?

> diff -puN include/linux/ipc.h~sysvmsg-container include/linux/ipc.h
> --- work/include/linux/ipc.h~sysvmsg-container	2006-03-06 15:41:56.000000000 -0800
> +++ work-dave/include/linux/ipc.h	2006-03-06 15:41:56.000000000 -0800
> @@ -68,6 +68,10 @@ struct kern_ipc_perm
>  	void		*security;
>  };
>  
> +struct ipc_context;
> +extern struct ipc_context *ipc_context;
> +
> +extern struct ipc_msg_context *init_ipc_context(void);
>  #endif /* __KERNEL__ */
>  
>  #endif /* _LINUX_IPC_H */
> diff -puN include/linux/sched.h~sysvmsg-container include/linux/sched.h
> --- work/include/linux/sched.h~sysvmsg-container	2006-03-06 15:41:56.000000000 -0800
> +++ work-dave/include/linux/sched.h	2006-03-06 15:41:56.000000000 -0800
> @@ -793,6 +793,7 @@ struct task_struct {
>  	int link_count, total_link_count;
>  /* ipc stuff */
>  	struct sysv_sem sysvsem;
> +	struct ipc_context *ipc_context;

how does this propagate on clone (presently it's just side-effect of
dup_task_struct starting from init_task, with no dynamic lifetime),
how is it meant to be changed?

>  /* CPU-specific state of this task */
>  	struct thread_struct thread;
>  /* filesystem information */
> diff -puN ipc/msg.c~sysvmsg-container ipc/msg.c
> --- work/ipc/msg.c~sysvmsg-container	2006-03-06 15:41:56.000000000 -0800
> +++ work-dave/ipc/msg.c	2006-03-06 15:41:56.000000000 -0800
> @@ -60,35 +60,30 @@ struct msg_sender {
>  #define SEARCH_NOTEQUAL		3
>  #define SEARCH_LESSEQUAL	4
>  
> -static atomic_t msg_bytes = ATOMIC_INIT(0);
> -static atomic_t msg_hdrs = ATOMIC_INIT(0);
> +#define msg_lock(ctx, id)	((struct msg_queue*)ipc_lock(&ctx->ids,id))
> +#define msg_unlock(ctx, msq)	ipc_unlock(&(msq)->q_perm)
> +#define msg_rmid(ctx, id)	((struct msg_queue*)ipc_rmid(&ctx->ids,id))
> +#define msg_checkid(ctx, msq, msgid)	\
> +	ipc_checkid(&ctx->ids,&msq->q_perm,msgid)
> +#define msg_buildid(ctx, id, seq) \
> +	ipc_buildid(&ctx->ids, id, seq)
>  
> -static struct ipc_ids msg_ids;
> -
> -#define msg_lock(id)	((struct msg_queue*)ipc_lock(&msg_ids,id))
> -#define msg_unlock(msq)	ipc_unlock(&(msq)->q_perm)
> -#define msg_rmid(id)	((struct msg_queue*)ipc_rmid(&msg_ids,id))
> -#define msg_checkid(msq, msgid)	\
> -	ipc_checkid(&msg_ids,&msq->q_perm,msgid)
> -#define msg_buildid(id, seq) \
> -	ipc_buildid(&msg_ids, id, seq)
> -
> -static void freeque (struct msg_queue *msq, int id);
> -static int newque (key_t key, int msgflg);
> +static void freeque (struct ipc_msg_context *, struct msg_queue *msq, int id);
> +static int newque (struct ipc_msg_context *context, key_t key, int id);
>  #ifdef CONFIG_PROC_FS
>  static int sysvipc_msg_proc_show(struct seq_file *s, void *it);
>  #endif
>  
> -void __init msg_init (void)
> +void __init msg_init (struct ipc_msg_context *context)
>  {
> -	ipc_init_ids(&msg_ids,msg_ctlmni);
> +	ipc_init_ids(&context->ids,msg_ctlmni);
>  	ipc_init_proc_interface("sysvipc/msg",
>  				"       key      msqid perms      cbytes       qnum lspid lrpid   uid   gid  cuid  cgid      stime      rtime      ctime\n",
> -				&msg_ids,
> +				&context->ids,
>  				sysvipc_msg_proc_show);

Does that mean /proc interface only gets init_task context?
Along those lines, I think now ipcs -a is incomplete from admin
perspective.  Suppose that's a feature from the container/vserver
POV.

> --- work/ipc/util.h~sysvmsg-container	2006-03-06 15:41:56.000000000 -0800
> +++ work-dave/ipc/util.h	2006-03-06 15:41:56.000000000 -0800
> @@ -12,7 +12,7 @@
>  #define SEQ_MULTIPLIER	(IPCMNI)
>  
>  void sem_init (void);
> -void msg_init (void);
> +void msg_init (struct ipc_msg_context *context);
>  void shm_init (void);
>  
>  struct ipc_id_ary {
> @@ -30,6 +30,18 @@ struct ipc_ids {
>  	struct ipc_id_ary* entries;
>  };
>  
> +struct ipc_msg_context {
> +	atomic_t bytes;
> +	atomic_t hdrs;
> +
> +	struct ipc_ids ids;
> +	struct kref count;
> +};
> +
> +struct ipc_context {
> +	struct ipc_msg_context msg;
> +};

This looks a little suspect.  ref count embedded in embedded object.
My first thought was, sem and shared memory would introduce same, and
now we'd have 3 independent refounts for top level object.  However,
it's not used, and doesn't appear to be mirrored in the sem and shared
mem contexts.  Perhaps it is just a leftover?

thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/