Messages in this thread | | | Date | Mon, 6 Mar 2006 18:34:45 -0800 | From | Chris Wright <> | Subject | Re: [RFC][PATCH 2/6] sysvmsg: containerize |
| |
* Dave Hansen (haveblue@us.ibm.com) wrote: > On Mon, 2006-03-06 at 17:57 -0800, Chris Wright wrote: > > * Dave Hansen (haveblue@us.ibm.com) wrote: > > > -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. > > It will get context from the current task, which means the current > container. We haven't quite decided how these things will be (or if > they need to be) aggregated on a a system-wide basis.
The /proc interface is registering with &context->ids of init_task. So, all other contexts using that interface will be looking at the wrong info, AFAICT.
As you can tell my concerns are in resource consumption. If a user can create contexts which it can hide from sysadmin, and they aren't subject to sysadmin mandated resource limits, it's effectively a leak, esp. since these resources don't die with exit(2).
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/
| |