> On 28 Apr 2016, at 10:19, Emmanuel Dreyfus <m...@netbsd.org> 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 - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)