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

[Filestore] Detect RequestId collisions #2033

Open
qkrorlqr opened this issue Sep 14, 2024 · 0 comments
Open

[Filestore] Detect RequestId collisions #2033

qkrorlqr opened this issue Sep 14, 2024 · 0 comments
Assignees
Labels
filestore Add this label to run only cloud/filestore build and tests on PR

Comments

@qkrorlqr
Copy link
Collaborator

Sometimes guest OS might send us a duplicate fuse_req->unique (aka RequestId in our protocol) field for a new request. We end up looking this RequestId up in the tablet DupCache and if we still haven't evicted the entry for the old request we end up returning the old response (which is not the response to the actual new request). It seems to be a bug in the guest but it's much easier to make a workaround on our side than to fix this behaviour in Linux (and possibly other OS kernels). The workaround is to compare the response that we found in DupCache to the actual request - if they don't match, evict this entry from the cache and treat this request as just a new request.

To make proper comparison, we need to add more data to the responses (which are stored in DupCache). It seems that adding ParentNodeId + Name will be enough to make the probability of a collision indistinguishable from 0. For CreateHandle we can add another check to discard the entries that were persistently stored in DupCaches before this fix - we can simply compare the NodeId from the request to the NodeId from the response for requests without child name (open() by node_id, not by parent_node_id + name).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
filestore Add this label to run only cloud/filestore build and tests on PR
Projects
None yet
Development

No branches or pull requests

1 participant