Passes on Fedora 34 with glibc 2.33, Fails with glibc 2.34: --- sem.stderr.exp 2021-10-28 11:43:42.259542045 -0400 +++ sem.stderr.out 2021-10-28 11:55:09.629589684 -0400 @@ -1,4 +1,28 @@ +Syscall param semtimedop(timeout) points to unaddressable byte(s) + at 0x........: semtimedop_syscall (semtimedop.c:33) + by 0x........: semtimedop (semtimedop.c:44) + by 0x........: main (sem.c:83) + Address 0x........ is not stack'd, malloc'd or (recently) free'd + +Syscall param semtimedop(timeout) points to unaddressable byte(s) + at 0x........: semtimedop_syscall (semtimedop.c:33) + by 0x........: semtimedop (semtimedop.c:44) + by 0x........: main (sem.c:115) + Address 0x........ is not stack'd, malloc'd or (recently) free'd + +Syscall param semtimedop(timeout) points to unaddressable byte(s) + at 0x........: semtimedop_syscall (semtimedop.c:33) + by 0x........: semtimedop (semtimedop.c:44) + by 0x........: main (sem.c:127) + Address 0x........ is not stack'd, malloc'd or (recently) free'd + +Syscall param semtimedop(timeout) points to unaddressable byte(s) + at 0x........: semtimedop_syscall (semtimedop.c:33) + by 0x........: semtimedop (semtimedop.c:44) + by 0x........: main (sem.c:142) + Address 0x........ is not stack'd, malloc'd or (recently) free'd with --trace-syscals=yes (first two calls) on f34: SYSCALL[252703,1](91) sys_munmap ( 0x4850000, 25612 )[sync] --> Success(0x0) SYSCALL[252703,1](117) sys_ipc ( 2, 0, 1, 384, 0x0, 137422175904 )[sync] --> Success(0xb) SYSCALL[252703,1](117) sys_ipc ( 4, 11, 1, 0, 0x1ffefffc86, 137422175904 ) --> [async] ... SYSCALL[252703,1](117) ... [async] --> Success(0x0) on f35: SYSCALL[37012,1](91) sys_munmap ( 0x484b000, 27527 )[sync] --> Success(0x0) SYSCALL[37012,1](117) sys_ipc ( 2, 0, 1, 384, 0x0, 1 )[sync] --> Success(0xe) SYSCALL[37012,1](117) sys_ipc ( 4, 14, 1, 0, 0x1ffefffb6e, 1 )==37012== Syscall param semtimedop(timeout) points to unaddressable byte(s) ==37012== at 0x496D296: semtimedop_syscall (semtimedop.c:33) ==37012== by 0x496D296: semtimedop (semtimedop.c:44) ==37012== by 0x1000C67: main (sem.c:83) ==37012== Address 0x1 is not stack'd, malloc'd or (recently) free'd ==37012== --> [async] ... SYSCALL[37012,1](117) ... [async] --> Success(0x0)
Note the following in glibc sysdeps/unix/sysv/linux/s390/ipc_priv.h: /* The s390 sys_ipc variant has only five parameters instead of six (as for default variant). The difference is the handling of SEMTIMEDOP where on s390 the third parameter is used as a pointer to a struct timespec where the generic variant uses fifth parameter. */ #undef SEMTIMEDOP_IPC_ARGS #define SEMTIMEDOP_IPC_ARGS(__nsops, __sops, __timeout) \ (__nsops), (__timeout), (__sops) So maybe we are hitting that? But why only with glibc 2.34?
(In reply to Mark Wielaard from comment #1) > Note the following in glibc sysdeps/unix/sysv/linux/s390/ipc_priv.h: > [...] > So maybe we are hitting that? But why only with glibc 2.34? You're right that this is different on s390x. And since the difference is not handled in Valgrind, this can't work correctly, and probably never has. But as far as I know, the glibc doesn't normally exploit the sys_ipc variant, but uses the semtimedop syscall instead, if available. It is a bit curious why this would change in a newer glibc. Is there perhaps something wrong with the glibc configuration?
Created attachment 146450 [details] Fix sys_ipc semtimedop for s390x Apart from a potential glibc configuration problem, Valgrind should be fixed as well. So this is a possible fix for the bad invocation of the sys_ipc semtimedop call on s390x platforms.
The patch looks good and I tested it on f34 (glibc-2.33-20.fc34.s390x) an f35 (glibc-2.34-25.fc35.s390x) perl tests/vg_regtest memcheck/tests/sem.vgtest succeeds before and after the patch with glibc 2.33 it fails before and succeeds after the patch with glibc 2.34 I don't know why on glibc 2.34 it looks like semtimedop goes through the ipc syscall multiplexer. I added Florian to the CC who might know if this was a deliberate change in glibc.
I think for several releases, glibc used the semtimedop system call by mistake: it was only added to the kernel in Linux 5.1, so this led to compatibility problems.
Pushed as commit 03a8b24ae362f13c7f97746f72f40240aeb5aade.