> On 22 Apr 2016, at 17:33, Emmanuel Dreyfus <m...@netbsd.org> wrote: > > On Fri, Apr 22, 2016 at 10:42:10AM -0400, Greg Troxel wrote: >> I still don't understand why this is about FUSE. What if a file were >> opened without O_NONBLOCK and then the same file were opened with? Why >> isn't that the same situation, and the same bug? > > The filesystem below NetBSD VFS cannot make the difference between > operations on the two file descriptors. Generic code above VFS > implements the blocking / non blocking behavior and the filesystem > does not have to handle that. > > Now let us see the locking scenario: > - process 1 opens file foo O_RDWR > - process 2 opens file foo O_RDWR|O_NONBLOCK > - process 1 locks a part of the file > - process 2 atteemps to write to the locked part > > With advisory locks (what we have in our filesystems), the code above > VFS has no reason to block process 2 write operation. The filesystem > could notice there is a lock on the written area, but it cannot enforce > it because it does not distinguish the file descriptors. Hence the write > on locked area succeeds, but this is not a huge problem since the > locks are adivsory. > > With mandatory locks, the filesystem must block process 2 when it > writes. In order to do that it must distinguish the file descriptors, > but NetBSD VFS does not let it do that.
Looks like you want to implement mandatory locking with strange semantics. In your example process 2 writes without locking, is it part of your proposed semantics to add an implicit lock/unlock to read and write operations? If it were written as - process 1 locks a part of the file + process 2 write locks the locked part - process 2 attempts to write to the locked part the lock (+) would return EAGAIN ... Wouldn't it be better to put the mandatory locking at the file->vnode level, operations vn_read() and vn_write()? Could you explain the proposed semantics in detail? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)