Quoting Seth Arnold ([email protected]):
> 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
Bugs, which is subscribed to 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-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
