Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify and fix cache volume locking #4352

Merged
merged 5 commits into from
Oct 20, 2022

Conversation

mtrmac
Copy link
Contributor

@mtrmac mtrmac commented Oct 19, 2022

What type of PR is this?

/kind bug

What this PR does / why we need it:

  • Simplify the handling of “target locks” used for cache volumes with sharing=locked (an undocumented feature AFAICS): Pass around lock objects instead of files, completely eliminating various error paths
  • Ensure that the locks are unlocked on error paths throughout the call stack.
  • (This also eliminates reliance on Lockfile.Locked, which is going away in API break: Remove Lockfile.Locked storage#1399 ).

How to verify it

Existing tests? I didn’t even try running the code.

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

Cc: @flouthoc who added the feature in #3820.

Does this PR introduce a user-facing change?

None

@mtrmac
Copy link
Contributor Author

mtrmac commented Oct 19, 2022

This adds no new tests:

  • The fix for multiple mounts is not tested because locking for a single mount does not have an effective test either
  • The error handling fixes would require us to trigger errors, and use an execution mechanism where we use the locks multiple times (because all locks are released on a process exit). I don’t understand the features enough to design that right now.

@flouthoc
Copy link
Collaborator

Could we get this in first please #4349 and then we can rebase the current PR ?

@mtrmac
Copy link
Contributor Author

mtrmac commented Oct 19, 2022

Sure. The overlap is actually pretty small.

@flouthoc
Copy link
Collaborator

@mtrmac Could you rebase please :)

They exist in memory anyway, so this is more efficient:
we avoid the need to manually touch the filesystem again,
the associated costs - and the error paths go away.

[NO NEW TESTS NEEDED]

Signed-off-by: Miloslav Trmač <[email protected]>
By construction it's now quite clear that the locks should
always be locked.

Don't even bother with AssertLockedForWriting(), that's
partially (checking for lock ownership, not for read-write ownership)
implied by Unlock() already.

[NO NEW TESTS NEEDED]

Signed-off-by: Miloslav Trmač <[email protected]>
Maintain a list of _all_ the locks, not just the last one.

Signed-off-by: Miloslav Trmač <[email protected]>
It can return at most one lock, so don't return an array.

Should not change behavior right now, but it will simplify
cleanup.

[NO NEW TESTS NEEDED]

Signed-off-by: Miloslav Trmač <[email protected]>
internal/parse/parse.go Outdated Show resolved Hide resolved
@rhatdan
Copy link
Member

rhatdan commented Oct 19, 2022

Other then spelling mistake LGTM

... and use a more traditional error handling model,
where responsibility for the cleanup passes to the caller
_only_ if the called function succeeds.

To reinforce that, hard-code nil returns on error paths
instead of returning the locks.

Signed-off-by: Miloslav Trmač <[email protected]>
@rhatdan
Copy link
Member

rhatdan commented Oct 19, 2022

Copy link
Member

@vrothberg vrothberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

Copy link
Collaborator

@flouthoc flouthoc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
/approve
/lgtm

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 20, 2022

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: flouthoc, mtrmac

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 60f14cf into containers:main Oct 20, 2022
@mtrmac mtrmac deleted the cache-locks branch October 20, 2022 13:48
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants