gmane.linux.kernel.containers

liblxc: lxc-debian

Serge E. Hallyn — 2008-12-04T02:39:36

Hi Daniel, to create a debian-based container using lxc-debian on fedora 10, I needed to just a couple of things: 1. iptables -F :) Grrr. 2. Right above the debootstrap command, I had to fool chage (used during openssh configuration) into thinking selinux was disabled. So after the line: mkdir -p "$CACHE/rootfs-$ARCH" I added mkdir -p "$CACHE/rootfs-$ARCH/selinux" echo 0 > "$CACHE/rootfs-$ARCH/selinux/enforce" 3. For the actual debootstrap command I had to do debootstrap --arch $ARCH etc $CACHE/rootfs-$ARCH Then apt-get install openssh-server and apache worked fine. But your debootstrap command failed (the last time i tried) on chroot - no idea why. Now it seems to work. This shouldn't have taken me 2 hours to figure out, but the symptoms were deceptive :) thanks, -serge

Re: [RFC][PATCH 3/5] Determine if sender is from ancestor ns

Roland McGrath — 2008-12-04T01:06:36

I don't quarrel with the intent, but I don't like this approach. I think we can do it more cleanly. I don't have it all worked out, but a couple of thoughts come to mind. Firstly, it's no problem to split SIGNAL_UNKILLABLE out into multiple flags. It's quite noninvasive, only signal.c looks at those flags. Then we can implement the signal magic cleanly keyed on a few separate flags, using different flag combinations for global init and container inits. I don't mind a feature that lets an unprivileged container init magically ignore normal exit signals. That just does something it could do itself with sigaction, except its /proc/pid/status "SigIgn:" line will lie. That's OK. Key that on its own flag and set that in both inits. Just check that flag in prepare_signal() and in get_signal_to_deliver(). It's a different story for the signals that cannot be caught, blocked, or ignored, SIGKILL and SIGSTOP. At least when sent from outside the container, circumventing either of those would be a privilege es

Re: [RFC v10][PATCH 00/13] Kernel based checkpoint/restart

Serge E. Hallyn — 2008-12-03T23:58:58

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA< at >public.gmane.org): Tests well for me. Haven't tested mktree yet, will wait until you re-send addressing feedback to do that. thanks, -serge

Re: [PATCH 1/3] ftrace: graph of a single function

Andrew Morton — 2008-12-03T21:08:59

On Wed, 03 Dec 2008 15:36:57 -0500 Steven Rostedt public.gmane.org> wrote: This could be static I think. It's probably not worth even commenting on or fixing this sort of thing. Just rely on someone(tm) doing periodic sweeps to fix them all up.

Re: [PATCH 1/3] ftrace: graph of a single function

Andrew Morton — 2008-12-03T21:07:41

On Wed, 03 Dec 2008 15:36:57 -0500 Steven Rostedt public.gmane.org> wrote: Can we use %pF here?

[PATCH 1/3] ftrace: graph of a single function

Steven Rostedt — 2008-12-03T20:36:57

From: Steven Rostedt public.gmane.org> Impact: New feature This patch adds the file: /debugfs/tracing/set_graph_function which can be used along with the function graph tracer. When this file is empty, the function graph tracer will act as normal. When the file has a function in it, the function graph tracer will only trace that function. For example: # echo blk_unplug > /debugfs/tracing/set_graph_function # cat /debugfs/tracing/trace [...] ------------------------------------------ | 2) make-19003 => kjournald-2219 ------------------------------------------ 2) | blk_unplug() { 2) | dm_unplug_all() { 2) | dm_get_table() { 2) 1.381 us | _read_lock(); 2) 0.911 us | dm_table_get(); 2) 1. 76 us | _read_unlock(); 2) + 12.912 us | } 2) | dm_table_unplug_all() { 2) | blk_unplug() { 2) 0.778 us | generic_unplug_

Re: [RFC][PATCH 4/4] checkpoint/restart: simplify cr_scan_fds()

Dave Hansen — 2008-12-03T16:23:17

Agreed. This just saves a few lines of code.

Re: [PATCH] Unused check for thread group leader inmem_cgroup_move_task

KAMEZAWA Hiroyuki — 2008-12-03T16:08:12

