From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3031 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: A few issues on MIPS and now on ARMEL Date: Mon, 1 Apr 2013 13:55:22 -0400 Message-ID: <20130401175522.GN20323@brightrain.aerifal.cx> References: <20121115233725.GK20323@brightrain.aerifal.cx> <20121116001110.GL20323@brightrain.aerifal.cx> <20121116001831.GM20323@brightrain.aerifal.cx> 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 1364838937 10085 80.91.229.3 (1 Apr 2013 17:55:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Apr 2013 17:55:37 +0000 (UTC) Cc: Paul Schutte To: musl@lists.openwall.com Original-X-From: musl-return-3032-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 01 19:56:04 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UMixc-0003za-Hh for gllmg-musl@plane.gmane.org; Mon, 01 Apr 2013 19:56:00 +0200 Original-Received: (qmail 11310 invoked by uid 550); 1 Apr 2013 17:55:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11302 invoked from network); 1 Apr 2013 17:55:35 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3031 Archived-At: Hey Paul, I want to give you a heads-up: this issue is likely to regress in the next release of musl, AND in glibc, since Linux has recently added SO_REUSEPORT, which will now work on new kernels, but fail just like before on old kernels. I've sent an email to the maintainer of dnsmasq informing him of the issue so hopefully it will be fixed soon. I Cc'd the musl list so you should be able to see that email if you're subscribed or if you check the archives. Let me know if you have any questions. Rich On Fri, Nov 16, 2012 at 03:28:59AM +0200, Paul Schutte wrote: > Thanks Rich ! > > It is working. > > You guys are the best ! > > Don't know if anyone is interested, but this is the memory usage of the > glibc binary (dynamically linked, distro supplied) : > root 9931 0.4 0.4 4232 1020 pts/2 S+ 03:23 0:00 /dnsmasq > > Musl binary, statically linked: > root 9927 0.0 0.1 328 244 pts/2 S 03:20 0:00 ./dnsmasq > > RSS size down from 1020 to 244, thus 25% of original consumption. > > Regards > Paul > > On Fri, Nov 16, 2012 at 2:18 AM, Rich Felker wrote: > > > On Thu, Nov 15, 2012 at 07:11:10PM -0500, Rich Felker wrote: > > > On Thu, Nov 15, 2012 at 06:37:25PM -0500, Rich Felker wrote: > > > > On Fri, Nov 16, 2012 at 12:21:11AM +0200, Paul Schutte wrote: > > > > > Hi guys, > > > > > > > > > > I am now hitting a similar problem on armel. > > > > > > > > > > I am cross-compiling "dnsmasq" > > > > > > > > > > Glibc strace: > > > > > > > > > > ---snip--- > > > > > socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 5 > > > > > fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR) > > > > > fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 > > > > > setsockopt(5, SOL_IP, IP_MTU_DISCOVER, [0], 4) = 0 > > > > > setsockopt(5, SOL_IP, IP_PKTINFO, [1], 4) = 0 > > > > > setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 > > > > > setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 > > > > > > > > > > > > > > > Musl strace: > > > > > > > > > > socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 5 > > > > > fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR) > > > > > fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 > > > > > setsockopt(5, SOL_IP, IP_MTU_DISCOVER, [0], 4) = 0 > > > > > setsockopt(5, SOL_IP, IP_PKTINFO, [1], 4) = 0 > > > > > setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 > > > > > setsockopt(5, SOL_SOCKET, *0xf /* SO_??? */*, [1], 4) = -1 > > ENOPROTOOPT > > > > > (Protocol not available) > > > > > > > > Thanks for the report. I'll check and see if ARM has unusual > > > > definitions we're missing. > > > > > > This doesn't seem to be ARM-specific. Linux has reserved a number for > > > SO_REUSEPORT, but it's not implemented in the kernel it seems, and > > > musl is providing the value, presumably causing the app to use it and > > > think it works. I'm guessing I should just remove it, but it might be > > > possible/preferable to make setsockopt and getsockopt remap it to > > > SO_REUSEADDR internally. Ideas anyone? > > > > For now I've disabled it, matching what other libcs do on Linux. > > Changes are in current git. > > > > Rich > >