From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9826 Path: news.gmane.org!not-for-mail From: Sebastian Gottschall Newsgroups: gmane.linux.lib.musl.general Subject: Re: recvmsg/sendmsg broken on mips64 Date: Sat, 2 Apr 2016 11:52:32 +0200 Message-ID: <4445e7a7-19f3-aa7c-04dc-3e329ef7fdac@dd-wrt.com> References: <20160331201012.GR9862@port70.net> <20160331203004.GX21636@brightrain.aerifal.cx> <76c20e67-4d62-a929-9f1d-a3fc63758426@dd-wrt.com> <20160401094919.GT9862@port70.net> <02844173-9671-d0e9-a291-764b27899f44@dd-wrt.com> <20160401113146.GU9862@port70.net> <91bfe81c-73c4-9b25-6d9b-a97d4ee54e89@dd-wrt.com> <20160401131712.GV9862@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1459590717 28891 80.91.229.3 (2 Apr 2016 09:51:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Apr 2016 09:51:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9839-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 02 11:51:54 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1amIDg-0002ww-Ro for gllmg-musl@m.gmane.org; Sat, 02 Apr 2016 11:51:52 +0200 Original-Received: (qmail 23680 invoked by uid 550); 2 Apr 2016 09:51:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23659 invoked from network); 2 Apr 2016 09:51:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dd-wrt.com; s=mikd; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To; bh=gS1hCRbd2e59mhsT9325EMIZ+Br1rXUN4qVWFYIn5WY=; b=dx4XFstTp+blDHHOAt2TjJhNVKbduTSm25QTJRVe1pI7oaV/MkytmwheKKF6E48eMms4ZP7EwdWkQgg630s+bIvrpQTdJqqOYPvDQxTe56MW/fyji13PKla4M34F3bqNYw+vtZp5oLJxXuooOEw6nkTAi3S+eA0oew4ZiyQar2E=; User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160401131712.GV9862@port70.net> X-SA-Exim-Connect-IP: 217.234.153.139 X-SA-Exim-Mail-From: s.gottschall@dd-wrt.com X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on webmail.newmedia-net.de X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=ALL_TRUSTED,BAYES_00, DNS_FROM_AHBL_RHSBL,RATWARE_GECKO_BUILD autolearn=no version=3.1.9, No X-SA-Exim-Version: 4.2.1 (built Thu, 26 May 2011 15:22:33 +0200) X-SA-Exim-Scanned: Yes (on webmail.newmedia-net.de) X-NMN-MailScanner-Information: Please contact the ISP for more information X-NMN-MailScanner-ID: 1amIDO-0004JT-Lc X-NMN-MailScanner: Found to be clean X-NMN-MailScanner-From: s.gottschall@dd-wrt.com X-Received: from [217.234.153.139] (helo=[10.88.193.128]) by webmail.newmedia-net.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1amIDO-0004JT-Lc for musl@lists.openwall.com; Sat, 02 Apr 2016 11:51:34 +0200 Xref: news.gmane.org gmane.linux.lib.musl.general:9826 Archived-At: Am 01.04.2016 um 15:17 schrieb Szabolcs Nagy: > * Sebastian Gottschall [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 >