Re: struct file reference at VFS level

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

> On 22 Apr 2016, at 17:33, Emmanuel Dreyfus <manu%netbsd.org@localhost> 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 - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)