From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9861 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: recvmsg/sendmsg broken on mips64 Date: Thu, 7 Apr 2016 20:46:43 +0200 Message-ID: <20160407184643.GI9862@port70.net> 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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1460054821 30918 80.91.229.3 (7 Apr 2016 18:47:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Apr 2016 18:47:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9874-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 07 20:47:01 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 1aoExH-0004p3-Q2 for gllmg-musl@m.gmane.org; Thu, 07 Apr 2016 20:46:59 +0200 Original-Received: (qmail 11443 invoked by uid 550); 7 Apr 2016 18:46:56 -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 11425 invoked from network); 7 Apr 2016 18:46:55 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9861 Archived-At: * 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. > 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 >