Re: Fixing the ELF priorities
On Tue, Jul 01, 2014 at 07:38:33PM +0100, Justin Cormack wrote: > FreeBSD recently ( > http://svnweb.freebsd.org/base?view=revision&revision=264269 ) added > elf header signature parsing to decide how to execute binaries (based > on the Linux binfmt_misc). The main use case is for qemu emulation, > but it could also apply to this type of issue. It is obviously a > bigger change, but could be worth considering. Being able to automatically invoke a suitable emulator for user binaries of the wrong OS and/or architecture would be very helpful for crossbuilding difficult packages. -- David A. Holland dholl...@netbsd.org
Re: Fixing the ELF priorities
On Tue, Jul 1, 2014 at 9:03 AM, Maxime Villard wrote: > Hi, > I would like to improve the priorities of the binary loader. When the kernel > loads a binary, it basically loops and calls different loaders (for aout, ELF, > ...). There are several ELF loaders, for native and emulated binaries. This > loop has a particular order: the 32bit compat loaders are called *before* > the native ones. Which means that when you launch a simple 64bit binary on a > 64bit system, the kernel first tries to load it through the netbsd32 and > linux32 > compat loaders. The priority is obviously wrong, the native loaders should be > called first; it also has a non-negligible performance impact when executing > many binaries (when compiling something, for example). FreeBSD recently ( http://svnweb.freebsd.org/base?view=revision&revision=264269 ) added elf header signature parsing to decide how to execute binaries (based on the Linux binfmt_misc). The main use case is for qemu emulation, but it could also apply to this type of issue. It is obviously a bigger change, but could be worth considering. Justin
Re: Obtaining list of created sockets
On Mon, Jun 30, 2014 at 09:39:37AM -0700, Will Dignazio wrote: > That would be an excellent start; I had considered it before, however I > thought that netstat only listed listening connections. With lsof, you > would only get sockets created with fsocket (those having file descriptors). > > I suppose combining the way the two get their information would yield a > majority of the sockets created, however I would like to get all internal > sockets that may not be listening yet, or never get a file descriptor. Some years back, I modified gre(4) to use an actual socket instead of rolling its own GRE or UDP packets. IIRC, I made gre(4) *always* create a file descriptor so that fstat(1) provided a comprehensive view of the sockets in the system. Having sockets in the system that appear neither in fstat(1) nor nor netstat(8) output seems like an unnecessary mystery/complication to me. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Fixing the ELF priorities
Hi, I would like to improve the priorities of the binary loader. When the kernel loads a binary, it basically loops and calls different loaders (for aout, ELF, ...). There are several ELF loaders, for native and emulated binaries. This loop has a particular order: the 32bit compat loaders are called *before* the native ones. Which means that when you launch a simple 64bit binary on a 64bit system, the kernel first tries to load it through the netbsd32 and linux32 compat loaders. The priority is obviously wrong, the native loaders should be called first; it also has a non-negligible performance impact when executing many binaries (when compiling something, for example). 32bit system: - exec_elf32 --> 32bit code and module, handles native binaries. 64bit system: - exec_elf64 --> 64bit code and module, handles native binaries. - exec_elf32 --> 32bit code and module. This module loads 32bit binaries properly, but they won't work in any case since it will then use the native 64bit environment. - netbsd32 --> this module loads 32bit binaries through the native 32bit code, but then uses its own 32bit syscalls. That's how a 32bit binary can work on a 64bit system. Let's consider this order: 1. exec_elf64 2. exec_elf32 3. netbsd32 That's how a 32bit binary will be processed: exec_elf64 will reject the binary, because it's not a 64bit one (ELF header). exec_elf32 will accept the binary, as it is a 32bit one, and will try to launch it, which of course will fail because it will use the native 64bit environment. So the binary will crash. netbsd32 is never reached. That's why netbsd32 is currently the first: it will use the 32bit code to load the binary (as well as exec_elf32 would), but it will then use its own 32bit environment. Now, a correct fix would be, on 64bit systems, to compile the 32bit code without setting up the exec_elf32 module. That way, on those systems, there's no more exec_elf32 module, which means that there's no module that will crash a binary before it actually reaches the intended compat layer, but there's still the 32bit code usable by netbsd32 and linux32. Then the order does not matter anymore, and we can give the native loader the highest priority. Attached are two patches (the former to disable the 32bit module, the latter to change the priorities). But I wonder if there wouldn't be a cleaner way to fix this. The problem with these patches is that exec_elf32 is a dependency of linux32: - linux32/common/linux32_mod.c - #if defined(EXEC_ELF32) # defineMD1 ",exec_elf32,compat_netbsd32" #else # defineMD1 "" #endif MODULE(MODULE_CLASS_EXEC, compat_linux32, "compat_linux" MD1); I think there's another issue with the dependency here: whether the exec_elf32 module is enabled or not does not matter, what matters is if the kernel is compiled with EXEC_ELF32. But as EXEC_ELF32 on 64bit systems will now disable exec_elf32, we have a problem. Beyond that, there's an inconsistency: if exec_elf32 is a dependency of linux32, then it should also be a dependency of netbsd32 (not the case currently). Do we just delete this dependency? This should really be fixed. I've made a small benchmark: on average, we save 30 seconds when doing "./build.sh kernel=GENERIC" with the attached fixes on amd64. -- 1 --- Index: exec_elf32.c === RCS file: /cvsroot/src/sys/kern/exec_elf32.c,v retrieving revision 1.140 diff -u -r1.140 exec_elf32.c --- exec_elf32.c7 Apr 2014 17:02:15 - 1.140 +++ exec_elf32.c8 Jun 2014 11:54:23 - @@ -34,10 +34,17 @@ #include __KERNEL_RCSID(0, "$NetBSD: exec_elf32.c,v 1.140 2014/04/07 17:02:15 rjs Exp $"); +/* Compile the 32bit code */ #defineELFSIZE 32 - #include "exec_elf.c" +#if ARCH_ELFSIZE != 64 +/* + * If we are on a 64bit system, we don't need the exec_elf32 module. However, + * we need the 32bit code to be compiled, because netbsd32 and linux32 will + * use it. + */ + #include #define ELF32_AUXSIZE (howmany(ELF_AUX_ENTRIES * sizeof(Aux32Info), \ @@ -101,3 +108,5 @@ return ENOTTY; } } + +#endif /* ARCH_ELFSIZE != 64 */ -- 2 --- Index: compat/linux32/common/linux32_mod.c === RCS file: /cvsroot/src/sys/compat/linux32/common/linux32_mod.c,v retrieving revision 1.5 diff -u -r1.5 linux32_mod.c --- compat/linux32/common/linux32_mod.c 7 Mar 2014 01:3
Re: pthread crashes on amd64-current
Date: Tue, 1 Jul 2014 10:14:22 +0300 From: Staffan =?iso-8859-1?Q?Thom=E9n?= Hi, I have a soekris net6501 and using a current amd64 kernel with either the 6.1.4 or daily from 2014-06-25 userland causes programs linked with libpthread to crash. i386 works perfectly. It looks awfully much like PR/47271 that was fixed in 2012. I had a look in lib/libpthread/pthread.c but it looks quite different from the patch in the PR... Is it just me doing it wrong or has there been a regression? The problem we diagnosed the symptom in PR 47271 to be a manifestation of should be fixed in 6.1.4 and is irrelevant in HEAD. Can you please submit a new PR with the symptoms you're observing and with stack traces from gdb, preferably with debug data?
Re: RFC: mpsafe bridge and NIC drivers (vioif and wm)
On Wed, Jun 11, 2014 at 5:20 PM, Ryota Ozaki wrote: > On Tue, Jun 3, 2014 at 10:06 PM, Ryota Ozaki wrote: >> Hi Darren, >> >> On Tue, Jun 3, 2014 at 9:16 PM, Darren Reed wrote: >>> I assume this to be related to what rmind is doing, yes? >> >> Yes and no. We have a same goal (networking parallelism), but we're >> working on different components; he is mainly at L3 and above, and >> we are below L3. We collaborate a little to avoid overlapping each >> effort, but we are working separately. >> >>> >>> Is there a projects page that outlines the approach, etc? >> >> Not yet. I'll propose it our members. > > The page will be somewhere under > https://github.com/IIJ-NetBSD/netbsd-src/wiki . https://github.com/IIJ-NetBSD/netbsd-src/wiki/smpnet Here you are. Any comments are appreciated :) Regards, ozaki-r > > ozaki-r > >> >>> >>> This URL: https://github.com/ozaki-r/netbsd-src/tree/experimental/mpsafe-bridge-wm-vioif >>> isn't really very useful in a web browser. Do you have one that is? >> >> Please look at >> >> https://github.com/ozaki-r/netbsd-src/compare/master...experimental%2Fmpsafe-bridge-wm-vioif >> for a readable diff, or >> http://www.netbsd.org/~ozaki-r/mpsafe-bridge-wm-vioif.diff >> for a raw patch. >> >> Regards, >> ozaki-r >> >>> >>> Darren >>>
Re: RFC: mpsafe bridge and NIC drivers (vioif and wm)
On Mon, Jun 30, 2014 at 4:09 PM, Ryota Ozaki wrote: > Hi, > > http://www.netbsd.org/~ozaki-r/mpsafe-ifq-wm.diff > > I've updated the patch. The changes include: > - Make callouts MPSAFE > - Reduce splnet as much as possible > - Make ifconfig up/down work correctly under load > > if_wm is now MPSAFEd as much as possible at this point. I've tested the combinations of the two cases: - NET_MPSAFE or not - NEWQUEUE or not (Rangeley or KVM) All works fine for me. I'll commit the patch soon, but any comments and suggestions are still not too late! Thanks, ozaki-r > > Thanks, > ozaki-r
pthread crashes on amd64-current
Hi, I have a soekris net6501 and using a current amd64 kernel with either the 6.1.4 or daily from 2014-06-25 userland causes programs linked with libpthread to crash. i386 works perfectly. It looks awfully much like PR/47271 that was fixed in 2012. I had a look in lib/libpthread/pthread.c but it looks quite different from the patch in the PR... Is it just me doing it wrong or has there been a regression? -- Staffan Thomén - ADB3 455F 10D5 86D1 78D6 048D 11BB D66E 7C7E 2EF8
Re: Obtaining list of created sockets
That would be an excellent start; I had considered it before, however I thought that netstat only listed listening connections. With lsof, you would only get sockets created with fsocket (those having file descriptors). I suppose combining the way the two get their information would yield a majority of the sockets created, however I would like to get all internal sockets that may not be listening yet, or never get a file descriptor. On Mon, Jun 30, 2014 at 8:53 AM, Johnny Billquist wrote: > On 2014-06-30 08:52, Johnny Billquist wrote: > >> On 2014-06-30 08:29, Will Dignazio wrote: >> >>> Hi, >>> >>> I've dug through the so* code, and haven't found any table or list >>> dedicated to created sockets. The exception only seems to be fsocreate, >>> which attaches a file descriptor that could be used to find the assigned >>> socket. >>> >>> I'm working on a module where I would like to expose the list of created >>> sockets as a series of directories containing file descriptors that let >>> you access the properties of the sockets. This of course requires that >>> the module be aware of all the created sockets in the system. So, >>> without modifying the current socket creation process, is there a way to >>> obtain a list or table of created (not necessarily bound/open/listening) >>> sockets? >>> >> >> Why not just check how netstat does it? >> > > Or lsof, if you want find potential open file descriptors before they have > even been bound... > > Johnny > > -- William Dignazio
