[lxc-devel] [lxcfs/master] bugfixes

brauner on Github lxc-bot at linuxcontainers.org
Wed Mar 4 10:24:03 UTC 2020


A non-text attachment was scrubbed...
Name: not available
Type: text/x-mailbox
Size: 365 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20200304/54659c64/attachment.bin>
-------------- next part --------------
From 9973cc069b9d4667d3d339252ea46f3cde44de6c Mon Sep 17 00:00:00 2001
From: Christian Brauner <christian.brauner at ubuntu.com>
Date: Wed, 4 Mar 2020 09:07:35 +0100
Subject: [PATCH 1/2] tree-wide: ensure lxcfs_opts is checked

When we only reload the shared library, then lxcfs_opts even with a
newer version of lxcfs will not be valid.

Signed-off-by: Christian Brauner <christian.brauner at ubuntu.com>
---
 bindings.c     | 2 +-
 proc_cpuview.c | 2 +-
 proc_fuse.c    | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/bindings.c b/bindings.c
index 64e6eeb..45a3e57 100644
--- a/bindings.c
+++ b/bindings.c
@@ -244,7 +244,7 @@ static void save_initpid(struct stat *sb, pid_t pid)
 	struct stat st;
 	int ino_hash;
 
-	if (opts->use_pidfd && can_use_pidfd) {
+	if (opts && opts->use_pidfd && can_use_pidfd) {
 		pidfd = pidfd_open(pid, 0);
 		if (pidfd < 0)
 			return;
diff --git a/proc_cpuview.c b/proc_cpuview.c
index 8321840..011975e 100644
--- a/proc_cpuview.c
+++ b/proc_cpuview.c
@@ -906,7 +906,7 @@ int proc_cpuinfo_read(char *buf, size_t size, off_t offset,
 	if (!cpuset)
 		return 0;
 
-	if (cgroup_ops->can_use_cpuview(cgroup_ops) && opts->use_cfs)
+	if (cgroup_ops->can_use_cpuview(cgroup_ops) && (opts && opts->use_cfs))
 		use_view = true;
 
 	if (use_view)
diff --git a/proc_fuse.c b/proc_fuse.c
index c6a972f..0f4798b 100644
--- a/proc_fuse.c
+++ b/proc_fuse.c
@@ -1037,7 +1037,7 @@ static int proc_meminfo_read(char *buf, size_t size, off_t offset,
 	__do_free void *fopen_cache = NULL;
 	__do_fclose FILE *f = NULL;
 	struct fuse_context *fc = fuse_get_context();
-	struct lxcfs_opts *opts = (struct lxcfs_opts *) fuse_get_context()->private_data;
+	struct lxcfs_opts *opts = (struct lxcfs_opts *)fuse_get_context()->private_data;
 	struct file_info *d = INTTYPE_TO_PTR(fi->fh);
 	uint64_t memlimit = 0, memusage = 0, memswlimit = 0, memswusage = 0,
 		 hosttotal = 0;

From 9e69f4431c7ace104054292b6d61999dc87bf6ed Mon Sep 17 00:00:00 2001
From: Christian Brauner <christian.brauner at ubuntu.com>
Date: Wed, 4 Mar 2020 11:22:13 +0100
Subject: [PATCH 2/2] README: add sections about upgrade + musl

Signed-off-by: Christian Brauner <christian.brauner at ubuntu.com>
---
 README.md | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index e2b92ee..7a8e367 100644
--- a/README.md
+++ b/README.md
@@ -26,7 +26,28 @@ Prior to the implementation of cgroup namespaces by Serge Hallyn `LXCFS` also
 provided a container aware `cgroupfs` tree. It took care that the container
 only had access to cgroups underneath it's own cgroups and thus provided
 additional safety. For systems without support for cgroup namespaces `LXCFS`
-will still provide this feature.
+will still provide this feature but it is mostly considered deprecated.
+
+## Upgrading `LXCFS` versions without resart
+
+`LXCFS` is split into a shared library (a libtool module, to be precise)
+`liblxcfs` and a simple binary `lxcfs`. When upgrading to a newer version to
+`LXCFS` the `lxcfs` binary will not be restarted. Instead it will detect that
+a new version of the shared library is available and will reload it using
+`dlclose(3)` and `dlopen(3)`. This design was chosen so that the fuse main loop
+that `LXCFS` uses will not need to be restarted. If it were then all containers
+using `LXCFS` would need to be restarted since they would end up with broken
+fuse mounts otherwise.
+
+### musl
+
+To achieve smooth upgrades through shared library reloads `LXCFS` also relies
+on the fact that when `dlclose(3)` drops the last reference to the shared
+library destructors are run and when `dlopen(3)` is called constructors are
+run. While this is true for `glibc` it is not true for `musl` (See the section
+[Unloading libraries](https://wiki.musl-libc.org/functional-differences-from-glibc.html).).
+So users of `LXCFS` on `musl` are advised to restart `LXCFS` completely and
+- by extension - all containers.
 
 ## Building
 Build lxcfs as follows:


More information about the lxc-devel mailing list