[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2656e404-f225-cd95-3989-a48df486d914@dd-wrt.com>
Date: Fri, 8 Apr 2016 01:33:51 +0200
From: Sebastian Gottschall <s.gottschall@...wrt.com>
To: musl@...ts.openwall.com
Subject: Re: recvmsg/sendmsg broken on mips64
Am 07.04.2016 um 20:46 schrieb Szabolcs Nagy:
> * Sebastian Gottschall <s.gottschall@...wrt.com> [2016-04-07 13:42:17 +0200]:
>>> ok so the failure is in sendmsg and in the msg_control copy.
>>>
>>> does the call fail with ENOMEM (because >1024 bytes of ancillary data)?
>>> that would be easy to fix..
>>>
>>> (libc has to make a copy, the struct is const and might be in
>>> readonly memory. a detailed bug report of the failure would
>>> be more useful than speculations about broken compilers..
>>> e.g. strace log with and without the msg_control copying.)
>> how to make a more detailed report than just that all netlink operations in
>> iproute2 fail. so the whole ip command doesnt work.
> there are only two places where msg->msg_control
> is used in iproute2: bpf_scm.h and libnetlink.c,
> they both use a fixed char[1024] buffer, which
> should work with musl.
>
> one thing i noticed is that iproute2 fails to
> take cmsghdr alignment requirements into account,
> so it only works by accident.
>
> i think the musl struct has different alignment
> (4 byte instead of 8 byte) which may cause problems
> because the copy uses the musl alignment, i'm
> not sure if this can cause what you observed.
>
> so we still don't know what your problem was
> and what fails exactly.
easy again. iproute2 doesnt work on mips64 targets since recvmsg /
sendmsg call does fail, caused by a wrong structure alignment, bad
structure at all or bad musl code at all.
its all resulting in the same failing recvmsg / sendmsg call.. so yes
libnetlink.c does not work with musl on mips64 (it does work on x64 and
everything else, just not mips64) unless the hack i offered was applied
which again fixed all.
before you ask again for a problem description, just read again. it wont
change the description if you ask again and just makes people tired on
this list.
since the problem is related to the fieldsize of several length
parameters, i also dont believe it has something todo with structure
alignments, since i also did not change them in my pseudo fix.
i just matched the fieldsizes to the api used by the kernel, so that the
kernel syscall does receive the same structure as expected, even if that
missmatches the posix api
for sure a size change in fieldsized again may change alignment
boundaries. but then again iproute2 would be the problem cause which
works for 15 years now with all libc implementations.
if you really want to keep posix compliance. then provide a external
structure for usage and convert them to a second internal structure
which matches the linux api, this does remove all that padding stuff
and looks cleaner at the end. and it will also reduce codesize. so you
can also fix possible alignment issues
>
>> i tracked it down to recvmsg / sendmsg which do not return in success for
>> some reason. if i send it more detailed, which means i debug out
>> the real cause would also mean submit a better patch. just had no time yet
>> to care about since my hack works.
>>
>> but does not fit to your philosophy. its easy to reproduce on any octeon
>> device using musl and iproute2.
>>
>>>> #if LONG_MAX > INT_MAX
>>>> struct msghdr h;
>>>> struct cmsghdr chbuf[1024/sizeof(struct cmsghdr)+1], *c;
>>>> if (msg) {
>>>> h = *msg;
>>>> h.__pad1 = h.__pad2 = 0;
>>>> msg = &h;
>>>> if (h.msg_controllen) {
>>>> if (h.msg_controllen > 1024) {
>>>> errno = ENOMEM;
>>>> return -1;
>>>> }
>>>> memcpy(chbuf, h.msg_control, h.msg_controllen);
>>>> h.msg_control = chbuf;
>>>> for (c=CMSG_FIRSTHDR(&h); c; c=CMSG_NXTHDR(&h,c))
>>>> c->__pad1 = 0;
>>>> }
>>>> }
>>>> #endif
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
