Hi Seth, thanks very much for the review.
> Everything else:
>
> - Calling lxc_container_free() _after_ releasing the privlock feels wrong
> - lxc_container_get() may follow stale pointers while locking
> - lxc_container_put() could be freeing an object that was acquired
I think this was an unintented bug. Note that
1. lxc_container_free() sets c->privlock to NULL
2. lxcunlock() returns an error -2 if c->privlock is NULL
3. lxclock() doesn't do so - I probably accidentally dropped
or forgot to add in that check.
since lxc_container_get() and _put() both return false if lxclock
fails, I adding the needed check in lxclock() this should suffice.
Does that sound ok to you for this item?
If you're up for it, I also wouldn't mind chatting sometime about
the goals and design of the locking. (The comment at top of
lxccontainer.c pretty accurately sums up my goals. It doesn't
mention that running containers are already mutexed by the
monitor UNIX socket in $lxc_path.)
-serge
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/509647
Title:
[MIR] lxc
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/509647/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
