This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: struct msgbuf wrong mtype size on ILP32 and possibly x32
- From: Bamvor Jian Zhang <bamvor dot zhangjian at huawei dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Szabolcs Nagy <nsz at port70 dot net>, Cyril Hrubis <chrubis at suse dot cz>, <libc-alpha at sourceware dot org>, <kamil at semihalf dot com>, Bintian <bintian dot wang at huawei dot com>, Dingtianhong <dingtianhong at huawei dot com>, zhangjian <bamvor dot zhangjian at huawei dot com>
- Date: Wed, 18 Mar 2015 10:12:36 +0800
- Subject: Re: struct msgbuf wrong mtype size on ILP32 and possibly x32
- Authentication-results: sourceware.org; auth=none
- References: <20150317155750 dot GB28649 at rei dot suse dot de> <20150317180746 dot GB16260 at port70 dot net> <20150317202912 dot GA23507 at brightrain dot aerifal dot cx>
On 2015/3/18 4:29, Rich Felker wrote:
> 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
>
Hi,
>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
agree.
>
>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.
regards
bamvor
>
>Rich
[1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/399944