This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 2015/3/18 4:29, Rich Felker wrote:
> On Tue, Mar 17, 2015 at 07:07:47PM +0100, Szabolcs Nagy wrote:
>> * Cyril Hrubis <> [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:
>So there is no way to pretend the requirement doesn't exist like
>glibc/x32 is doing now for timespec. This needs a fix.
I send a fix to kernel mailing list several days ago[1]. The basic idea
is that msgsnd/msgrcv should be wrapped to compat syscall in kernel:
#define sys_msgrcv              compat_sys_msgrcv
#define sys_msgsnd              compat_sys_msgsnd

This action could fix the compatability issue. And It will not affect
other syscalls.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]