shmctl06 not portable to 32-bit powerpc + 64bit time

[andree182]

The test uses

	struct shmid64_ds buf_ds = {
		.shm_atime_high = 0x0A0A,
		.shm_dtime_high = 0x0A0A,
		.shm_ctime_high = 0x0A0A,
	};

from linux, but in case of powerpc, it's this: https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/shmbuf.h

However, shmctl() actually consumes shmid_ds, which comes from https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/bits/types/struct_shmid64_ds.h and subsequently https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/bits/types/struct_shmid64_ds_helper.h .

Notice the diff in shm_segsz . The ABI doesn't match and there's obviously offset in the returned variables. On powerpc, the test fails (but there's 0x0800 instead of 0x0A0A in my case).

[metan-ucw]

Looks like indeed glibc does translation between the kernel structure and the libc structure in sysdeps/unix/sysv/linux/shmctl.c.

Since this is a test about kernel not leaking any data the easiest solution would be to switch to raw syscall and call the shmctl as
tst_syscall(__NR_shmctl, ...) instead.

[metan-ucw]

I'm currently looking at LTP code and it is a bit more complicated. We use the libc version from sys/sem.h when available and then there are fallbacks defined for a different architectures in LTP lapi at include/lapi/shmbuf.h. And it looks like the fallback defintions may be wrong, i.e. the kernel structures. So I suppose that in the end the fallback definition should be fixed.

[metan-ucw]

And it's even more broken the configure check looks for shmid64_ds structure in nonexisting header sys/shmbuf.h but even if it's corrected to sys/shm.h it does not work because the glibc type is actually called struct __shmid64_ds which is internal glibc definition that shouldn't be used.

So I suppose that this needs to be simplified we should just remove the configure checks and define the structure with the glibc layout in the LTP lapi header. And we need the same for semid64_ds as well.