Re: Status of fcntl() mandatory locking

["Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>]

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@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html