Re: recvmsg/sendmsg broken on mips64

[Sebastian Gottschall <s.gottschall@dd-wrt.com>]

Am 01.04.2016 um 15:17 schrieb Szabolcs Nagy:
> * Sebastian Gottschall <s.gottschall@dd-wrt.com> [2016-04-01 14:42:36 +0200]:
>> it only affects mips64 so far. not x64. i checked both using dd-wrt
> the types *must* be the same on the source level
> on *all* targets as specified by posix, the linux
> syscall abi is irrelevant, that is not visible
> to userspace code which is written for the c
> language level api, if you change the types
> it is not possible to write portable c code.
i understand the reason why the datatypes are defined as is, but on the 
other hand the argument is irrelevant
if it doesnt work portable or not. (for some reason which might be mips 
specific)
but anyway. i dont want to discuss this to the deep and. i prefer to 
find and fix the bug by keeping the original structures.
i will do some debugging on this today

>
> your fix does not explain that unless there is
> a >4G message somewhere which i think is not
> supported on the kernel side either.
>
> please send a proper bug report about what
> breaks, it sounds like the padding is at
> the wrong place. changing int,int to size_t
> should make no difference for iproute2.
it not just padding if you look at confusing codelines like this in sendmsg
for me it look like someone creates a copy of the buffer to work with 
it. but i dont see a reason for it and is does also limit the maximum 
size of a message
and code like this h = *msg; should be replaced by memcpy, since the 
compiler may optimize that in a bad way . i have seen compiler 
introduced bugs
in the past on lines like that. for me that code should be removed. 
clearing padding is one thing, but why doing a copy?

#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

>
>> same way since it uses the same struct
>> my dirty musl hack again fixed it by using the same datatypes used in the
>> kernel. so this might be mips specific.
>> currently musl does convert the non conform kernel structures to posix
>> specified structures, but this doesnt seem to work for mips64
> we should figure out why it does not work
> instead of breaking portability.
okay
>