[lxc-devel] [PATCH] tests: Introduce lxc-test-concurrent for testing basic actions concurrently

Serge Hallyn serge.hallyn at ubuntu.com
Sat Sep 14 02:20:36 UTC 2013


Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
> Quoting Dwight Engen (dwight.engen at oracle.com):
> > On Fri, 13 Sep 2013 17:29:53 -0400
> > Dwight Engen <dwight.engen at oracle.com> wrote:
> > 
> > > On Fri, 13 Sep 2013 12:09:55 -0400
> > > S.Çağlar Onur <caglar at 10ur.org> wrote:
> > > 
> > > > Hi Dwight,
> > > > 
> > > > Yes, I only observed a hang so far but not this assertion (in fact I
> > > > don't remember ever seeing that). What I'm seeing is this;
> > > 
> > > Okay, something funny is going on, but I don't know what yet. That
> > > assertion is coming from liblxc.so->libgnutls->libgcrypt and seems to
> > > be complaining that we're unlocking something that is already
> > > unlocked. So I compiled lxc without GNUTLS support (by commenting out
> > > the check for it in configure.ac) and now I get past that and get
> > > hangs similar to yours.
> > > 
> > > Interestingly, I modified your program to just do the create and
> > > destroy and not the start nor stop and I still get the hangs during
> > > the creation part.
> > 
> > Sorry to reply to myself: So now I modified your program to do the
> > create single threaded and everything else threaded (see attached
> > patch) and that doesn't hang for me.
> > 
> > It looked like to me that the hung threads were stuck on process_lock()
> > so I added a backtrace there to debug it a bit more and it looks like
> > the hang is in the flow:
> > 
> >  lxcapi_create()
> >    c->save_config()
> >      container_disk_lock()
> >        lxclock()
> >          process_lock()
> > 
> > Not sure why yet though. Serge, do you think this could have to do with
> > the fork()ing from a thread in that flow?
> 
> Well, we've got save_config() doing an fopen without the process_lock()
> for one thing which is bad.  That could explain it in a few ways - we
> could have corruption due to both tasks changing fdtable at the same
> time, or perhaps because open() is a cancelation point...
> 
> Does doing a process_lock() around the fopen and fclose in
> lxcapi_save_config() fix it?

something like this should be a start:

Subject: api_start: make thread-safe (or at least start to)

Signed-off-by: Serge Hallyn <serge.hallyn at ubuntu.com>
---
 src/lxc/lxccontainer.c | 6 ++++++
 src/lxc/parse.c        | 4 ++++
 2 files changed, 10 insertions(+)

diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index 79237df..3c51c4a 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -665,7 +665,9 @@ static bool create_container_dir(struct lxc_container *c)
 		free(s);
 		return false;
 	}
+	process_lock();
 	ret = mkdir(s, 0755);
+	process_unlock();
 	if (ret) {
 		if (errno == EEXIST)
 			ret = 0;
@@ -1362,11 +1364,15 @@ static bool lxcapi_save_config(struct lxc_container *c, const char *alt_file)
 	if (lret)
 		return false;
 
+	process_lock();
 	fout = fopen(alt_file, "w");
+	process_unlock();
 	if (!fout)
 		goto out;
 	write_config(fout, c->lxc_conf);
+	process_lock();
 	fclose(fout);
+	process_unlock();
 	ret = true;
 
 out:
diff --git a/src/lxc/parse.c b/src/lxc/parse.c
index 26cbbdd..f154b89 100644
--- a/src/lxc/parse.c
+++ b/src/lxc/parse.c
@@ -90,7 +90,9 @@ int lxc_file_for_each_line(const char *file, lxc_file_cb callback, void *data)
 	char *line = NULL;
 	size_t len = 0;
 
+	process_lock();
 	f = fopen(file, "r");
+	process_unlock();
 	if (!f) {
 		SYSERROR("failed to open %s", file);
 		return -1;
@@ -104,7 +106,9 @@ int lxc_file_for_each_line(const char *file, lxc_file_cb callback, void *data)
 
 	if (line)
 		free(line);
+	process_lock();
 	fclose(f);
+	process_unlock();
 	return err;
 }
 
-- 
1.8.3.2





More information about the lxc-devel mailing list