summaryrefslogtreecommitdiff
path: root/vendor
diff options
context:
space:
mode:
authorMatthew Heon <matthew.heon@pm.me>2019-12-02 23:06:00 -0500
committerMatthew Heon <matthew.heon@pm.me>2019-12-02 23:06:00 -0500
commit689329f7495c1fc4f035fe3f39be28375987faf8 (patch)
treeb99b70b1d8825b7ef64889b76e27674a50dd07a1 /vendor
parentc9696c451df1efe181c103f9f227787af14dd7b1 (diff)
downloadpodman-689329f7495c1fc4f035fe3f39be28375987faf8.tar.gz
podman-689329f7495c1fc4f035fe3f39be28375987faf8.tar.bz2
podman-689329f7495c1fc4f035fe3f39be28375987faf8.zip
Ensure volumes reacquire locks on state refresh
After a restart, pods and containers both run a refresh() function to prepare to run after a reboot. Until now, volumes have not had a similar function, because they had no per-boot setup to perform. Unfortunately, this was not noticed when in-memory locking was introduced to volumes. The refresh() routine is, among other things, responsible for ensuring that locks are reserved after a reboot, ensuring they cannot be taken by a freshly-created container, pod, or volume. If this reservation is not done, we can end up with two objects using the same lock, potentially needing to lock each other for some operations - classic recipe for deadlocks. Add a refresh() function to volumes to perform lock reservation and ensure it is called as part of overall refresh(). Fixes #4605 Fixes #4621 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Diffstat (limited to 'vendor')
0 files changed, 0 insertions, 0 deletions