From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: recvmsg/sendmsg broken on mips64
Date: Thu, 7 Apr 2016 11:48:06 +0200 [thread overview]
Message-ID: <20160407094806.GE9862@port70.net> (raw)
In-Reply-To: <4445e7a7-19f3-aa7c-04dc-3e329ef7fdac@dd-wrt.com>
* Sebastian Gottschall <s.gottschall@dd-wrt.com> [2016-04-02 11:52:32 +0200]:
> 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.
"original structures" does not make sense.
the next glibc will fix their bug and use exactly the same struct as musl:
http://sourceware.org/ml/libc-alpha/2016-03/msg00661.html
eventually uclibc will fix this too (assuming it's still maintained)
(and hopefully at some point the kernel will introduce new syscalls
that use the correct structs.)
> 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?
>
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.)
> #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
next prev parent reply other threads:[~2016-04-07 9:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 18:20 size_t and int64_t on a new platform Dan Gohman
2016-03-31 19:25 ` Rich Felker
2016-03-31 20:10 ` Szabolcs Nagy
2016-03-31 20:23 ` Alexander Monakov
2016-03-31 20:30 ` Rich Felker
2016-04-01 9:16 ` recvmsg/sendmsg broken on mips64 Sebastian Gottschall
2016-04-01 9:49 ` Szabolcs Nagy
2016-04-01 10:29 ` Sebastian Gottschall
2016-04-01 11:31 ` Szabolcs Nagy
2016-04-01 11:37 ` Sebastian Gottschall
2016-04-01 12:21 ` Masanori Ogino
2016-04-01 12:42 ` Sebastian Gottschall
2016-04-01 13:17 ` Szabolcs Nagy
2016-04-02 9:52 ` Sebastian Gottschall
2016-04-07 9:48 ` Szabolcs Nagy [this message]
2016-04-07 11:42 ` Sebastian Gottschall
2016-04-07 18:46 ` Szabolcs Nagy
2016-04-07 23:33 ` Sebastian Gottschall
2016-04-10 22:18 ` Rich Felker
2016-04-10 22:24 ` Sebastian Gottschall
2016-04-10 22:29 ` Rich Felker
2016-04-10 22:33 ` Sebastian Gottschall
2016-04-11 2:35 ` Rich Felker
2016-04-11 6:35 ` Sebastian Gottschall
2016-04-11 18:32 ` Rich Felker
2016-04-11 19:01 ` Sebastian Gottschall
2016-04-14 14:10 ` Sebastian Gottschall
2016-04-15 16:19 ` Rich Felker
2016-04-21 1:37 ` Rich Felker
2016-04-21 7:22 ` Sebastian Gottschall
2016-04-21 15:36 ` Rich Felker
2016-04-21 17:16 ` Rich Felker
2016-04-21 19:30 ` Sebastian Gottschall
2016-04-21 19:29 ` Sebastian Gottschall
2016-04-01 0:35 ` size_t and int64_t on a new platform Dan Gohman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160407094806.GE9862@port70.net \
--to=nsz@port70.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).