Re: struct file reference at VFS level

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

> On 28 Apr 2016, at 10:19, Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:
> 
>> Wouldn't it be better to put the mandatory locking at the file->vnode
>> level, operations vn_read() and vn_write()?
> 
> Do you mean that instead of providing support so that filesystems 
> can implement mandatory locks, we should just implement it above VFS
> for all filesystems? That would work for local filesystems, but I 
> understand it cannot be done for distributed filesystems, as the 
> local kernel knows nothing about locks set by other machines: you 
> need to let the filesystem handle it.

Advertised locks are already implemented inside the file systems and
we have VOP_ADVLOCK() with “op == F_GETLK”. What else is needed to
make the decision here?

>> Could you explain the proposed semantics in detail?
> 
> We have this:
> https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt

I strongly object against an implementation whose specification starts:

  0. Why you should avoid mandatory locking
  -----------------------------------------

  The Linux implementation is prey to a number of difficult-to-fix race
  conditions which in practice make it not dependable:

  - The write system call checks for a mandatory lock only once
    at its start.  It is therefore possible for a lock request to
    be granted after this check but before the data is modified.
    A process may then see file data change even while a mandatory
    lock was held.
  - Similarly, an exclusive lock may be granted on a file after
    the kernel has decided to proceed with a read, but before the
    read has actually completed, and the reading process may see
    the file data in a state which should not have been visible
    to it.
  - Similar races make the claimed mutual exclusion between lock
    and mmap similarly unreliable.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)