Status of fcntl() mandatory locking

Status of fcntl() mandatory locking

[Michael Kerrisk (man-pages)]

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


-- 
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

Re: Status of fcntl() mandatory locking

[Jeff Layton]

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.

-- 
Jeff Layton <jlayton@redhat.com>
--
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

Re: Status of fcntl() mandatory locking

[Michael Kerrisk (man-pages)]

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