Wrong locking during more complex prunes #2337
Labels
difficulty/medium
medium complexity/difficutly issue
Comments
|
Yeah, I think you're right. We clearly need a test that tries to reproduce this race. Also, fixing this would require fixing #2286 |
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Apr 15, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Apr 15, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
dbnicholson
pushed a commit
to dbnicholson/ostree
that referenced
this issue
Apr 29, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
dbnicholson
pushed a commit
to dbnicholson/ostree
that referenced
this issue
Jun 5, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
dbnicholson
pushed a commit
to dbnicholson/ostree
that referenced
this issue
Jun 5, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
dbnicholson
pushed a commit
to endlessm/ostree
that referenced
this issue
Jun 7, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev/ostree#2337 Closes: ostreedev/ostree#2286 (cherry picked from commit 0f36d8c) The new symbols have been added to the released symbols file rather than the development symbols file as in the upstream PR since our package does a released build. Similarly, the upstream `LIBOSTREE_2021.3` symbol version has been used so that packages don't need to be rebuilt when we get to that version and drop our backported commits. https://phabricator.endlessm.com/T31868
|
Oh hey, this is fixed by #2808! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While doing some research into pruning I noticed that in ot-builtin-prune.c, if we take the more complex path that uses
ostree_repo_prune_from_reachable()the exclusive repo lock is only held insideostree_repo_prune_from_reachable(), so we compute the reachable set outside the lock.If this where to race with a commit operation that created a new commit which we didn't traverse then it would be pruned away.
The text was updated successfully, but these errors were encountered: