with no size/direction hints. (DVD_READ_STRUCT)
Patch from Austin English (austinenglish@gmail.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16153
with no size/direction hints. (CDROMSTOP).
Patch from Austin English (austinenglish@gmail.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16152
Note that it is unclear if the PRE syscall for rt_sigsuspend
is properly setting up a temporary mask in the thread state
tmp_sig_mask: if an handler is called while a thread is
calling sigsuspend, the mask during the handler run must be
the temporary mask set by sigsuspend.
It is not clear if/where the valgrind sigframe builder/handler
sets the tmp_sig_mask to the value as expected by the user
(i.e. the value of the temporary mask which was given to
the sigsuspend syscall)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16141
Since we try to modify the old/new sigaction handler before passing it
to the kernel we must make sure that (if they aren't NULL) it is safe
to use. If not we should bail out early with EFAULT.
Bug #369362
Found by LTP testcases/kernel/syscalls/rt_sigaction/rt_sigaction02.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15994
Since we want to use the set and oldset for bookkeeping we also want
to make sure they are addressable otherwise, like the kernel, we EFAULT.
Also use EINVAL instead of EMFILE as failure when sigset size is wrong.
Found by LTP testcases/kernel/syscalls/rt_sigprocmask/rt_sigprocmask02.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15992
Don't check or try to copy sigmask if it is NULL. The sigmask might be
given in a struct, where the length is non-zero, but the signal set
pointer is NULL.
Testcase provided by Paul Eggert <eggert@cs.ucla.edu>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15893
The new memcheck/tests/arm64-linux/scalar test is based on the
memcheck/tests/x86-linux/scalar test and contains all syscalls
that are also available on arm64. To make comparison of exp results
easier the order of the tested syscalls is the same as on x86.
This enables a couple extra arm64 syscalls. Part of the fix for
bug #359503 - Add missing syscalls for aarch64 (arm64).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15825
The original fix in svn r15793 read argument 6 separately by using PRA6
unconditionally. This is wrong. We need to first check whether a
track_pre_reg_read callback is registered (only memcheck does).
The PRE_REG_READX macro already had this check. Just add the same
before calling PRA6. Thanks to Tom Hughes for noticing. Without this
helgrind/tests/cond_timedwait_test and drd/tests/pth_inconsistent_cond_wait
regtests would fail.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15795
Comparing the command byte with VKI_I2C_SMBUS_QUICK is like comparing
apples to carrots, it makes no sense. The command byte is unused for
quick transactions anyway so checking its value is pointless.
Patch by Jean Delvare <jdelvare@suse.de>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15656
The first byte of the data array holds the length, so the actual data
length is the value of that byte plus one.
Patch by Jean Delvare <jdelvare@suse.de>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15655
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
Some architectures, e.g. s390, don't have dedicated recvmmsg and sendmmsg
system calls, but use the socketcall multiplexing system call with
SYS_RECVMMSG or SYS_SENDMMSG (just like the accept4 systemcall can also
be called through socketcall). Create separate helpers for recvmmsg and
sendmmsg helpers that can be used by either the direct syscall or the
socket call.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14964
only to check the lowest 32 bits, since that arg is a file descriptor
-- hence "int" -- and checking all 64 bits fails unexpectedly if ARG1
and VKI_AT_FDCWD are not both zero- or sign- extended.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14689
Bug is not really fixed, instead the SHM_HUGETLB flag is ignored.
Note that it is not straightforward to properly fix this,
as this implies either to learn aspacemgr what huge pages are.
Also, the trick used in the fix for 333051 cannot be used easily,
because the SHM_HUGETLB flag is given in shmget, while the mmap
is done in shmat.
So, the easiest is to just ignore the SHM_HUGETLB flag.
SHM_HUGETLB is supposed to only give a performance impact.
Ignoring it should be benign.
Theoretically, the caller might expect a sucessful shmget(SHM_HUGETLB)+shmat
to give pages aligned on e.g. 1MB.
In this case, bad luck, the program will misbehave under valgrind.
To warn of this, a warning is given (once) when SHM_HUGETLB is seen.
The map_unmap.c test has been restructured somewaht to allow
TEST_SHM_HUGETLB to be tested independently (or not) of the TEST_MAP_HUGETLB.
Note also that by default, testing MAP_HUGETLB and SHM_HUGETLB
is disabled as usually, huge pages are not enabled.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14683
to issue a false complaint. Fixes BZ #339706
Source patch by David Herrmann (dh.herrmann@gmail.com).
Testcase by myself.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14646
