David Holland <dholland-t...@netbsd.org> wrote: > If something in fuse is causing these cases to share the same open and > thus the same struct file, fuse is broken. Fix fuse first. > > If that isn't what's happening, the next possible problem is that > puffs/refuse/whatnot is the losing IO_NDELAY flag of VOP_WRITE. If so, > fuse is broken. Fix fuse first.
If you want to implement mandatory locks, the O_NONBLOCK / IO_NDELAY just determines how a failure should occur: by waiting for the lock to be released, or by failing with EAGAIN. In order to decide whether an I/O will succeed or fail because of a mandatory lock, the filesystem must know if there is a lock on the file, and in the case there is a lock, whether it is held by the caller or not. As I understand, telling if a lock is held by caller requires a reference to the struct file on which the operation was issued. If we reconsider the proposed scenario without process 2 using O_NONBLOCK, then a write by process 2 must wait for the lock to be released, while a write by process 1 must succeed without delay. But when the requests come at the filesystem level, there is no way to distinguish them. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