Balbir Singh said: Considering following case, # mount -t cgroup none /cgroup -t memory,cpuset # mkdir /cgroup/grpA/ # echo 1 > /cgroup/grpA/memory.use_hierarchy # echo 1G > /cgroup/grpA/memory.limit_in_bytes # mkdir /cgroup/grpA/01 # mkdir /cgroup/grpA/02 limit grpA/01's cpu to 0 limit grpA/02's cpu to 1 Run multithread program under grpA and move threads to grpA/01, grpA/02 if necessary to bind cpu. Your "hierarchy" added this kind of flexibility and this is very useful. And, of course, cgroup generic interface allows per-thread group attaching. This is why I changed my mind and agreed to handle hierarchy management under the kernel. This can be an answer for use case to explain why thread-leader-check is bad ? If we add limitation as "memcgroup should be mounted without others", And, if we only allows attaching thread-group-leader, how to migrate multi-threaded program's all thread ? I'm sorry I misunderstand something. -Kame

Re: [PATCH] Unused check for thread group leader inmem_cgroup_move_task

Balbir Singh — 2008-12-03T13:40:25

* KAMEZAWA Hiroyuki public.gmane.org> [2008-12-01 13:30:30]: Sorry, I did not review this patch. The correct thing was nikanth did at first, move this to can_attach(). Why would we allow threads to exist in different groups, but still mark them as being accounted to the thread group leader. It can be a bit confusing for end users, it can be helpful when all controllers are mounted together. I agree we did not do anything useful in move_task(). The correct check now, should be for mm->owner. If the common case is going to be that memory and cpu are mounted together, then this patch is correct, but it can be confusing to users who look at tasks/threads, but as the threads consume memory, the accounting will happen with mm->owner.

Re: [RFC][PATCH 4/4] checkpoint/restart: simplify cr_scan_fds()

Oren Laadan — 2008-12-03T09:48:18

(as discussed in the LKML thread) as far as I can see the existing code is safe, and this code is not more correct (for restart) in terms of races with changes to the file table ? Dave Hansen wrote:

MD Listing

Wm E Eastman — 2008-12-03T04:52:18

Currently in Practice: MDs in the US 788,149 in total <> 17,219 emails 34 primary and secondary specialties Can easily be sorted by 16 different fields Now priced at: $391 <><><> GET THE 4 ITEMS BELOW AS A GIFT WHEN YOU ORDER <><><> List of US Pharma Companies 47,000 names and emails of the major positions Complete Database of Hospitals in the US more than 23k hospital administrators in over 7k hospitals [worth over $300 alone) American Dentists Virtually every dentist in the US with full contact details Chiropractors in the USA Complete data for all chiropractors in the USA (a $250 value) reply to: Collier-zv0fbVGlH0KkkmuXFMvWN0EOCMrvLtNR< at >public.gmane.org above expires on December 05 Send email to quit-zv0fbVGlH0KkkmuXFMvWN0EOCMrvLtNR< at >public.gmane.org to ensure no further communication

MD Listing

Wm E Eastman — 2008-12-03T04:52:18

Re: [RFC][PATCH 4/4] checkpoint/restart: simplify cr_scan_fds()

Serge E. Hallyn — 2008-12-03T04:21:39

Quoting Dave Hansen (dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8< at >public.gmane.org): Heh, well I think you'll need to initialize n after the retry: label. Otherwise, I can see the appeal of this...

Re: [PATCH 2/3] cgroups: add inactive subsystems to rootnode.root_list

Li Zefan — 2008-12-03T01:10:00

Yes, since it's not broken, I didn't claim this patch as a bug fix that should go into 2.6.28. I found this confusion when I was trying to understand this part of code. I'll fix it. :)

Re: [PATCH 2/3] cgroups: add inactive subsystems to rootnode.root_list

Paul Menage — 2008-12-02T22:53:37

Looking at the existing code, it's not actually broken - but only by accident. We aim to add a link for each cgroup, which we do by finding the first subsystem in each hierarchy and adding a link for its cgroup, and then adding a link for dummytop if there weren't any subsystems in the inactive hierarchy. But since rootnode.subsys_list is always empty, we always skip the inactive hierarchy in the main loop (if it has any subsystems), and always add the inactive hierarchy afterwards. So everything works out OK (all hierarchies do get linked), but it's horribly unreadable. Having the subsys_list be correct for the inactive hierarchy is probably a good thing, so this patch should go ahead (once the typos is fixed). Paul

Re: [RFC][PATCH 2/4] checkpoint/restart: fix cr_ctx_checkpoint()locking

Dave Hansen — 2008-12-02T22:25:31

