[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