mailing list of musl libc
 help / color / mirror / code / Atom feed
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


  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).