Re: struct msgbuf wrong mtype size on ILP32 and possibly x32

[Rich Felker <dalias at libc dot org>]

On Tue, Mar 17, 2015 at 07:07:47PM +0100, Szabolcs Nagy wrote:
> * Cyril Hrubis <chrubis@suse.cz> [2015-03-17 16:57:50 +0100]:
> > I've got a bugreport for LTP that msgrcv and msgsnd are hanging forever
> > on -mabi=ilp32 (and possibly on x32).
> > 
> > The issue seems to be that sizeof(long) != sizeof(__syscall_slong_t) on
> > these (which is used to define mtype in glibc headers and likely the
> > size used in kernel) which is probably the reason for the test hang.
> > 
> > The proposed solution for fixing LTP is to replace the long in the
> > custom defined msgbuf structures with __syscall_slong_t which is
> > obviously wrong. Not only it uses glibc internal type but also breaks
> > backward compatibilty.
> > 
> > I'm pretty sure that this needs to be fixed somewhere in glibc/kernel
> > because the mtype being long is part of the ABI. Or at least man page
> > and numerous tutorials on net suggets so.
> > 
> 
> this is just another case where the kernel x32 abi
> (and thus glibc) fails to follow the standard/man
> 
> just like with timespec, timex and sysinfo structs
> 
> the userspace api should use long and not __syscall_slong_t

This kind of thing is going to keep happening -- having
__syscall_slong_t or similar spill into userspace at all was a huge
mistake. If there are going to be ILP32 models on archs where the
kernel is LP64, they need to have separate working ILP32 interfaces
that treat long consistently as 32-bit.

BTW in this particular case, the public API actually requires the
application to define its own structure using long:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/msgrcv.html

So there is no way to pretend the requirement doesn't exist like
glibc/x32 is doing now for timespec. This needs a fix.

Rich