Re: [lxc-devel] [RFC] rootfs pinning
Hi there, No. There's a change there, all right, and thank you for reminding me of that, but (afaik) it's NOT in the kernel itself. It's a mount option. It's that bloody MS_SHARED option and, to a lessor extent, MS_SLAVE option that are behind how those things are propagated. MS_SHARED will propagate certain things from a child mount to the mount point and to other children, IIRC, while MS_SLAVE propagates in one direction and MS_PRIVATE restricts it. I think the trouble maker is MS_SHARED and that's what caused all the pivot_root calls to face plant when systemd started mounting everything with MS_SHARED in the host system. I was using bind mounts to avoid some of these problems but then they changed systemd and its default mount options and broke a number of things I had running. This is not MS_SHARED. The 3.8 instance I'm testing this with is a Debian Wheezy with a custom kernel (the 3.8 from Serge's and/or Stéphane's repository for userns which floated around here half a year ago or so. (I never had a chance to upgrade, it's in a KVM, so that I don't break my main system). Look at the following: root@lxcdev:~# mkdir /foo/bar /foo/baz -p root@lxcdev:~# mount --bind /foo/bar /foo/baz root@lxcdev:~# grep /foo /proc/self/mountinfo 25 20 253:1 /foo/bar /foo/baz rw,relatime - ext4 /dev/disk/by-uuid/b2e1ac13-e6d0-48e7-a3b0-9fcdf81db294 rw,errors=remount-ro,data=ordered root@lxcdev:~# grep ^20 /proc/self/mountinfo 20 1 253:1 / / rw,relatime - ext4 /dev/disk/by-uuid/b2e1ac13-e6d0-48e7-a3b0-9fcdf81db294 rw,errors=remount-ro,data=ordered root@lxcdev:~# mount /foo/baz -o remount,ro mount: /foo/baz is busy root@lxcdev:~# mount /foo/baz -o remount,bind,ro root@lxcdev:~# grep /foo /proc/self/mountinfo 25 20 253:1 /foo/bar /foo/baz ro,relatime - ext4 /dev/disk/by-uuid/b2e1ac13-e6d0-48e7-a3b0-9fcdf81db294 rw,errors=remount-ro,data=ordered root@lxcdev:~# uname -a Linux lxcdev 3.8.0-rc3+ #1 SMP Sun Jan 27 16:39:34 CET 2013 x86_64 GNU/Linux I don't see any shared: in /proc/self/mountinfo. Obviously, this could be a side-effect of the specific kernel I'm using, but I don't recall the additional userns patches to change anything in that regard. Also note that a mount --make-private / doesn't change anything. And that this isn't even in an own namespace. I don't have that much time atm, so I won't be able to check with a current official kernel. -- Christian -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] doc: Japanese man pages is not generated when docbook-utils is used
Character encoding of Japanese man pages is UTF-8. But docbook-utils can't treat it (and don't have --encoding option that use in Makefile). So change to Japanese man pages is not generated when docbook-utils is used. Signed-off-by: KATOH Yasufumi ka...@jazz.email.ne.jp --- configure.ac| 1 + doc/Makefile.am | 9 +++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a523583..092a67d 100644 --- a/configure.ac +++ b/configure.ac @@ -91,6 +91,7 @@ if test x$enable_doc = xyes -o x$enable_doc = xauto; then AC_SUBST(db2xman) fi AM_CONDITIONAL([ENABLE_DOCBOOK], [test x$db2xman != x]) +AM_CONDITIONAL([USE_DOCBOOK2X], [test x$db2xman != xdocbook2man]) if test x$db2xman = xdocbook2man; then docdtd=\-//Davenport//DTD DocBook V3.0//EN\ diff --git a/doc/Makefile.am b/doc/Makefile.am index f2a106b..1e83f8a 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,5 +1,10 @@ -SUBDIRS = examples rootfs ja -DIST_SUBDIRS = examples rootfs ja +SUBDIRS = examples rootfs +DIST_SUBDIRS = examples rootfs + +if USE_DOCBOOK2X +SUBDIRS += ja +DIST_SUBDIRS += ja +endif EXTRA_DIST = \ FAQ.txt -- 1.8.1.4 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: Device Namespaces
On Tue, Sep 10, 2013 at 10:09 AM, Amir Goldstein a...@cellrox.com wrote: On Mon, Sep 9, 2013 at 2:51 AM, Eric W. Biederman ebied...@xmission.comwrote: Amir Goldstein a...@cellrox.com writes: On Fri, Sep 6, 2013 at 7:50 PM, Eric W. Biederman ebied...@xmission.com wrote: Hi Eric, If we can get people to take a quick look at the code before LPC that could make the LPC discussions more effective. Hi, I think we are curious enough to experiment with Erics idea of implementing basic 'device namespace' in userspace (never miss an opportunity to throw away kernel code). Can anyone point out any obvious reason why this would not work if we consider bulk of the work being plain access filtering? That being said, is there a valid reason why binder is part of device namespace here instead of IPC? -- Janne -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [RFC] rootfs pinning
Quoting Christian Seiler (christ...@iwakd.de):
Hi there,
No. There's a change there, all right, and thank you for reminding
me
of that, but (afaik) it's NOT in the kernel itself. It's a mount
option. It's that bloody MS_SHARED option and, to a lessor extent,
MS_SLAVE option that are behind how those things are propagated.
MS_SHARED will propagate certain things from a child mount to the
mount
point and to other children, IIRC, while MS_SLAVE propagates in one
direction and MS_PRIVATE restricts it. I think the trouble maker is
MS_SHARED and that's what caused all the pivot_root calls to face
plant when systemd started mounting everything with MS_SHARED in the
host system. I was using bind mounts to avoid some of these problems
but then they changed systemd and its default mount options and broke
a
number of things I had running.
This is not MS_SHARED. The 3.8 instance I'm testing this with is
a Debian Wheezy with a custom kernel (the 3.8 from Serge's and/or
Stéphane's repository for userns which floated around here half
a year ago or so. (I never had a chance to upgrade, it's in a KVM,
so that I don't break my main system).
Look at the following:
root@lxcdev:~# mkdir /foo/bar /foo/baz -p
root@lxcdev:~# mount --bind /foo/bar /foo/baz
root@lxcdev:~# grep /foo /proc/self/mountinfo
25 20 253:1 /foo/bar /foo/baz rw,relatime - ext4
/dev/disk/by-uuid/b2e1ac13-e6d0-48e7-a3b0-9fcdf81db294
rw,errors=remount-ro,data=ordered
root@lxcdev:~# grep ^20 /proc/self/mountinfo
20 1 253:1 / / rw,relatime - ext4
/dev/disk/by-uuid/b2e1ac13-e6d0-48e7-a3b0-9fcdf81db294
rw,errors=remount-ro,data=ordered
root@lxcdev:~# mount /foo/baz -o remount,ro
mount: /foo/baz is busy
root@lxcdev:~# mount /foo/baz -o remount,bind,ro
root@lxcdev:~# grep /foo /proc/self/mountinfo
25 20 253:1 /foo/bar /foo/baz ro,relatime - ext4
/dev/disk/by-uuid/b2e1ac13-e6d0-48e7-a3b0-9fcdf81db294
rw,errors=remount-ro,data=ordered
root@lxcdev:~# uname -a
Linux lxcdev 3.8.0-rc3+ #1 SMP Sun Jan 27 16:39:34 CET 2013 x86_64
GNU/Linux
I don't see any shared: in /proc/self/mountinfo. Obviously,
this could be a side-effect of the specific kernel I'm using,
but I don't recall the additional userns patches to change
anything in that regard.
Also note that a mount --make-private / doesn't change
anything. And that this isn't even in an own namespace.
I don't have that much time atm, so I won't be able to
check with a current official kernel.
Hm, this looks like a bug (perhaps in a patch I ported). I get:
serge@sergelap:~$ sudo mount -t tmpfs tmpfs /tmp/a
serge@sergelap:~$ sudo mkdir /tmp/a/{a,b}
serge@sergelap:~$ sudo mount --bind /tmp/a/a /tmp/a/b
serge@sergelap:~$ sudo mount -o remount,ro /tmp/a/b
serge@sergelap:~$ grep /tmp/a /proc/self/mountinfo
48 20 0:40 / /tmp/a rw,relatime - tmpfs tmpfs rw
49 48 0:40 /a /tmp/a/b ro,relatime - tmpfs tmpfs rw
serge@sergelap:~$ uname -a
Linux sergelap 3.11.0-8-generic #15-Ubuntu SMP Fri Sep 20 04:11:26 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
Drat I just deleted my userns vm, I'll set up a new one and shout if
I get different results there.
-serge
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [RFC] rootfs pinning
Quoting Michael H. Warfield (m...@wittsend.com): On Tue, 2013-09-24 at 17:19 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): No. There's a change there, all right, and thank you for reminding me of that, but (afaik) it's NOT in the kernel itself. It's a mount option. It's that bloody MS_SHARED option and, to a lessor extent, There *is* a kernel change which dhansen was telling me about last week - I believe it's commit 4ed5e82fe77f4147cf386327c9a63a2dd7eff518. It allows you to now do sudo mount -t tmpfs tmpfs /tmp/a sudo mount -o bind,remount,ro /tmp/a /tmp/b In the past you had to first create a bind mount before you could mark it readonly, i.e. sudo mount -t tmpfs tmpfs /tmp/a sudo mount --bind /tmp/a /tmp/b sudo mount -o remount,ro /tmp/b /tmp/b Interesting point. Very interesting. I guess I can dig into it an look it up but, what rev did that commit show up in and does it impact the way we handle things dependent on kernel version? Oh, it's older than I thought. Came between 3.2 and 3.3. But no, it makes some things easier but shouldn't affect anything we do negatively. -serge -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] doc: Japanese man pages is not generated when docbook-utils is used
On Wed, Sep 25, 2013 at 07:36:30PM +0900, KATOH Yasufumi wrote: Character encoding of Japanese man pages is UTF-8. But docbook-utils can't treat it (and don't have --encoding option that use in Makefile). So change to Japanese man pages is not generated when docbook-utils is used. Signed-off-by: KATOH Yasufumi ka...@jazz.email.ne.jp Acked-by: Stéphane Graber stgra...@ubuntu.com --- configure.ac| 1 + doc/Makefile.am | 9 +++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a523583..092a67d 100644 --- a/configure.ac +++ b/configure.ac @@ -91,6 +91,7 @@ if test x$enable_doc = xyes -o x$enable_doc = xauto; then AC_SUBST(db2xman) fi AM_CONDITIONAL([ENABLE_DOCBOOK], [test x$db2xman != x]) +AM_CONDITIONAL([USE_DOCBOOK2X], [test x$db2xman != xdocbook2man]) if test x$db2xman = xdocbook2man; then docdtd=\-//Davenport//DTD DocBook V3.0//EN\ diff --git a/doc/Makefile.am b/doc/Makefile.am index f2a106b..1e83f8a 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,5 +1,10 @@ -SUBDIRS = examples rootfs ja -DIST_SUBDIRS = examples rootfs ja +SUBDIRS = examples rootfs +DIST_SUBDIRS = examples rootfs + +if USE_DOCBOOK2X +SUBDIRS += ja +DIST_SUBDIRS += ja +endif EXTRA_DIST = \ FAQ.txt -- 1.8.1.4 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 7cb14f: doc: Japanese man pages is not generated when docb...
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 7cb14f34a92e0a8eae07db027344126bf5c901c9 https://github.com/lxc/lxc/commit/7cb14f34a92e0a8eae07db027344126bf5c901c9 Author: KATOH Yasufumi ka...@jazz.email.ne.jp Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: M configure.ac M doc/Makefile.am Log Message: --- doc: Japanese man pages is not generated when docbook-utils is used Character encoding of Japanese man pages is UTF-8. But docbook-utils can't treat it (and don't have --encoding option that use in Makefile). So change to Japanese man pages is not generated when docbook-utils is used. Signed-off-by: KATOH Yasufumi ka...@jazz.email.ne.jp Acked-by: Stéphane Graber stgra...@ubuntu.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] b65330: split up lxc_cgroup_load_meta2
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: b653309a4aec9b0be859bc7fc23215fad07bdbb2 https://github.com/lxc/lxc/commit/b653309a4aec9b0be859bc7fc23215fad07bdbb2 Author: Serge Hallyn serge.hal...@ubuntu.com Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: M src/lxc/cgroup.c Log Message: --- split up lxc_cgroup_load_meta2 This one's easier to review by looking at the before and after files. It splits up lxc_cgroup_load_meta2() by adding 3 helpers. The result seems easier to reason about. A question I had, is, should the kernel_subsystems ** be freed in the success case? I assumed it was being used elsewhere but I can't find where. Currently it is only being freed in the error case. I suspect we want to free it in the success case as well. Cc: Christian Seiler christ...@iwakd.de Cc: Dwight Engen dwight.en...@oracle.com Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com Commit: 178938fe0ac891092205d76f67af855dcf7397af https://github.com/lxc/lxc/commit/178938fe0ac891092205d76f67af855dcf7397af Author: Dwight Engen dwight.en...@oracle.com Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: M src/lxc/cgroup.c Log Message: --- fix some larger memory leaks in cgroup code Don't worry about saved_errno since none of the *_free routines will set it Signed-off-by: Dwight Engen dwight.en...@oracle.com Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com Compare: https://github.com/lxc/lxc/compare/7cb14f34a92e...178938fe0ac8 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [lxc/lxc] b65330: split up lxc_cgroup_load_meta2
Hi there, The result seems easier to reason about. I agree, thanks! A question I had, is, should the kernel_subsystems ** be freed in the success case? I assumed it was being used elsewhere but I can't find where. Currently it is only being freed in the error case. I suspect we want to free it in the success case as well. Yes, I agree completely. Sorry I didn't notice that when writing the function. -- Christian -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: Device Namespaces
I've been looking at this problem for some time to help solve my very specific use case. In our case we are using containers to provide individual desktops to a number of users. We want the desktop to run X, and bind and unbind a display, keyboard, mouse to that X server running in a particular container, and not be able to grab anyone elses keyboard, mouse or display unless granted specific access to that from the owern. To that end, I started worked on a udev solution. I understand that most containers don't/won't run udev. And systemd won't even start udev if the container doesn't have the mknod capability which is a kinda odd cookie but I digress. Currently the kernel effectively broadcasts uevents to all network namespaces, and this is an issue. I don't want container A to see container B's events. It should see only what the admin has set for the policy for that container. This policy should be handled on the host for the containers in userspace. This deamon can get the events, and then forward to the appropriate container(s) those events that are pertinent, and disregard the rest. To accomplish this, I had to change the broadcast mechanism, and then provide a forwarding mechanism to specific network namespaces. Back in the day, that would have been sufficient. Udev running in the container would have gotten the add event, and created the appropriate devices and symlinks, and then cleaned up on remove/change events. With the introduction of devtmpfs, udev no longer actually creates the device nodes. It just handles links and name changes. So, I'm still left with needing to create/manage devtmpfs or some other solution. This leads me down the path of virtualizing devtmpfs. I've been fooling around with FUSE, to basically mirror the host /dev (filtered appropriately), but there are many ugly security, and implementation details that look bad to me. I have been kicking around the notion that the device cgroup might provide the list of acceptable devices, and construct a filter/view for devtmpfs based on that. I do have these changes working on a mostly stock 3.10 kernel, the kernel changes are pretty small, and the deamon does a pretty minimal filtering mostly to demonstrate functionality. It does assume that the containers are running in a separate network namespace, but that's about it. Of course, that still leaves you with sysfs needing similar treatment. ---Michael J Coss -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 2/2] fix some larger memory leaks in cgroup code
Uhh something is wrong with this commit
(178938fe0ac891092205d76f67af855dcf7397af), both go bindings and some lxc
tools started to seg fault
sudo lxc-ps
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
CONTAINER PID TTY TIME CMD
27168 pts/200:00:00 ps
27169 pts/200:00:00 awk
27061 pts/200:00:00 sudo
27062 pts/200:00:00 lxc-ps
reverting 178938fe0a makes things OK again.
On Tue, Sep 24, 2013 at 7:46 PM, Serge Hallyn serge.hal...@ubuntu.comwrote:
From: Dwight Engen dwight.en...@oracle.com
Don't worry about saved_errno since none of the *_free routines will set it
Signed-off-by: Dwight Engen dwight.en...@oracle.com
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/cgroup.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
index 72abc2f..730d3b7 100644
--- a/src/lxc/cgroup.c
+++ b/src/lxc/cgroup.c
@@ -296,7 +296,7 @@ static bool find_hierarchy_mountpts( struct
cgroup_meta_data *meta_data, char **
return false;
while (getline(line, sz, proc_self_mountinfo) != -1) {
- char *token, *saveptr = NULL;
+ char *token, *line_tok, *saveptr = NULL;
size_t i, j, k;
struct cgroup_mount_point *mount_point;
struct cgroup_hierarchy *h;
@@ -305,7 +305,7 @@ static bool find_hierarchy_mountpts( struct
cgroup_meta_data *meta_data, char **
if (line[0] line[strlen(line) - 1] == '\n')
line[strlen(line) - 1] = '\0';
- for (i = 0; (token = strtok_r(line, , saveptr)); line
= NULL) {
+ for (i = 0, line_tok = line; (token = strtok_r(line_tok,
, saveptr)); line_tok = NULL) {
r = lxc_grow_array((void ***)tokens,
token_capacity, i + 1, 64);
if (r 0)
goto out;
@@ -477,6 +477,7 @@ struct cgroup_meta_data *lxc_cgroup_put_meta(struct
cgroup_meta_data *meta_data)
lxc_cgroup_hierarchy_free(meta_data-hierarchies[i]);
}
free(meta_data-hierarchies);
+ free(meta_data);
return NULL;
}
@@ -1103,29 +1104,30 @@ char *lxc_cgroup_get_hierarchy_abs_path(const char
*subsystem, const char *name,
struct cgroup_process_info *base_info, *info;
struct cgroup_mount_point *mp;
char *result = NULL;
- int saved_errno;
meta = lxc_cgroup_load_meta();
if (!meta)
return NULL;
base_info = lxc_cgroup_get_container_info(name, lxcpath, meta);
if (!base_info)
- return NULL;
+ goto out1;
info = find_info_for_subsystem(base_info, subsystem);
if (!info)
- return NULL;
+ goto out2;
if (info-designated_mount_point) {
mp = info-designated_mount_point;
} else {
mp = lxc_cgroup_find_mount_point(info-hierarchy,
info-cgroup_path, true);
if (!mp)
- return NULL;
+ goto out3;
}
result = cgroup_to_absolute_path(mp, info-cgroup_path, NULL);
- saved_errno = errno;
+out3:
+ lxc_cgroup_process_info_free(info);
+out2:
lxc_cgroup_process_info_free(base_info);
+out1:
lxc_cgroup_put_meta(meta);
- errno = saved_errno;
return result;
}
--
1.8.3.2
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
S.Çağlar Onur cag...@10ur.org
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
Re: [lxc-devel] [PATCH 2/2] fix some larger memory leaks in cgroup code
On Wed, 25 Sep 2013 14:44:07 -0400
S.Çağlar Onur cag...@10ur.org wrote:
Uhh something is wrong with this commit
Hey Serge, I think this has to do with the rebase after the split up as
it certinaly wasn't seg faulting on me originally. The split also
appears to have introduced a couple new leaks (ie. line in the
subfunctions). Do you want me to just redo the cleanup fds memory
stuff on top of your change?
(178938fe0ac891092205d76f67af855dcf7397af), both go bindings and some
lxc tools started to seg fault
sudo lxc-ps
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
CONTAINER PID TTY TIME CMD
27168 pts/200:00:00 ps
27169 pts/200:00:00 awk
27061 pts/200:00:00 sudo
27062 pts/200:00:00 lxc-ps
reverting 178938fe0a makes things OK again.
On Tue, Sep 24, 2013 at 7:46 PM, Serge Hallyn
serge.hal...@ubuntu.comwrote:
From: Dwight Engen dwight.en...@oracle.com
Don't worry about saved_errno since none of the *_free routines
will set it
Signed-off-by: Dwight Engen dwight.en...@oracle.com
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/cgroup.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
index 72abc2f..730d3b7 100644
--- a/src/lxc/cgroup.c
+++ b/src/lxc/cgroup.c
@@ -296,7 +296,7 @@ static bool find_hierarchy_mountpts( struct
cgroup_meta_data *meta_data, char **
return false;
while (getline(line, sz, proc_self_mountinfo) != -1) {
- char *token, *saveptr = NULL;
+ char *token, *line_tok, *saveptr = NULL;
size_t i, j, k;
struct cgroup_mount_point *mount_point;
struct cgroup_hierarchy *h;
@@ -305,7 +305,7 @@ static bool find_hierarchy_mountpts( struct
cgroup_meta_data *meta_data, char **
if (line[0] line[strlen(line) - 1] == '\n')
line[strlen(line) - 1] = '\0';
- for (i = 0; (token = strtok_r(line, ,
saveptr)); line = NULL) {
+ for (i = 0, line_tok = line; (token =
strtok_r(line_tok, , saveptr)); line_tok = NULL) {
r = lxc_grow_array((void ***)tokens,
token_capacity, i + 1, 64);
if (r 0)
goto out;
@@ -477,6 +477,7 @@ struct cgroup_meta_data
*lxc_cgroup_put_meta(struct cgroup_meta_data *meta_data)
lxc_cgroup_hierarchy_free(meta_data-hierarchies[i]);
}
free(meta_data-hierarchies);
+ free(meta_data);
return NULL;
}
@@ -1103,29 +1104,30 @@ char
*lxc_cgroup_get_hierarchy_abs_path(const char *subsystem, const
char *name, struct cgroup_process_info *base_info, *info;
struct cgroup_mount_point *mp;
char *result = NULL;
- int saved_errno;
meta = lxc_cgroup_load_meta();
if (!meta)
return NULL;
base_info = lxc_cgroup_get_container_info(name, lxcpath,
meta); if (!base_info)
- return NULL;
+ goto out1;
info = find_info_for_subsystem(base_info, subsystem);
if (!info)
- return NULL;
+ goto out2;
if (info-designated_mount_point) {
mp = info-designated_mount_point;
} else {
mp = lxc_cgroup_find_mount_point(info-hierarchy,
info-cgroup_path, true);
if (!mp)
- return NULL;
+ goto out3;
}
result = cgroup_to_absolute_path(mp, info-cgroup_path,
NULL);
- saved_errno = errno;
+out3:
+ lxc_cgroup_process_info_free(info);
+out2:
lxc_cgroup_process_info_free(base_info);
+out1:
lxc_cgroup_put_meta(meta);
- errno = saved_errno;
return result;
}
--
1.8.3.2
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
most from
the latest Intel processors and coprocessors. See abstracts and
register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___ Lxc-devel mailing
list Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
Re: [lxc-devel] [PATCH 2/2] fix some larger memory leaks in cgroup code
Quoting S.Çağlar Onur (cag...@10ur.org): Uhh something is wrong with this commit (178938fe0ac891092205d76f67af855dcf7397af), both go bindings and some lxc tools started to seg fault sudo lxc-ps Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) CONTAINER PID TTY TIME CMD 27168 pts/200:00:00 ps 27169 pts/200:00:00 awk 27061 pts/200:00:00 sudo 27062 pts/200:00:00 lxc-ps reverting 178938fe0a makes things OK again. Yeah I don't know why that didn't happen in my testing last night. lxc-list also bugs out. It seems to be the lxc_cgroup_process_info_free(info). -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 3a0abb: free kernel_subsystems in success case
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 3a0abb3aa21dda3679f4353926ebdd4c51ea0d0f https://github.com/lxc/lxc/commit/3a0abb3aa21dda3679f4353926ebdd4c51ea0d0f Author: Serge Hallyn serge.hal...@ubuntu.com Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: M src/lxc/cgroup.c Log Message: --- free kernel_subsystems in success case Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: Device Namespaces
Janne Karhunen janne.karhu...@gmail.com writes: That being said, is there a valid reason why binder is part of device namespace here instead of IPC? I think the practical issue with binder was simply that binder only allows for a single instance and thus is does not play nicely with containers. Eric -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [lxc/lxc] b65330: split up lxc_cgroup_load_meta2
Quoting Christian Seiler (christ...@iwakd.de): Hi there, The result seems easier to reason about. I agree, thanks! A question I had, is, should the kernel_subsystems ** be freed in the success case? I assumed it was being used elsewhere but I can't find where. Currently it is only being freed in the error case. I suspect we want to free it in the success case as well. Yes, I agree completely. Sorry I didn't notice that when writing the function. Thanks. I pushed the following commit to github: [PATCH 1/1] free kernel_subsystems in success case Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com --- src/lxc/cgroup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c index babe0b7..e27bc03 100644 --- a/src/lxc/cgroup.c +++ b/src/lxc/cgroup.c @@ -451,6 +451,7 @@ struct cgroup_meta_data *lxc_cgroup_load_meta2(const char **subsystem_whitelist) goto out_error; } + lxc_free_array((void **)kernel_subsystems, free); return meta_data; out_error: -- 1.8.1.2 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 0ccf7c: REALLY always free(line)
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 0ccf7c2a63da5482b2eeffb87cd693eedeec645e https://github.com/lxc/lxc/commit/0ccf7c2a63da5482b2eeffb87cd693eedeec645e Author: Serge Hallyn serge.hal...@ubuntu.com Date: 2013-09-25 (Wed, 25 Sep 2013) Changed paths: M src/lxc/cgroup.c Log Message: --- REALLY always free(line) Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 2/2] fix some larger memory leaks in cgroup code
On Wed, 25 Sep 2013 15:08:37 -0500 Serge Hallyn serge.hal...@ubuntu.com wrote: Quoting Dwight Engen (dwight.en...@oracle.com): On Wed, 25 Sep 2013 14:44:07 -0400 S.Çağlar Onur cag...@10ur.org wrote: Uhh something is wrong with this commit Hey Serge, I think this has to do with the rebase after the split up as it certinaly wasn't seg faulting on me originally. The split also Yeah, sorry. I'd lost the free(line) when moving code. I'm not quite sure how the lxc_cgroup_process_info_free(info) at the out3: label could have actually worked for you, but maybe I dropped a zeroing out Hmm, yeah I'm not sure why I didn't hit that in my testing with lxc-test-concurrent. I agree with you that it shouldn't be free()ed as it just points at one of the info's of base_info and isn't a new alloc. of something somewhere. appears to have introduced a couple new leaks (ie. line in the subfunctions). Do you want me to just redo the cleanup fds memory stuff on top of your change? If you see any more bits I stupidly dropped in current git head, please do. I'm going to get going on the selinux patch now. Okay, it looks like you didn't merge any of the first one (cleanup fds, memory in lxc_cgroup_load_meta2()) so I'll look at rebasing that on git head, re-valgrind, and resubmit. Thanks. thanks, -serge -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 2/2] fix some larger memory leaks in cgroup code
Quoting Dwight Engen (dwight.en...@oracle.com): Okay, it looks like you didn't merge any of the first one (cleanup fds, memory in lxc_cgroup_load_meta2()) so I'll look at rebasing that on git head, re-valgrind, and resubmit. Thanks. Thanks! -serge -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: Device Namespaces
Jeremy Andrus jere...@cs.columbia.edu writes: On Sep 25, 2013, at 4:23 PM, Eric W. Biederman ebied...@xmission.com wrote: Janne Karhunen janne.karhu...@gmail.com writes: That being said, is there a valid reason why binder is part of device namespace here instead of IPC? I think the practical issue with binder was simply that binder only allows for a single instance and thus is does not play nicely with containers. It's true that there was a singleton paradigm in binder that had to be overcome, but I agree with Janne. It really belongs in the IPC namespace, and I don't see any technical reason not to move it there. *Blink* I missed the IPC namespace suggestion. The IPC namespace sounds reasonable. Of course binder is still in staging because it has implementation and ABI problems. Little things like a 64bit kernel and a 32bit userspace don't work particularly well. So while fixing those problems it might be possible to fix the single container problem as well. It would be a weird direction for cleanup of binder to come from but I don't see why that wouldn't work. Personally until binder is out of staging it seems reasonable to push for an API that sucks less, or for a more general solution that Androdid could use instead of binder. One of the uses of namespaces is to clean up after problematic kernel design decisions. If we still have the option I would rather fix the problems than clean up after them. Eric -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 2/2] fix some larger memory leaks in cgroup code
On Wed, Sep 25, 2013 at 4:56 PM, Serge Hallyn serge.hal...@ubuntu.comwrote: Quoting Dwight Engen (dwight.en...@oracle.com): Okay, it looks like you didn't merge any of the first one (cleanup fds, memory in lxc_cgroup_load_meta2()) so I'll look at rebasing that on git head, re-valgrind, and resubmit. Thanks. Thanks! -serge Much better now, thanks! -- S.Çağlar Onur cag...@10ur.org -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [minor] Changing the version naming
Hey, It's not that important but I just wanted to learn your thoughts about starting to use more predictable version names for releases. I was trying to do some stuff based on the LXC version that is installed on the system and realized that current naming is little different than what I was expecting. Do you think something like following (and also starting to use http://semver.org/ kind of naming) is acceptable? diff --git a/configure.ac b/configure.ac index a523583..f466a43 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ # -*- Autoconf -*- # Process this file with autoconf to produce a configure script. -AC_INIT([lxc], [1.0.0.alpha1]) +AC_INIT([lxc], [1.0.0-alpha1]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_AUX_DIR([config]) Best, -- S.Çağlar Onur cag...@10ur.org -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: Device Namespaces
On Sep 25, 2013, at 4:23 PM, Eric W. Biederman ebied...@xmission.com wrote: Janne Karhunen janne.karhu...@gmail.com writes: That being said, is there a valid reason why binder is part of device namespace here instead of IPC? I think the practical issue with binder was simply that binder only allows for a single instance and thus is does not play nicely with containers. It's true that there was a singleton paradigm in binder that had to be overcome, but I agree with Janne. It really belongs in the IPC namespace, and I don't see any technical reason not to move it there. -Jeremy -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [minor] Changing the version naming
On Wed, Sep 25, 2013 at 05:48:26PM -0400, S.Çağlar Onur wrote: Hey, It's not that important but I just wanted to learn your thoughts about starting to use more predictable version names for releases. I was trying to do some stuff based on the LXC version that is installed on the system and realized that current naming is little different than what I was expecting. Do you think something like following (and also starting to use http://semver.org/ kind of naming) is acceptable? diff --git a/configure.ac b/configure.ac index a523583..f466a43 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ # -*- Autoconf -*- # Process this file with autoconf to produce a configure script. -AC_INIT([lxc], [1.0.0.alpha1]) +AC_INIT([lxc], [1.0.0-alpha1]) AC_CONFIG_SRCDIR([configure.ac]) AC_CONFIG_AUX_DIR([config]) Best, It doesn't really matter to me or to any of the Debian based distros, but I seem to remember the version number being a problem to the RPM based distros in the past, so I'd rather not change the format unless we first make sure it's going to work with everyone's packaging. (And if we do change format, I'd only start doing it with alpha2 to avoid some extra confusion) -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] fix segfault on lxc-create with bad template name
- change get_template_path() to only return NULL or non-NULL since one of
the callers was doing a free(-1) which caused the segfault. Handle the
NULL template case in the lxcapi_create() caller.
- make sure to free(tpath) in the sha1sum_file() failure case
Signed-off-by: Dwight Engen dwight.en...@oracle.com
---
src/lxc/lxccontainer.c | 45 -
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index f5d41b3..d3f5b0d 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -713,38 +713,32 @@ static struct bdev *do_bdev_create(struct lxc_container
*c, const char *type,
/*
* Given the '-t' template option to lxc-create, figure out what to
* do. If the template is a full executable path, use that. If it
- * is something like 'sshd', then return $templatepath/lxc-sshd. If
- * no template was passed in, return NULL (this is ok).
- * On error return (char *) -1.
+ * is something like 'sshd', then return $templatepath/lxc-sshd.
+ * On success return the template, on error return NULL.
*/
-char *get_template_path(const char *t)
+static char *get_template_path(const char *t)
{
int ret, len;
char *tpath;
- if (!t)
- return NULL;
-
if (t[0] == '/' access(t, X_OK) == 0) {
tpath = strdup(t);
- if (!tpath)
- return (char *) -1;
return tpath;
}
len = strlen(LXCTEMPLATEDIR) + strlen(t) + strlen(/lxc-) + 1;
tpath = malloc(len);
if (!tpath)
- return (char *) -1;
+ return NULL;
ret = snprintf(tpath, len, %s/lxc-%s, LXCTEMPLATEDIR, t);
if (ret 0 || ret = len) {
free(tpath);
- return (char *) -1;
+ return NULL;
}
if (access(tpath, X_OK) 0) {
SYSERROR(bad template: %s\n, t);
free(tpath);
- return (char *) -1;
+ return NULL;
}
return tpath;
@@ -917,20 +911,19 @@ bool prepend_lxc_header(char *path, const char *t, char
*const argv[])
#if HAVE_LIBGNUTLS
tpath = get_template_path(t);
- if (tpath == (char *) -1) {
+ if (!tpath) {
ERROR(bad template: %s\n, t);
goto out_free_contents;
}
- if (tpath) {
- have_tpath = true;
- ret = sha1sum_file(tpath, md_value);
- if (ret 0) {
- ERROR(Error getting sha1sum of %s, tpath);
- goto out_free_contents;
- }
+ have_tpath = true;
+ ret = sha1sum_file(tpath, md_value);
+ if (ret 0) {
+ ERROR(Error getting sha1sum of %s, tpath);
free(tpath);
+ goto out_free_contents;
}
+ free(tpath);
#endif
process_lock();
@@ -1006,16 +999,18 @@ static bool lxcapi_create(struct lxc_container *c, const
char *t,
{
bool bret = false;
pid_t pid;
- char *tpath;
+ char *tpath = NULL;
int partial_fd;
if (!c)
return false;
- tpath = get_template_path(t);
- if (tpath == (char *) -1) {
- ERROR(bad template: %s\n, t);
- goto out;
+ if (t) {
+ tpath = get_template_path(t);
+ if (!tpath) {
+ ERROR(bad template: %s\n, t);
+ goto out;
+ }
}
if (!c-save_config(c, NULL)) {
--
1.8.1.4
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH v2 rebased against github master 9d0cda4f] refactor AppArmor into LSM backend, add SELinux support
Quoting Dwight Engen (dwight.en...@oracle.com): Currently, a maximum of one LSM within LXC will be initialized and used. If in the future stacked LSMs become a reality, we can support it without changing the configuration syntax and add support for more than a single LSM at a time to the lsm code. Generic LXC code should note that lsm_process_label_set() will take effect now for AppArmor, and upon exec() for SELinux. Ah, that's right, lxc-attach doesn't always exec a new task, right? So that's where the selinux behavior may be a problem. -serge -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] fix segfault on lxc-create with bad template name
Quoting Dwight Engen (dwight.en...@oracle.com):
- change get_template_path() to only return NULL or non-NULL since one of
the callers was doing a free(-1) which caused the segfault. Handle the
NULL template case in the lxcapi_create() caller.
Hm, some people really do want to run lxc-create without a template
though. I'm not terribly attached to that idea, but I don't want to
break it if we can help it - would it solve it to just set tpath = NULL
right after
ERROR(bad template: %s\n, t);
and before the goto out?
- make sure to free(tpath) in the sha1sum_file() failure case
Signed-off-by: Dwight Engen dwight.en...@oracle.com
---
src/lxc/lxccontainer.c | 45 -
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index f5d41b3..d3f5b0d 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -713,38 +713,32 @@ static struct bdev *do_bdev_create(struct lxc_container
*c, const char *type,
/*
* Given the '-t' template option to lxc-create, figure out what to
* do. If the template is a full executable path, use that. If it
- * is something like 'sshd', then return $templatepath/lxc-sshd. If
- * no template was passed in, return NULL (this is ok).
- * On error return (char *) -1.
+ * is something like 'sshd', then return $templatepath/lxc-sshd.
+ * On success return the template, on error return NULL.
*/
-char *get_template_path(const char *t)
+static char *get_template_path(const char *t)
{
int ret, len;
char *tpath;
- if (!t)
- return NULL;
-
if (t[0] == '/' access(t, X_OK) == 0) {
tpath = strdup(t);
- if (!tpath)
- return (char *) -1;
return tpath;
}
len = strlen(LXCTEMPLATEDIR) + strlen(t) + strlen(/lxc-) + 1;
tpath = malloc(len);
if (!tpath)
- return (char *) -1;
+ return NULL;
ret = snprintf(tpath, len, %s/lxc-%s, LXCTEMPLATEDIR, t);
if (ret 0 || ret = len) {
free(tpath);
- return (char *) -1;
+ return NULL;
}
if (access(tpath, X_OK) 0) {
SYSERROR(bad template: %s\n, t);
free(tpath);
- return (char *) -1;
+ return NULL;
}
return tpath;
@@ -917,20 +911,19 @@ bool prepend_lxc_header(char *path, const char *t, char
*const argv[])
#if HAVE_LIBGNUTLS
tpath = get_template_path(t);
- if (tpath == (char *) -1) {
+ if (!tpath) {
ERROR(bad template: %s\n, t);
goto out_free_contents;
}
- if (tpath) {
- have_tpath = true;
- ret = sha1sum_file(tpath, md_value);
- if (ret 0) {
- ERROR(Error getting sha1sum of %s, tpath);
- goto out_free_contents;
- }
+ have_tpath = true;
+ ret = sha1sum_file(tpath, md_value);
+ if (ret 0) {
+ ERROR(Error getting sha1sum of %s, tpath);
free(tpath);
+ goto out_free_contents;
}
+ free(tpath);
#endif
process_lock();
@@ -1006,16 +999,18 @@ static bool lxcapi_create(struct lxc_container *c,
const char *t,
{
bool bret = false;
pid_t pid;
- char *tpath;
+ char *tpath = NULL;
int partial_fd;
if (!c)
return false;
- tpath = get_template_path(t);
- if (tpath == (char *) -1) {
- ERROR(bad template: %s\n, t);
- goto out;
+ if (t) {
+ tpath = get_template_path(t);
+ if (!tpath) {
+ ERROR(bad template: %s\n, t);
+ goto out;
+ }
}
if (!c-save_config(c, NULL)) {
--
1.8.1.4
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
