summaryrefslogtreecommitdiff
path: root/libpod/boltdb_state_linux.go
diff options
context:
space:
mode:
authorMatthew Heon <matthew.heon@pm.me>2022-09-12 16:28:45 -0400
committerMatthew Heon <matthew.heon@pm.me>2022-09-14 13:44:48 -0400
commite19e0de5faf31137fa0197ea014d4615e641d33a (patch)
tree0c2781c55126e2d571a8a4f220173b1c9d37253e /libpod/boltdb_state_linux.go
parent017d81ddd0e8d228aadb949175c0aae1e4b9d925 (diff)
downloadpodman-e19e0de5faf31137fa0197ea014d4615e641d33a.tar.gz
podman-e19e0de5faf31137fa0197ea014d4615e641d33a.tar.bz2
podman-e19e0de5faf31137fa0197ea014d4615e641d33a.zip
Introduce graph-based pod container removal
Originally, during pod removal, we locked every container in the pod at once, did a number of validity checks to ensure everything was safe, and then removed all the containers in the pod. A deadlock was recently discovered with this approach. In brief, we cannot lock the entire pod (or much more than a single container at a time) without causing a deadlock. As such, we converted to an approach where we just looped over each container in the pod, removing them individually. Unfortunately, this removed a lot of the validity checking of the earlier approach, allowing for a lot of unintended bad things. Infra containers could be removed while containers in the pod still depended on them, for example. There's no easy way to do validity checks while in a simple loop, so I implemented a version of our graph-traversal logic that currently handles pod start. This version acts in the reverse order of startup: startup starts from containers which depend on nothing and moves outwards, while removal acts on containers which have nothing depend on them and moves inwards. By doing graph traversal, we can guarantee that nothing is removed while something that depends on it still exists - so the infra container should be the last thing in a pod that is removed, for example. In the (unlikely) case that a graph of the pod's containers cannot be built (most likely impossible without database editing) the old method of pod removal has been retained to ensure that even misbehaving pods can be forcibly evicted from the state. I'm fairly confident that this resolves the problem, but there are a lot of assumptions around dependency structure built into the original pod removal code and I am not 100% sure I have captured all of them. Fixes #15526 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Diffstat (limited to 'libpod/boltdb_state_linux.go')
0 files changed, 0 insertions, 0 deletions