You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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).
The text was updated successfully, but these errors were encountered: