On 04/28/2014 12:07 PM, Jeff Layton wrote: > 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. Thanks for the confirmation, Jeff. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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
