-
Notifications
You must be signed in to change notification settings - Fork 323
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
Conflict with Loopback OpenDir, SetLk, and FileHandles #451
Comments
it's possible, but it would be backward incompatible, so if we can avoid it, that would be better. One of the reasons for the current interface (single readdir callwhich returns a dirstream) is that it allows taking a single consistent snapshot of the dir, and that it is easy to implement seeking correctly (see the comment in rawBridge.setStream). I fear that this may become impossible if the DirStream is exposed through OpenDir instead. Why do you want to lock directories? |
@rfjakob FYI - Jakob did a lot of stress testing of the current API, and I wonder what pitfalls he sees if we start returning filehandles from Opendir. |
one alternative is to have loopbackNode.SetLk open the directory to get a file descriptor just for the purpose of locking. |
I'm working on implementing FUSE in gvisor, which aims to implement most of Linux system call interface. I've been using this package to help test the correctness of my implementation, and one our internal tests locks an open directory file and checks for success, since it's allowed on Linux. In my prototype change, I added an interface called I think this satisfies the backwards compatibility requirement — only those who need Having SetLk Open the file itself like you mentioned would also work well with fewer total changes. I could do either, just let me know which is preferable. |
On a side note, I think there is a bug in rawBridge SetLk on this line (same applies for SetLkw). I think that should be |
oh, you're a googler! If you don't mind, can you loop me in on internal bug(s) for this? I usually work on go-fuse in my free time, but if this is related to Google business, I prefer to do it in work time. |
re. bug: yes, that looks wrong. I guess this code does not have enough test coverage. |
I think I'd rather have this. NodeOpenDirFher (aside from the ugly name) will be confusing, because it makes people wonder if they should implement NodeOpener or NodeOpenDirFher. ps. I prefer to use gerrit for review (see CONTRIBUTING) |
The upside I see for NodeOpenDirFher is that it also fixes xfstests generic/035 ( #55 ), and that the |
After looking into this more, I've realized that gVisor's FUSE implementation is incorrect. Linux does not send FUSE SetLk requests to open dir files, it only does it for regular files. See https://github.com/torvalds/linux/blob/master/fs/fuse/file.c#L3204 vs |
I'm using a server backed by the loopback filesystem to perform the following operations:
The SetLk method returns ENOTSUP even though loopbackFile implements the SetLker interface. OPENDIR returns a valid file handle in its response, so this seems like unexpected behavior. Digging further, it looks like Opendir does not register a FileHandle the same way Open does, it just closes it with the closes the fd right after opening. So, when rawBridge's SetLk looks for a file, it doesn't find one associated with the inode and returns ENOTSUP (even though it should be).
An easy solution would be to extend the loopbackNode to implement NodeSetlker, but we still need to get the correct file descriptor somehow. Would it be possible to modify or extend the NodeOpendirer interface to include a method that returns a FileHandle like open? Then we can register this fileHandle with b.registerFile and the issue resolves itself. I already have a patch in the works if this is acceptable.
The text was updated successfully, but these errors were encountered: