From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9862 Path: news.gmane.org!not-for-mail From: Sebastian Gottschall Newsgroups: gmane.linux.lib.musl.general Subject: Re: recvmsg/sendmsg broken on mips64 Date: Fri, 8 Apr 2016 01:33:51 +0200 Message-ID: <2656e404-f225-cd95-3989-a48df486d914@dd-wrt.com> References: <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> <4445e7a7-19f3-aa7c-04dc-3e329ef7fdac@dd-wrt.com> <20160407094806.GE9862@port70.net> <20160407184643.GI9862@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1460078611 12803 80.91.229.3 (8 Apr 2016 01:23:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 01:23:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9875-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 08 03:23:30 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 1aoL90-0002BB-6Z for gllmg-musl@m.gmane.org; Fri, 08 Apr 2016 03:23:30 +0200 Original-Received: (qmail 13369 invoked by uid 550); 7 Apr 2016 23:34:05 -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 13348 invoked from network); 7 Apr 2016 23:34:05 -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=poUYweUG6I6R6gCuUwMh5ubWaP3yZBvF9XBNfHMizmI=; b=Rm8dlI3ebQfJPn6ff/UnKSq2xZrcI56QL7kAA7DRD4TU1grhmrkfnl+Jc9LFrB+uFKyStnru0N+dNcDnl3DjME5W7szoXrdVWNFbz/Qwm39kZnZWDTPNk/Lm0//x5gE1Wmhqv8ibv0qVU2Ogzb9HeEJ+I7g07c4lU+msKlsCOUs=; User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160407184643.GI9862@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: 1aoJQn-0002Nw-SH 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 1aoJQn-0002Nw-SH for musl@lists.openwall.com; Fri, 08 Apr 2016 01:33:47 +0200 Xref: news.gmane.org gmane.linux.lib.musl.general:9862 Archived-At: Am 07.04.2016 um 20:46 schrieb Szabolcs Nagy: > * Sebastian Gottschall [2016-04-07 13:42:17 +0200]: >>> 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.) >> how to make a more detailed report than just that all netlink operations in >> iproute2 fail. so the whole ip command doesnt work. > there are only two places where msg->msg_control > is used in iproute2: bpf_scm.h and libnetlink.c, > they both use a fixed char[1024] buffer, which > should work with musl. > > one thing i noticed is that iproute2 fails to > take cmsghdr alignment requirements into account, > so it only works by accident. > > i think the musl struct has different alignment > (4 byte instead of 8 byte) which may cause problems > because the copy uses the musl alignment, i'm > not sure if this can cause what you observed. > > so we still don't know what your problem was > and what fails exactly. easy again. iproute2 doesnt work on mips64 targets since recvmsg / sendmsg call does fail, caused by a wrong structure alignment, bad structure at all or bad musl code at all. its all resulting in the same failing recvmsg / sendmsg call.. so yes libnetlink.c does not work with musl on mips64 (it does work on x64 and everything else, just not mips64) unless the hack i offered was applied which again fixed all. before you ask again for a problem description, just read again. it wont change the description if you ask again and just makes people tired on this list. since the problem is related to the fieldsize of several length parameters, i also dont believe it has something todo with structure alignments, since i also did not change them in my pseudo fix. i just matched the fieldsizes to the api used by the kernel, so that the kernel syscall does receive the same structure as expected, even if that missmatches the posix api for sure a size change in fieldsized again may change alignment boundaries. but then again iproute2 would be the problem cause which works for 15 years now with all libc implementations. if you really want to keep posix compliance. then provide a external structure for usage and convert them to a second internal structure which matches the linux api, this does remove all that padding stuff and looks cleaner at the end. and it will also reduce codesize. so you can also fix possible alignment issues > >> i tracked it down to recvmsg / sendmsg which do not return in success for >> some reason. if i send it more detailed, which means i debug out >> the real cause would also mean submit a better patch. just had no time yet >> to care about since my hack works. >> >> but does not fit to your philosophy. its easy to reproduce on any octeon >> device using musl and iproute2. >> >>>> #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