riscv64: the large-file fcntl lock commands are the plain ones
fcntl (fd, F_SETLKW, &fl) returned EINVAL on riscv64 whenever the caller was
built with _FILE_OFFSET_BITS=64, which is what UCLIBC_HAS_LFS gives every
program by default.
bits/fcntl.h maps F_GETLK/F_SETLK/F_SETLKW onto the *64 variants in that mode
and defined those as 12/13/14. Those numbers are the 32-bit compatibility
commands: fs/fcntl.c handles them under "#if BITS_PER_LONG == 32" only, so on
a 64-bit kernel they fall through to the default case and come back as EINVAL.
The riscv64 header was copied from the 32-bit one, where 12/13/14 are right.
aarch64 and x86_64 alias them to 5/6/7, alpha to its own F_GETLK -- riscv64
was the odd one out.
Six tests failed on riscv64 with NPTL against 4.19.56 headers: tst-flock2 said
"first fcntl failed" outright, and tst-cancel7 said "pthread_cancel failed",
which was a consequence -- its thread dies on the same fcntl before the
cancellation, so pthread_cancel then reports ESRCH.
Verified under qemu-system-riscv64: tst-flock2, tst-cancel7, tst-cancelx7 and
their -O2 twins pass.
riscv32 keeps its copy unchanged; there the 32-bit numbering is correct.
Signed-off-by: Ramin Moussavi <lordrasmus@gmail.com>
ramin