-
Notifications
You must be signed in to change notification settings - Fork 62
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
A few bugfixes #10
A few bugfixes #10
Conversation
Currently bytes_to_cstr() expects one and only one '\0' and the end of the buffer, but we've seen lookup request with name buffer having multiple '\0's at the end and caused failures. To make it more robust, trim extra zeros in buffer, this also follows what virtiofsd does. Signed-off-by: Eryu Guan <eguan@linux.alibaba.com>
Writing fuse replies back to kernel should always return `EncodeMessage` with errors. So writing fuse replies will return unique error code hinting an error happens when replies. Signed-off-by: Changwei Ge <chge@linux.alibaba.com>
virtiofsd uses "none" as one of the cache policies, but passthroughfs uses "never". Support "none" as well to be compatible with virtiofsd's configuration. Signed-off-by: Eryu Guan <eguan@linux.alibaba.com>
If there's an error, we can only signal it if we haven't stored any entries yet - otherwise we'd end up with wrong lookup counts for the entries that are already in the buffer. So we return what we've collected until that point. Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>
The Sys_getdents64 in kernel will pad the name with '\0' bytes up to 8-byte alignment, so @name of LinuxDirent64 may contain a few null terminators. This causes an extra lookup from fuse kernel when called by readdirplus, because kernel path walking only takes name without null terminators, the dentry with more than 1 null terminators added by readdirplus doesn't satisfy the path walking so that kernel has to issue another lookup to get a valid dentry. Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>
cargo clippy --features=fusedev --target-dir target-fusedev -- -Dclippy::all Checking fuse-rs v0.1.0 (/root/git_repo/fuse-backend-rs) error: using `Option.and_then(|x| Some(y))`, which is more succinctly expressed as `map(|x| y)` --> /root/git_repo/fuse-backend-rs/src/transport/fusedev/mod.rs:166:17 | 166 | / e.as_errno() 167 | | .and_then(|r| Some(io::Error::from_raw_os_error(r as i32))) | |_______________________________________________________________________________^ help: try this: `e.as_errno().map(|r| io::Error::from_raw_os_error(r as i32))` | = note: `-D clippy::bind-instead-of-map` implied by `-D clippy::all` = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#bind_instead_of_map Signed-off-by: Changwei Ge <chge@linux.alibaba.com>
Remove some unnecessary map() calls. Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>
It is weird that building failed, I did the same test locally, it ran fine. The test is
|
@liubogithub Maybe rust version problem? |
Looks like it's vm-memory version causing the trouble. So the problem is cause by the fact that vm-virtio needs a feature Update: |
Solved by this PR: cloud-hypervisor/vm-virtio#6 (comment) |
This PR consists of several bug fixes regarding to fuse ops
readdirplus
.