Bug 444552

Summary:	memcheck/tests/sem fails on s390x with glibc 2.34
Product:	[Developer tools] valgrind	Reporter:	Mark Wielaard <mark>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	RESOLVED FIXED
Severity:	normal	CC:	arnez, fweimer, sam
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Fix sys_ipc semtimedop for s390x

Description Mark Wielaard 2021-10-28 17:19:09 UTC

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)

Comment 1 Mark Wielaard 2021-10-29 07:32:07 UTC

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?

Comment 2 Andreas Arnez 2022-02-08 16:48:16 UTC

(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?

Comment 3 Andreas Arnez 2022-02-08 16:51:24 UTC

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.

Comment 4 Mark Wielaard 2022-02-09 23:45:46 UTC

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.

Comment 5 Florian Weimer 2022-02-10 09:33:23 UTC

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.

Comment 6 Andreas Arnez 2022-02-18 19:38:51 UTC

Pushed as commit 03a8b24ae362f13c7f97746f72f40240aeb5aade.