syscall() with SYS_posix_fallocate and simillar

Hi

Yesterday I was doing some testing of Valgrind on 16,0-CURRENT. There 
are a few new syscalls that I need to handle.

When I was testing I noticed another issue. We have one big test that 
uses syscall() for each system call number using bad arguments. This 
test failed for SYS_posix_fallocate.

The test does

     /* SYS_posix_fallocate        530 */
#if defined(VGP_amd64_freebsd) || defined(VGP_arm64_freebsd)
     GO(SYS_posix_fallocate, "3s 0m");
     SY(SYS_posix_fallocate, x0+99999, x0+10, x0+20); SUCC;
#else
     GO(SYS_posix_fallocate, "5s 0m");
     SY(SYS_posix_fallocate, x0+9999, x0, x0+10, x0, x0+20); SUCC;
#endif
     assert(res == EBADF);

x0 is an uninitizalised variable which we know contains 0. The GO macro 
just prints info about the test and the SY macro expands to "res = 
syscall(__ARGS__)". There are two macros, SUCC (asserts res != -1) and 
FAIL (asserts res == -1). In this case I'm abusing the SUCC macro for a 
case that is failing, I should replace that with a FAIL_POSIX(x) macro 
that asserts res == x.

Anyway, prior to 16 this worked OK both standalone and running in 
Valgrind. Now on 16 it runs OK standalone but on Valgrind the return 
value is -1 so that abused SUCC macro is firing the assert.

The Valgrind wrapper for posix_fallocate contains

    if (!ML_(fd_allowed)(ARG1, "posix_fallocate", tid, False))
       SET_STATUS_Failed(VKI_EBADF);


The ML_(fd_allowed) function does various checks on the file descriptor 
(for --track-fds validation and also to ensure that the value of the fd 
is not in the range that Valgrind reserves for its own use for logs and 
results files). In this case ML_(fd_allowed) is returning false.

That means

- the syscall doesn't proceed to the kernel

- the return value gets set to EBADF

- the carry flag gets set.


I think that setting the carry flag is wrong and I should be calling 
SET_STATUS_Success(VKI_EBADF) which just sets the return value.

What I don't understand is why this worked prior to 16.0-CURRENT. I 
don't think that syscall syscall() has changed.

Can anyone confirm that not setting the carry flag is the correct thing 
to do for syscalls like this?


A+

Paul