fcntl(F_SETLK) for setting byte range locks is broken leading to data corruption

[ned14]

My WSL is the Creator's Update 1703. uname -r reports 4.4.0-43-Microsoft

I'm seeing fcntl(F_SETLK) permit multiple exclusive locks on WSL which is bad, it's instant data corruption for anything relying on this to work. This test launches four child processes and uses a shared memory map to check if fcntl(F_SETLK) is working correctly. This test passes on real Linux, fails badly on WSL:

integration/afio/shared_fs_mutex_byte_ranges/exclusives:
Tests that afio::algorithm::shared_fs_mutex::byte_ranges implementation implements exclusive locking
CHECK ((i.results[0] == 'o' && i.results[1] == 'k')) FAILED at /home/ned/windocs/boostish/afio/test/tests/shared_fs_mutex.cpp:283
Child reports Child 0 released exclusive lock to find child 3 had stolen my lock!
CHECK ((i.results[0] == 'o' && i.results[1] == 'k')) FAILED at /home/ned/windocs/boostish/afio/test/tests/shared_fs_mutex.cpp:283
Child reports Child 1 granted exclusive lock when child 2 already has exclusive lock!
CHECK ((i.results[0] == 'o' && i.results[1] == 'k')) FAILED at /home/ned/windocs/boostish/afio/test/tests/shared_fs_mutex.cpp:283
Child reports Child 2 released exclusive lock to find child 1 had stolen my lock!
CHECK ((i.results[0] == 'o' && i.results[1] == 'k')) FAILED at /home/ned/windocs/boostish/afio/test/tests/shared_fs_mutex.cpp:283
Child reports Child 3 granted exclusive lock when child 0 already has exclusive lock!
4 checks passed  4 checks failed  duration 5150 ms

While you're at it, if you could implement the non-insane fcntl(F_OFD_SETLK) locks that would be very useful. The fcntl(F_SETLK) type locks are stupid.

[therealkenc]

Same as #1712 (message), FWIW.

[ned14]

The issue referenced looks like lock files, not byte range locks. Another test in my test suite tests lock files and it passes on WSL. Still, the issues could be related.

It should be trivially easy to convert the new ORD locks to LockFileEx. The older POSIX locks would require a little more work to emulate the broken semantics required by POSIX. In any case they should return ENOTSUPP or something so implementations can choose a backup locking system like lock files.

[0xabu]

FWIW, recent builds of QEMU require F_OFD_SETLK / F_OFD_GETLK for disk image files. It would be nice to have them implemented.

[trawick]

I see this fcntl(F_SETLK) issue with libapr's apr_file_lock() API. A child process is able to run this sequence successfully while the parent holds the lock.

[pid   702] open("data/testfile.lock", O_WRONLY|O_CLOEXEC) = 3
[pid   702] fcntl(3, F_GETFD)           = 0x1 (flags FD_CLOEXEC)
[pid   702] fcntl(3, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0

[apenwarr]

A simple test case for fcntl-style file locking semantics can be found in "locky.c" linked from this blog post: https://apenwarr.ca/log/20101213

[rgal]

Still seeing this on Version 1803 (4.4.0-17134-Microsoft).

Are there plans to fix this?