[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4445e7a7-19f3-aa7c-04dc-3e329ef7fdac@dd-wrt.com>
Date: Sat, 2 Apr 2016 11:52:32 +0200
From: Sebastian Gottschall <s.gottschall@...wrt.com>
To: musl@...ts.openwall.com
Subject: Re: recvmsg/sendmsg broken on mips64
Am 01.04.2016 um 15:17 schrieb Szabolcs Nagy:
> * Sebastian Gottschall <s.gottschall@...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
>
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.