This looked simpler to me. We're going to have to rip this sucker out anyway, so I went for what I thought was the smallest amount of code.

Re: [RFC][PATCH 2/4] checkpoint/restart: fix cr_ctx_checkpoint()locking

Oren Laadan — 2008-12-02T22:22:37

any reason why you want to reference the entire ->fs instead of, as I suggested, make a *copy* of ->fs->root and then reference its contents ? Dave Hansen wrote:

Re: [PATCH 3/3] cgroups: introduce link_css_set() to remove duplicatecode

Paul Menage — 2008-12-02T22:16:29

Sounds good. But we're creating the hierarchy at this point, so there can clearly only be one cgroup any (which is the root cgroup). I don't think it's any more or less readable, it just seems an unnecessary change. Paul

[RFC][PATCH 3/4] checkpoint/restart: fix 'struct file' references

Dave Hansen — 2008-12-02T18:57:39

We must hold a reference to 'file' when it get passed in to fd_install(). After fd_install() the entry in the fdtable takes on the reference. If we don't hold a reference to it, another thread can come along after fd_install() and fput() it before we've done the get_file(). In cr_read_fd_data(), the cr_obj_add_ref() code does the get_file() internally. But, we need to do this (and get the ref) before we do the cr_attach_file(). Otherwise, the file can go away after the cr_attach_file() and before the cr_obj_add_ref(). --- linux-2.6.git-dave/checkpoint/rstr_file.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff -puN checkpoint/rstr_file.c~fix-refs-order-in-cr_attach_get_file checkpoint/rstr_file.c --- linux-2.6.git/checkpoint/rstr_file.c~fix-refs-order-in-cr_attach_get_file2008-12-02 10:22:17.000000000 -0800 +++ linux-2.6.git-dave/checkpoint/rstr_file.c2008-12-02 10:22:17.000000000 -0800 < at >< at > -59,8 +59,8 < at >< at > static int cr_attach_get_file(struct fil if (fd >= 0) { fsno

[RFC][PATCH 4/4] checkpoint/restart: simplify cr_scan_fds()

Dave Hansen — 2008-12-02T18:57:42

I think having all the allocations in one place, plus the reduction in the number of lines speaks for itself. In any case, this is last in the series and can be dropped if you don't like it. --- linux-2.6.git-dave/checkpoint/ckpt_file.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff -puN checkpoint/ckpt_file.c~fix-cr_scan_fds-realloc checkpoint/ckpt_file.c --- linux-2.6.git/checkpoint/ckpt_file.c~fix-cr_scan_fds-realloc2008-12-02 10:26:53.000000000 -0800 +++ linux-2.6.git-dave/checkpoint/ckpt_file.c2008-12-02 10:26:53.000000000 -0800 < at >< at > -38,6 +38,7 < at >< at > int cr_scan_fds(struct files_struct *fil int i, n = 0; int tot = CR_DEFAULT_FDTABLE; +retry: fds = kmalloc(tot * sizeof(*fds), GFP_KERNEL); if (!fds) return -ENOMEM; < at >< at > -55,18 +56,12 < at >< at > int cr_scan_fds(struct files_struct *fil 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 - */ +/*

[RFC][PATCH 2/4] checkpoint/restart: fix cr_ctx_checkpoint() locking

Dave Hansen — 2008-12-02T18:57:36

The existing ctx->vfsroot is dangerous. We take it from the root task via: ctx->root_task->fs->root and don't take a ref on the 'fs' in there. We also take a ref on the fs.root which is worthless. So, replace ctx->vfsroot with a reference to the 'fs' instead. This gives us easy access to fs.root later on, and also lets us do proper refcounting. This, of course, eventually needs to be done per-process but this should at least remove a potential oops. --- linux-2.6.git-dave/checkpoint/checkpoint.c | 7 ++----- linux-2.6.git-dave/checkpoint/ckpt_file.c | 2 +- linux-2.6.git-dave/checkpoint/ckpt_mem.c | 2 +- linux-2.6.git-dave/checkpoint/sys.c | 4 ++-- linux-2.6.git-dave/include/linux/checkpoint.h | 2 +- 5 files changed, 7 insertions(+), 10 deletions(-) diff -puN checkpoint/checkpoint.c~fix-cr_ctx_checkpoint-locking checkpoint/checkpoint.c --- linux-2.6.git/checkpoint/checkpoint.c~fix-cr_ctx_checkpoint-locking2008-12-02 10:21:52.000000000 -0800 +++ linux-2.6.git