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

Concurrency issue when new mounts are added #411

Closed
NymanRobin opened this issue Apr 30, 2024 · 5 comments
Closed

Concurrency issue when new mounts are added #411

NymanRobin opened this issue Apr 30, 2024 · 5 comments
Labels

Comments

@NymanRobin
Copy link
Contributor

In the filesystem/mountpoint.go file the mountsByDevice map is recreated on each call of update UpdateMountInfo.
This causes problem, if these steps occurs!

  1. Mount is assigned to policy.context
  2. UpdateMountInfo is called
  3. policy.apply is called

This will result in the fact that the policy.context.Mount will have the old memory address from the old mountsByDevice map while the filesystems.findMount will find the new object and then in the comparison the following error will be thrown in the policy.apply function.

(%!w(*actions.ErrDifferentFilesystem=&{0xc00157b130 0xc00208a140}).

This currently affects the ceph-csi project and more information can be found in this issue:
ceph/ceph-csi#4592

I have tested a solution were only the new mount objects are updated and that would at least work for my specific use-case, I will open a PR for this and look forward to any feedback

@josephlr
Copy link
Member

Another approach to fixing this would just be to compare the Mounts by value rather than by pointer.

Happy to review any PR!

@NymanRobin
Copy link
Contributor Author

Great point @josephlr!
I went ahead with the comparison as that removed the responsibility of removing unused mounts from the map and made it a tad bit easier

@ebiggers
Copy link
Collaborator

ebiggers commented May 7, 2024

Fixed by 068b9f8

@ebiggers ebiggers closed this as completed May 7, 2024
@ebiggers ebiggers added the bug label May 7, 2024
@NymanRobin
Copy link
Contributor Author

Thanks for the helping me get this change in @ebiggers and @josephlr!
I've got one more question: when could we expect a new release of fscrypt? Do you have any plans in mind?
I'm asking because I'd like to get this fix into ceph-csi.

@ebiggers
Copy link
Collaborator

ebiggers commented May 7, 2024

There was a release recently, and there haven't been many changes since then, so it probably will be at least a few months before we do another release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants