Quoting Seth Arnold (509...@bugs.launchpad.net): > Urgh. sorry for losing track of this bug. I forgot to subscribe after > submitting my comment. > > I believe your proposed additional check would be sufficient. I _think_ > better might be to destroy the lock pointer in the shared structure when > freeing the object but before unlocking -- preventing other threads from > acquiring the lock once the free path has started.
Just to help myself think through this, freer | racing get()er lxc_container_put() \ lxclock(c->privlock) lxc_container_get() \ c->numthreads = 0 \ lxclock(c->privlock) -> waits \ lxcunlock \ \ lxc_container_free \ lxclock() returns \ c->numthreads < 1 -> return \ \ (free stuff) \ \ sem_destroy(privlock) So lxclock() needs to check that sem is not NULL as you said before; Setting c->privlock = NULL before calling sem_destroy on (a copy of :) it will help another race - I think that is what you are suggesting here. I'm trying to figure out if there is still a possible race with that, where the get()er dereferences c->privlock, then put()er sets c->privlock = NULL and sem_destroy()s it, then get()er calls sem_wait(), resulting in 'undefined behavior' per the man page. -- 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