On Sun, 27 Apr 2014 17:35:52 +0200 "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> wrote: > Hello all, > > For a long time now, the fcntl(2) man page has carried this text > regarding mandatory (byte-range) locking: > > > Mandatory locking > The implementation of mandatory locking in all known versions > of Linux is subject to race conditions which render it unreli‐ > able: a write(2) call that overlaps with a lock may modify data > after the mandatory lock is acquired; a read(2) call that over‐ > laps with a lock may detect changes to data that were made only > after a write lock was acquired. Similar races exist between > mandatory locks and mmap(2). It is therefore inadvisable to > rely on mandatory locking. > > I wanted to check: does it remain true with modern kernels that mandatory > locking is unreliable? If things have changed, an uopdate to the man page > is obviously in order. > > Cheers, > > Michael > > Yes, it's still unreliable in modern kernels for the same reasons. The basic problem is that another task can race in and grab a lock after you check for it but before you do the I/O. FWIW, this probably fixable if someone is motivated enough to do so. You could have reads and writes set an implicit lock on the file that isn't merged with existing locks. Doing that with mmap might be "interesting" though. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
