lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 12 Feb 2007 01:32:51 -0800 From: "Paul Menage" <menage@...gle.com> To: "Paul Jackson" <pj@....com> Cc: akpm@...l.org, sekharan@...ibm.com, dev@...ru, xemul@...ru, serue@...ibm.com, vatsa@...ibm.com, ebiederm@...ssion.com, ckrm-tech@...ts.sourceforge.net, linux-kernel@...r.kernel.org, rohitseth@...gle.com, mbligh@...gle.com, winget@...gle.com, containers@...ts.osdl.org, devel@...nvz.org Subject: Re: [PATCH 0/7] containers (V7): Generic Process Containers On 2/12/07, Paul Jackson <pj@....com> wrote: > > You'll have a rough time selling me on the idea that some kernel thread > should be waking up every few seconds, grabbing system-wide locks, on a > big honkin NUMA box, for the few times per hour, or less, that a cpuset is > abandoned. I think it could be made smarter than that, e.g. have a workqueue task that's only woken when a refcount does actually reach zero. (I think that waking a workqueue task is something that can be done without too much worry about locks) > > Can you explain to me how this intruded on the reference counting? > Essentially, it means that anything that releases a reference count on a container needs to be able to trigger a call to the release agent. The reference count is often released at a point when important locks are held, so you end up having to pass buffers into any function that might drop a ref count, in order to store a path to a release agent to be invoked. In particular, the new container_clone() function can be called during the task fork path; at which point forking a new release_agent process would be impossible, or at least nasty. Additionally, if containers are potentially going to be used for virtual servers, having the release agent run from a top-level process rather than the process context that released the refcount sounds like a sane option. Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists