From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 19 12:26:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 365FE1065670; Sun, 19 Aug 2012 12:26:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 48AFA8FC0C; Sun, 19 Aug 2012 12:26:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7JCQmtJ012872; Sun, 19 Aug 2012 15:26:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q7JCQacf079186; Sun, 19 Aug 2012 15:26:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7JCQaEf079185; Sun, 19 Aug 2012 15:26:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 19 Aug 2012 15:26:36 +0300 From: Konstantin Belousov To: Jilles Tjoelker Message-ID: <20120819122636.GH33100@deviant.kiev.zoral.com.ua> References: <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com> <20120814210911.GA90640@stack.nl> <502AE1D4.4060308@gmail.com> <20120815174942.GN5883@deviant.kiev.zoral.com.ua> <502C3D8B.4060008@gmail.com> <20120816114426.GR5883@deviant.kiev.zoral.com.ua> <20120816223933.GA19925@stack.nl> <20120817124312.GD33100@deviant.kiev.zoral.com.ua> <20120817160847.GA34417@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYYhpFXgKVw71fwr" Content-Disposition: inline In-Reply-To: <20120817160847.GA34417@stack.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org Subject: Re: system() using vfork() or posix_spawn() and libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 12:26:44 -0000 --mYYhpFXgKVw71fwr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 17, 2012 at 06:08:47PM +0200, Jilles Tjoelker wrote: > On Fri, Aug 17, 2012 at 03:43:12PM +0300, Konstantin Belousov wrote: > > On Fri, Aug 17, 2012 at 12:39:33AM +0200, Jilles Tjoelker wrote: > > > On Thu, Aug 16, 2012 at 02:44:26PM +0300, Konstantin Belousov wrote: > > > > BTW, returning to Jilles proposal, can we call vfork() only for > > > > single-threaded parent ? I think it gives good boost for single-thr= eaded > > > > case, and also eliminates the concerns of non-safety. >=20 > > > This would probably fix the safety issues but at a price. There is a > > > correlation between processes so large that they benefit greatly from > > > vfork and threaded processes. > > Ok, so I will continue with my patch. >=20 > > > On the other hand, I think direct calls to vfork() in applications are > > > risky and it may not be possible to support them safely in all > > > circumstances. However, if libc is calling vfork() such as via popen(= ), > > > system() or posix_spawn(), it should be possible even in a > > > multi-threaded process. In that case, the rtld and libthr problems can > > > be avoided by using aliases with hidden visibility for all functions = the > > > vforked child needs to call (or any other method that prevents > > > interposition and hard-codes a displacement into libc.so). >=20 > > I do not see how using any aliases could help there. Basically, if mt > > process is not single-threaded for vfork, you can have both some parent > > thread and child enter rtld. This is complete mess. >=20 > If libc calls a function with hidden visibility, this proceeds directly > (not via the PLT) and rtld is not involved. Oh, so you are only concerned with libc there ? If spending so much efforts on this issue, IMO it is pity to only fix libc and not fix vfork for all consumers. >=20 > Several ways to do this are in section 2.2.7 Avoid Using Exported > Symbols of Ulrich Drepper's dsohowto. One of them is something like >=20 > extern __typeof(next) next_int > __attribute((alias("next"), visibility("hidden"))); >=20 > in the same source as the definition of the function >=20 > int next(void) { ...; } >=20 > As Drepper notes, the visibility attribute is not strictly required if a > version script keeps the symbol local but it might lead to better code. > At least on i386, though, the optimal direct near call instruction is > generated even without it. For example, _nsdispatch() calls > libc_dlopen() (kept local by the version script) without going through > the PLT (from the output of objdump -dS on the libc.so.7 in /usr/obj). I am not confident, so this might be a hallucination, but 'optimization' in the recent gnu ld might rewrite the call target to avoid PLT when symbol visibility is hidden. >=20 > In the assembler syscall stubs using code from lib/libc/arch/SYS.h this > can be done by adding another .set (we currently have foo, _foo and > __sys_foo for a syscall foo; some syscalls have only _foo and > __sys_foo) such as __syshidden_foo. The ones that are actually used > then need prototypes (similar to the __sys_* ones in lib/libthr/?). >=20 > For some reason, the symbol .cerror (HIDENAME(cerror)) is also exported. > Either this should be kept local or a local uninterposable alias should > be added and used (as with the syscalls). >=20 > The function __error() (to get errno's address for the current thread) > is and must be called via the PLT (because libthr is separate). > Therefore, we should ensure it is called at least once before vfork so > calls in the child do not involve rtld. The implementations for the > various architectures use the TLS register (or memory location for ARM), > so they seem safe. >=20 > This should suffice to fix posix_spawn() but the _execvpe() used by > posix_spawnp also uses various string functions. If not all of these > have already been called earlier, this will not work. Making calls to > them not go through the PLT seems fairly hard, even though it would make > sense in general, so perhaps I should instead reimplement it such that > the parent does almost all of the work. >=20 > An alternative is to write the core of posix_spawn() in assembler using > system calls directly but I would rather avoid that :( BTW, we have very gross inefficiency in our libc syscall stubs on i386. Namely, the PIC_PROLOGUE generates 'call 1f; 1f:' sequence, which trashes return stack predictor in CPU. When compiling for pentium pro and later, gcc calls dummy procedure that moves return address into %ebx. I think we ought to do this unconditionally for libc stubs in modern times. >=20 > > > There may still be a problem in programs that install signal handlers > > > because the set of async-signal-safe functions is larger than what can > > > be done in a vforked child. Userland can avoid this by masking affect= ed > > > signals before calling vfork() and resetting them to SIG_DFL before > > > unmasking them. This will add many syscalls if the code does not know > > > which signals are affected (such as libc). Alternatively, the kernel > > > could map caught signals to the default action for processes with > > > P_PPWAIT (just like it does not stop such processes because of signals > > > or TTY job control). >=20 > > If rtld does not work, then any library function call from a signal han= dler > > is problematic. My goal is to get a working rtld and possibly malloc. >=20 > > BTW, not quite related, it seems that the placement of openat, > > setcontext and swapcontext in the pthread.map is wrong. openat is > > at FBSD_1.1 in libc, and *context are at FBSD_1.0 version, while > > libthr exports them at 1.2. App or library gets linked to arbitrary > > version depending on whether libphread was specified at link time, and > > interposition from libthr does not work. >=20 > Oops :( Can this still be fixed (like by exporting identical functions > in multiple versions)? My take is that we shall declare this an ABI bug and fix it before 9.1 by exporting only the right version from libthr. This would indeed break some binaries, but I having the same symbol at different versions gives not the semantic we want for bugfix (since you would still link to the default version). >=20 > > Below is the latest version of my patch for vfork, which survives (modi= fied) > > tools/test/pthread_vfork_test. Patch is only for x86 right now. >=20 > Why does this patch call thread_single(SINGLE_BOUNDARY)? I think this > just causes breakage by causing short writes, [ERESTART] and the like > where not permitted by POSIX while not fixing userland's problems. From > userland's point of view, thread_single(SINGLE_BOUNDARY) just freezes > threads at whatever point they are executing, including while holding an > internal lock. Also, the thread_single_end() is before waiting for the > child to exec or exit (because that is now just before returning to > userland). Oh, the placement of the single_end() is bug. Thank you for noting it. The EINTR return from syscalls in other threads when doing fork(2) in one thread is common and well-known situation. I believe that older Solarises and SVr4 did exactly this. So I do not consider the EINTR or short i/o an unacceptable cost, but please see below. >=20 > If single-threading is needed, it should be done in userland such as via > pthread_suspend_all_np(). This function already ensures no other thread > is in a libthr critical section. If rtld blocks SIGTHR during its > critical sections, it likely also waits for the threads to leave rtld. > As with kernel-level single-threading, this is slow and causes incorrect > short writes. User-mode single-threading, like pthread_suspend_all_np() is order of magnitude slower then kernel-mode single-threading (I admit that I was not aware of pthread_suspend_all_np()). The cause is that kernel often can declare single-threading done when the threads are stopped while still on sleepqueue. Only recently we started marking some sleeps as 'unsafe to stop', mostly in NFS land. So pthread_suspend_all_np() needs to wake up all threads, deliver SIGCANCEL, wait for threads to leave kernel and get ast. For large process were lot of threads typically just sleep waiting for (socket) i/o, there is a lot of cycles to spend. >=20 > If single-threading is only necessary because umtx locks are formally > per-process instead of per-vmspace, then I suggest avoiding the trouble > and depending on the fact that they are per-vmspace. I agree. I worried about inter-process locking to prevent simultaneous entry into rtld or malloc from parent other thread and child, but as David rightfully pointed out, still relied on single vmspace for unlock. So I removed the single-threading from the kernel, relying on the usermode locks to prevent parallel rtld entrance and to lock fork/vfork in parent. Patch below also fixes a typo in amd64/vfork.S, which also passes pthread_vfork_test now. diff --git a/lib/libthr/arch/amd64/Makefile.inc b/lib/libthr/arch/amd64/Mak= efile.inc index e6d99ec..476d26a 100644 --- a/lib/libthr/arch/amd64/Makefile.inc +++ b/lib/libthr/arch/amd64/Makefile.inc @@ -1,3 +1,4 @@ #$FreeBSD$ =20 -SRCS+=3D pthread_md.c _umtx_op_err.S +CFLAGS+=3D-I${.CURDIR}/../libc/${MACHINE_CPUARCH} +SRCS+=3D pthread_md.c _umtx_op_err.S vfork.S diff --git a/lib/libthr/arch/amd64/amd64/vfork.S b/lib/libthr/arch/amd64/am= d64/vfork.S new file mode 100644 index 0000000..7997032 --- /dev/null +++ b/lib/libthr/arch/amd64/amd64/vfork.S @@ -0,0 +1,77 @@ +/*- + * Copyright (c) 2012 Konstantin Belousov + * Copyright (c) 1990 The Regents of the University of California. + * All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * William Jolitz. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "SYS.h" + + .weak _vfork + .set _vfork,__sys_vfork + .weak vfork + .set vfork,__sys_vfork +ENTRY(__sys_vfork) + call _thr_vfork_pre + popq %rsi /* fetch return address (%rsi preserved) */ + mov $SYS_vfork,%rax + KERNCALL + jb 2f + cmpl $0,%eax + jne 1f + pushq %rsi + pushq %rsi /* twice for stack alignment */ + call CNAME(_thr_vfork_post_child) + popq %rsi + popq %rsi + xorl %eax,%eax + jmp *%rsi +1: + pushq %rsi + pushq %rax + call CNAME(_thr_vfork_post_parent) + popq %rax + popq %rsi + jmp *%rsi +2: + pushq %rsi + pushq %rax + call CNAME(_thr_vfork_post_child) + call PIC_PLT(CNAME(__error)) + popq %rdx + movq %rdx,(%rax) + movq $-1,%rax + movq %rax,%rdx + retq +END(__sys_vfork) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libthr/arch/i386/Makefile.inc b/lib/libthr/arch/i386/Makef= ile.inc index 01290d5..13d55e2 100644 --- a/lib/libthr/arch/i386/Makefile.inc +++ b/lib/libthr/arch/i386/Makefile.inc @@ -1,3 +1,4 @@ # $FreeBSD$ =20 -SRCS+=3D pthread_md.c _umtx_op_err.S +CFLAGS+=3D-I${.CURDIR}/../libc/${MACHINE_CPUARCH} +SRCS+=3D pthread_md.c _umtx_op_err.S vfork.S diff --git a/lib/libthr/arch/i386/i386/vfork.S b/lib/libthr/arch/i386/i386/= vfork.S new file mode 100644 index 0000000..ca8896b --- /dev/null +++ b/lib/libthr/arch/i386/i386/vfork.S @@ -0,0 +1,82 @@ +/*- + * Copyright (c) 2012 Konstantin Belousov + * Copyright (c) 1990 The Regents of the University of California. + * All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * William Jolitz. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "SYS.h" + + .weak _vfork + .set _vfork,__sys_vfork + .weak vfork + .set vfork,__sys_vfork +ENTRY(__sys_vfork) + PIC_PROLOGUE + call PIC_PLT(CNAME(_thr_vfork_pre)) + PIC_EPILOGUE + popl %ecx /* my rta into ecx */ + mov $SYS_vfork,%eax + KERNCALL + jb error_ret + pushl %ecx + cmpl $0,%eax + jne parent_ret + PIC_PROLOGUE + call PIC_PLT(CNAME(_thr_vfork_post_child)) + PIC_EPILOGUE + popl %ecx + xorl %eax,%eax + jmp *%ecx +parent_ret: + pushl %eax + PIC_PROLOGUE + call PIC_PLT(CNAME(_thr_vfork_post_parent)) + PIC_EPILOGUE + popl %eax + popl %ecx + jmp *%ecx +error_ret: + pushl %ecx + pushl %eax + PIC_PROLOGUE + call PIC_PLT(CNAME(_thr_vfork_post_child)) + call PIC_PLT(CNAME(__error)) + PIC_EPILOGUE + popl %edx + movl %edx,(%eax) + movl $-1,%eax + movl %eax,%edx + retl +END(__sys_vfork) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libthr/pthread.map b/lib/libthr/pthread.map index 355edea..40d14b4 100644 --- a/lib/libthr/pthread.map +++ b/lib/libthr/pthread.map @@ -157,6 +157,7 @@ FBSD_1.0 { system; tcdrain; usleep; + vfork; wait; wait3; wait4; diff --git a/lib/libthr/thread/Makefile.inc b/lib/libthr/thread/Makefile.inc index ddde6e9..92e82ac 100644 --- a/lib/libthr/thread/Makefile.inc +++ b/lib/libthr/thread/Makefile.inc @@ -55,4 +55,5 @@ SRCS+=3D \ thr_switch_np.c \ thr_symbols.c \ thr_umtx.c \ + thr_vfork.c \ thr_yield.c diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_privat= e.h index ba272fe..951c3b8 100644 --- a/lib/libthr/thread/thr_private.h +++ b/lib/libthr/thread/thr_private.h @@ -757,6 +757,7 @@ void _thr_cancel_leave(struct pthread *, int) __hidden; void _thr_testcancel(struct pthread *) __hidden; void _thr_signal_block(struct pthread *) __hidden; void _thr_signal_unblock(struct pthread *) __hidden; +void _thr_signal_unblock_noref(struct pthread *) __hidden; void _thr_signal_init(void) __hidden; void _thr_signal_deinit(void) __hidden; int _thr_send_sig(struct pthread *, int sig) __hidden; @@ -777,6 +778,9 @@ int _thr_setscheduler(lwpid_t, int, const struct sched_= param *) __hidden; void _thr_signal_prefork(void) __hidden; void _thr_signal_postfork(void) __hidden; void _thr_signal_postfork_child(void) __hidden; +void _thr_vfork_pre(void) __hidden; +void _thr_vfork_post_child(void) __hidden; +void _thr_vfork_post_parent(void) __hidden; void _thr_try_gc(struct pthread *, struct pthread *) __hidden; int _rtp_to_schedparam(const struct rtprio *rtp, int *policy, struct sched_param *param) __hidden; @@ -833,6 +837,7 @@ pid_t __sys_getpid(void); ssize_t __sys_read(int, void *, size_t); ssize_t __sys_write(int, const void *, size_t); void __sys_exit(int); +pid_t __sys_vfork(void); #endif =20 static inline int diff --git a/lib/libthr/thread/thr_sig.c b/lib/libthr/thread/thr_sig.c index 3dee8b7..3e5b25e 100644 --- a/lib/libthr/thread/thr_sig.c +++ b/lib/libthr/thread/thr_sig.c @@ -107,6 +107,13 @@ _thr_signal_unblock(struct pthread *curthread) __sys_sigprocmask(SIG_SETMASK, &curthread->sigmask, NULL); } =20 +void +_thr_signal_unblock_noref(struct pthread *curthread) +{ + if (curthread->sigblock =3D=3D 0) + __sys_sigprocmask(SIG_SETMASK, &curthread->sigmask, NULL); +} + int _thr_send_sig(struct pthread *thread, int sig) { diff --git a/lib/libthr/thread/thr_vfork.c b/lib/libthr/thread/thr_vfork.c new file mode 100644 index 0000000..80c9d1e --- /dev/null +++ b/lib/libthr/thread/thr_vfork.c @@ -0,0 +1,123 @@ +/* + * Copyright (c) 2012 Konstantin Belousov + * Copyright (c) 2005 David Xu + * Copyright (c) 2003 Daniel Eischen + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Neither the name of the author nor the names of any co-contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/* + * Copyright (c) 1995-1998 John Birrell + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the author nor the names of any co-contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY JOHN BIRRELL AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include "namespace.h" +#include +#include +#include +#include +#include +#include +#include +#include "un-namespace.h" + +#include "libc_private.h" +#include "rtld_lock.h" +#include "thr_private.h" + +static int rtld_locks[MAX_RTLD_LOCKS]; +static int cancelsave, was_threaded; + +void +_thr_vfork_pre(void) +{ + struct pthread *curthread; + + curthread =3D _get_curthread(); + _thr_rwl_wrlock(&_thr_atfork_lock); + cancelsave =3D curthread->no_cancel; + curthread->no_cancel =3D 1; + _thr_signal_block(curthread); + _thr_signal_prefork(); + if (_thr_isthreaded() !=3D 0) { + was_threaded =3D 1; + _malloc_prefork(); + _rtld_atfork_pre(rtld_locks); + } else + was_threaded =3D 0; +} + +void +_thr_vfork_post_child(void) +{ + struct pthread *curthread; + + _thr_signal_postfork(); + if (was_threaded) { + _rtld_atfork_post(rtld_locks); + _malloc_postfork(); + } + curthread =3D _get_curthread(); + _thr_signal_unblock(curthread); + curthread->no_cancel =3D cancelsave; + _thr_rwlock_unlock(&_thr_atfork_lock); + if (curthread->cancel_async) + _thr_testcancel(curthread); +} + +void +_thr_vfork_post_parent(void) +{ + struct pthread *curthread; + + curthread =3D _get_curthread(); + _thr_signal_unblock_noref(curthread); + if (curthread->cancel_async) + _thr_testcancel(curthread); +} diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 46cdca1..6f2cfed 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -150,11 +150,7 @@ sys_vfork(struct thread *td, struct vfork_args *uap) int error, flags; struct proc *p2; =20 -#ifdef XEN - flags =3D RFFDG | RFPROC; /* validate that this is still an issue */ -#else flags =3D RFFDG | RFPROC | RFPPWAIT | RFMEM; -#endif =09 error =3D fork1(td, flags, 0, &p2, NULL, 0); if (error =3D=3D 0) { td->td_retval[0] =3D p2->p_pid; --mYYhpFXgKVw71fwr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAw23sACgkQC3+MBN1Mb4h4pQCg6bt7mxwbf+9RzwF454I+ymhT RmwAn3IU/Re8GQwf3YuKoAo+Cj2rquW9 =0W8i -----END PGP SIGNATURE----- --mYYhpFXgKVw71fwr-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 08:51:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8530E106564A for ; Mon, 20 Aug 2012 08:51:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 3188814DD5B; Mon, 20 Aug 2012 08:51:56 +0000 (UTC) Message-ID: <5031FAAB.9020409@FreeBSD.org> Date: Mon, 20 Aug 2012 01:51:55 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Vitaly Magerya References: In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling?=, "Bjoern A. Zeeb" , =?ISO-8859-1?Q?_Sm=F8rgrav?= , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:51:56 -0000 On 08/06/2012 13:23, Vitaly Magerya wrote: > Doug Barton wrote: >> On 07/07/2012 16:33, Garrett Wollman wrote: >>> The utilities (specifically host(1) and dig(1)) are the only >>> user-visible interfaces I care about. > [...] >> ldns (a dependency of unbound) comes with drill, which is a dig-alike >> tool. I'd like to see us produce a host-alike based on ldns as well, > > If there still is interest, I've got just that at [1]. This tool, > ldns-host, implements all the options of bind9-host (except for > debugging ones), and produces close (and often identical) output. > > There's a list of differences between ldns-host and bind9-host > in the man page (see [2]); most items can be fixed if people > will request for it. Some more exotic situations where not tested > though, so that list is only partial. > > [1] http://hg.tx97.net/ldns-host/file/ > [2] http://manweb.tx97.net/http://hg.tx97.net/ldns-host/raw-file/tip/ldns-host.1 If I didn't already say so, this is awesome! :) Dag-Erling, do you have a timeline for getting started on the ldns/unbound import? -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 08:55:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0747C106566C for ; Mon, 20 Aug 2012 08:55:48 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id A7A3B8FC08 for ; Mon, 20 Aug 2012 08:55:47 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 965B225D3A9B for ; Mon, 20 Aug 2012 08:55:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C1ED1BE84AC for ; Mon, 20 Aug 2012 08:55:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 9PNJYaLy-JIT for ; Mon, 20 Aug 2012 08:55:37 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 5EC38BE84AA for ; Mon, 20 Aug 2012 08:55:37 +0000 (UTC) Date: Mon, 20 Aug 2012 08:55:36 +0000 (UTC) From: "Bjoern A. Zeeb" To: FreeBSD Hackers In-Reply-To: <5031FAAB.9020409@FreeBSD.org> Message-ID: References: <5031FAAB.9020409@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:55:48 -0000 On Mon, 20 Aug 2012, Doug Barton wrote: > On 08/06/2012 13:23, Vitaly Magerya wrote: >> Doug Barton wrote: >>> On 07/07/2012 16:33, Garrett Wollman wrote: >>>> The utilities (specifically host(1) and dig(1)) are the only >>>> user-visible interfaces I care about. >> [...] >>> ldns (a dependency of unbound) comes with drill, which is a dig-alike >>> tool. I'd like to see us produce a host-alike based on ldns as well, >> >> If there still is interest, I've got just that at [1]. This tool, >> ldns-host, implements all the options of bind9-host (except for >> debugging ones), and produces close (and often identical) output. >> >> There's a list of differences between ldns-host and bind9-host >> in the man page (see [2]); most items can be fixed if people >> will request for it. Some more exotic situations where not tested >> though, so that list is only partial. >> >> [1] http://hg.tx97.net/ldns-host/file/ >> [2] http://manweb.tx97.net/http://hg.tx97.net/ldns-host/raw-file/tip/ldns-host.1 > > If I didn't already say so, this is awesome! :) > > Dag-Erling, do you have a timeline for getting started on the > ldns/unbound import? We will continue to reject this until there are more firm plans, proper documentation on the security support side, which I cannot remember Simon got an answer for. I continue to say that I am not willing to trade one for another for the sake of just changing the name. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 09:12:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 483201065670 for ; Mon, 20 Aug 2012 09:12:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8819E14EE09; Mon, 20 Aug 2012 09:12:07 +0000 (UTC) Message-ID: <5031FF67.80000@FreeBSD.org> Date: Mon, 20 Aug 2012 02:12:07 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <5031FAAB.9020409@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 09:12:52 -0000 On 08/20/2012 01:55, Bjoern A. Zeeb wrote: > We will continue to reject this until there are more firm plans, > proper documentation on the security support side, which I cannot > remember Simon got an answer for. I gave a clear answer. If there are any pieces missing it's up to Simon to follow up with Dag-Erling. > I continue to say that I am not willing to trade one for another > for the sake of just changing the name. Have you seriously not been paying attention to the numerous reasons why BIND in the base is no longer a good fit? In any case, importing ldns/unbound is a different question from removing BIND. Not only do I not see any reason not to move forward on the former, I think that once people see a solid implementation in place already it will ease the fears about removing BIND. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 09:19:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F0741065673 for ; Mon, 20 Aug 2012 09:19:17 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 175328FC0C for ; Mon, 20 Aug 2012 09:19:16 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CD80625D386E for ; Mon, 20 Aug 2012 09:19:15 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id E82FFBE84AB for ; Mon, 20 Aug 2012 09:19:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id CdppDWzkXmS9 for ; Mon, 20 Aug 2012 09:19:13 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A17ABBE84AA for ; Mon, 20 Aug 2012 09:19:13 +0000 (UTC) Date: Mon, 20 Aug 2012 09:19:12 +0000 (UTC) From: "Bjoern A. Zeeb" To: FreeBSD Hackers In-Reply-To: <5031FF67.80000@FreeBSD.org> Message-ID: References: <5031FAAB.9020409@FreeBSD.org> <5031FF67.80000@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 09:19:17 -0000 On Mon, 20 Aug 2012, Doug Barton wrote: > On 08/20/2012 01:55, Bjoern A. Zeeb wrote: > >> We will continue to reject this until there are more firm plans, >> proper documentation on the security support side, which I cannot >> remember Simon got an answer for. > > I gave a clear answer. If there are any pieces missing it's up to Simon > to follow up with Dag-Erling. If you did, where was it. My email client shows 1 follow-up to http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039837.html and that was unrelated and not you. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 09:26:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5195F1065673; Mon, 20 Aug 2012 09:26:52 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 153178FC08; Mon, 20 Aug 2012 09:26:51 +0000 (UTC) Received: from [192.168.111.191] (unknown [62.244.179.74]) by relay.exonetric.net (Postfix) with ESMTPSA id 3F2DA2C68C; Mon, 20 Aug 2012 10:16:57 +0100 (BST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Mark Blackman In-Reply-To: <5031FF67.80000@FreeBSD.org> Date: Mon, 20 Aug 2012 10:16:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <5031FAAB.9020409@FreeBSD.org> <5031FF67.80000@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1485) Cc: "Bjoern A. Zeeb" , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 09:26:52 -0000 On 20 Aug 2012, at 10:12, Doug Barton wrote: > On 08/20/2012 01:55, Bjoern A. Zeeb wrote: > >> We will continue to reject this until there are more firm plans, >> proper documentation on the security support side, which I cannot >> remember Simon got an answer for. > > I gave a clear answer. If there are any pieces missing it's up to Simon > to follow up with Dag-Erling. >> I continue to say that I am not willing to trade one for another >> for the sake of just changing the name. > > Have you seriously not been paying attention to the numerous reasons why > BIND in the base is no longer a good fit? Perhaps bunging together a quick wiki-page to point busier individuals at would be handy? - Mark From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 09:30:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id DADDE10656EE for ; Mon, 20 Aug 2012 09:30:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E7C7914E0A5; Mon, 20 Aug 2012 09:30:29 +0000 (UTC) Message-ID: <503203B5.1080300@FreeBSD.org> Date: Mon, 20 Aug 2012 02:30:29 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Mark Blackman References: <5031FAAB.9020409@FreeBSD.org> <5031FF67.80000@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 09:30:35 -0000 On 08/20/2012 02:16, Mark Blackman wrote: > > On 20 Aug 2012, at 10:12, Doug Barton wrote: > >> On 08/20/2012 01:55, Bjoern A. Zeeb wrote: >> >>> We will continue to reject this until there are more firm plans, >>> proper documentation on the security support side, which I cannot >>> remember Simon got an answer for. >> >> I gave a clear answer. If there are any pieces missing it's up to Simon >> to follow up with Dag-Erling. > > >>> I continue to say that I am not willing to trade one for another >>> for the sake of just changing the name. >> >> Have you seriously not been paying attention to the numerous reasons why >> BIND in the base is no longer a good fit? > > Perhaps bunging together a quick wiki-page to point busier individuals > at would be handy? Just read this thread in the archives, that should do it for you. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 09:35:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 8615C1065672 for ; Mon, 20 Aug 2012 09:35:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 63E0C14DA4C; Mon, 20 Aug 2012 09:35:48 +0000 (UTC) Message-ID: <503204F3.7060803@FreeBSD.org> Date: Mon, 20 Aug 2012 02:35:47 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <5031FAAB.9020409@FreeBSD.org> <5031FF67.80000@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Dag-Erling Smorgrav Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 09:35:48 -0000 On 08/20/2012 02:19, Bjoern A. Zeeb wrote: > On Mon, 20 Aug 2012, Doug Barton wrote: > >> On 08/20/2012 01:55, Bjoern A. Zeeb wrote: >> >>> We will continue to reject this until there are more firm plans, >>> proper documentation on the security support side, which I cannot >>> remember Simon got an answer for. >> >> I gave a clear answer. If there are any pieces missing it's up to Simon >> to follow up with Dag-Erling. > > If you did, where was it. My email client shows 1 follow-up to > http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039837.html > and that was unrelated and not you. You don't get to comment on the discussion if you're not going to follow the discussion. :) It's not up to me to advocate for the inclusion of unbound in any case, that's up to Dag-Erling. My point is simple ... BIND is not a good fit for the FreeBSD base, and it needs to go. The fact that we not only have a solid replacement for it ready to go, but a willing maintainer, is a bonus. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 14:52:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9303C106566B; Mon, 20 Aug 2012 14:52:31 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8468FC0A; Mon, 20 Aug 2012 14:52:31 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T3ToR-000JLs-0f; Mon, 20 Aug 2012 18:22:43 +0300 Message-ID: <50324DB4.6080905@cabletv.dp.ua> Date: Mon, 20 Aug 2012 17:46:12 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Aug 2012 16:24:55 +0000 Cc: Subject: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 14:52:31 -0000 Hi. I found some overhead code in /src/sys/net/if_ethersubr.c and /src/sys/netgraph/ng_ether.c It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. This code call every time, when we send Ethernet packet. On example, on my machine in invoked nearly 20K per second. Why we are use bcopy(), to copy only 6 bytes? Answer - in some architectures we are can not directly copy unaligned data. I propose this solution. In file /usr/src/include/net/ethernet.h add this lines: static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { #if defined(__i386__) || defined(__amd64__) *dst = *src; #else bcopy(src, dst, ETHER_ADDR_LEN); #endif } On platform i386 gcc produce like this code: leal -30(%ebp), %eax leal 6(%eax), %ecx leal -44(%ebp), %edx movl (%edx), %eax movl %eax, (%ecx) movzwl 4(%edx), %eax movw %ax, 4(%ecx) And clang produce this: movl -48(%ebp), %ecx movl %ecx, -26(%ebp) movw -44(%ebp), %si movw %si, -22(%ebp) All this variants are much faster, than bcopy() From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 16:41:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFAD41065670 for ; Mon, 20 Aug 2012 16:41:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9278FC14 for ; Mon, 20 Aug 2012 16:41:17 +0000 (UTC) Received: by dadr6 with SMTP id r6so2427081dad.13 for ; Mon, 20 Aug 2012 09:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ATR+a737mE2XVMGayWXiEhZO8qe2Cf9Rroa14hntcsI=; b=MOcuTzE88TWQxs3xR3bWLlssVeclI1aF7GhSXs071wTe7hjl0jtbgpKzyDcl2JwXvy 9m9BJXs6YA6IUxW1NB3KzsnU95szCMc/iIdPNo18geO6PvD8wNL70U+qVIgPmo7te4Cd zEac4kG4AyOQqNky22X/PUjAgO7YXixBxlxuEqZHlvRTOUJaOATdcnhd9ZQmIqtZ7hHv lJmddAlnafjWy2aio+MinApL7DWYPwT0d7hH4SzZBXk7g5g/24wo4G2exeW2f8b1Z6iB LgDcSs6G6FgKbZkii11bLoRGik/OIlE+dGOKRe/DkP9etE6ipJLbwm3wFLfo4gVlhMzq U2yQ== Received: by 10.66.74.100 with SMTP id s4mr30960611pav.27.1345480877170; Mon, 20 Aug 2012 09:41:17 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([216.51.42.66]) by mx.google.com with ESMTPS id kt2sm11392939pbc.73.2012.08.20.09.41.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 09:41:16 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50324DB4.6080905@cabletv.dp.ua> Date: Mon, 20 Aug 2012 10:41:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4C06696D-EF17-411D-A229-B738B9D47B8A@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> To: Mitya X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQn4J4qUSG2iiKLbunqQCqTegm1U/lujaWjqcNpmWwDWmDa1aE/0ajI8LllKowEGcszWUXjN Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 16:41:17 -0000 On Aug 20, 2012, at 8:46 AM, Mitya wrote: > Hi. > I found some overhead code in /src/sys/net/if_ethersubr.c and = /src/sys/netgraph/ng_ether.c >=20 > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > This code call every time, when we send Ethernet packet. > On example, on my machine in invoked nearly 20K per second. >=20 > Why we are use bcopy(), to copy only 6 bytes? > Answer - in some architectures we are can not directly copy unaligned = data. True for shorts, longs, etc. But why do we need it for ether_addr? It = is a struct that's just an array... That's always safe. > I propose this solution. >=20 > In file /usr/src/include/net/ethernet.h add this lines: >=20 > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > #if defined(__i386__) || defined(__amd64__) Bleck. that's uber ugly. We have a define for unaligned vs aligned = architectures. we should use that here. If we even need this ifdef at = all. Warner > *dst =3D *src; > #else > bcopy(src, dst, ETHER_ADDR_LEN); > #endif > } >=20 > On platform i386 gcc produce like this code: > leal -30(%ebp), %eax > leal 6(%eax), %ecx > leal -44(%ebp), %edx > movl (%edx), %eax > movl %eax, (%ecx) > movzwl 4(%edx), %eax > movw %ax, 4(%ecx) > And clang produce this: > movl -48(%ebp), %ecx > movl %ecx, -26(%ebp) > movw -44(%ebp), %si > movw %si, -22(%ebp) >=20 >=20 > All this variants are much faster, than bcopy() >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 16:49:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0888910656D8; Mon, 20 Aug 2012 16:49:31 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id D53C68FC1E; Mon, 20 Aug 2012 16:49:24 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q7KGmitp035334; Mon, 20 Aug 2012 18:48:48 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q7KGmd0Y035331; Mon, 20 Aug 2012 18:48:43 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 20 Aug 2012 18:48:39 +0200 (CEST) From: Wojciech Puchar To: Mitya In-Reply-To: <50324DB4.6080905@cabletv.dp.ua> Message-ID: References: <50324DB4.6080905@cabletv.dp.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 20 Aug 2012 18:48:49 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 16:49:31 -0000 > #if defined(__i386__) || defined(__amd64__) > *dst = *src; > #else > bcopy(src, dst, ETHER_ADDR_LEN); #else short *tmp1=((*short)src),*tmp2=((*short)dst); *tmp2=*tmp1; *(tmp2+1)=*(tmp1+1); *(tmp2+2)=*(tmp1+2); or use ++. i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 19:06:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07418106566C for ; Mon, 20 Aug 2012 19:06:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C505A8FC0A for ; Mon, 20 Aug 2012 19:06:00 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so7790365pbb.13 for ; Mon, 20 Aug 2012 12:05:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FV6OYrlPxmmTMb7e2jr7yrc99awCVz+KDCbQ4Fh3tu8=; b=RA1Qi5tHvOJvlpw1wa82haB1xD2/dyEwvO06PrPWQtaY12RgjY1oP955cvA2BaBpao obNvrJX9LmOU7FQCXwzp6D3zfGiIhgfY+DmqWhc+TOCUlgm+ViflW0+Lm+SsH4YpzCVC PkVziqqpIhjO3ty+Fc3drWVQgiXdcZGIWEbbocDwp/EfGjoIvuLUrzrMI7R87/Sbl6Eu XiNfasKjdy+MoZkLlT+HUtiQwyUZD5NO5N+8/MoM8fvTSzKNSi4kS8Csq1haJ44QxsEl j2oZQh67v4Rg0g4oe8vYg+drB8ZJ669DY2w4iPrjJhhlsPlRx9gOJtBYDAyhLG+3JuAD t24w== Received: by 10.68.234.169 with SMTP id uf9mr29989923pbc.105.1345489554129; Mon, 20 Aug 2012 12:05:54 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([216.51.42.66]) by mx.google.com with ESMTPS id ka4sm6249974pbc.61.2012.08.20.12.05.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 12:05:53 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 20 Aug 2012 13:05:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50324DB4.6080905@cabletv.dp.ua> To: Wojciech Puchar X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkffXAXYrkV+Vp1hNMd4/hb0ZiJ8W9an4PSBJalo+m+5lC0sGuJqy6YwqIOaytSulWDW1AQ Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:06:01 -0000 On Aug 20, 2012, at 10:48 AM, Wojciech Puchar wrote: >> #if defined(__i386__) || defined(__amd64__) >> *dst =3D *src; >> #else >> bcopy(src, dst, ETHER_ADDR_LEN); > #else > short *tmp1=3D((*short)src),*tmp2=3D((*short)dst); > *tmp2=3D*tmp1; *(tmp2+1)=3D*(tmp1+1); *(tmp2+2)=3D*(tmp1+2); >=20 > or use ++. >=20 > i think it is always aligned to 2 bytes and this should produce usable = code on any CPU? should be 6 instructions on MIPS and PPC IMHO. We should tag it as __aligned(2) then, no? If so, then the compiler = should generate the code you posted. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 19:19:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40C0F10656A4; Mon, 20 Aug 2012 19:19:10 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0C78FC1A; Mon, 20 Aug 2012 19:19:04 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q7KJI5f1019376; Mon, 20 Aug 2012 21:18:07 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q7KJHwPa019373; Mon, 20 Aug 2012 21:18:01 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 20 Aug 2012 21:17:58 +0200 (CEST) From: Wojciech Puchar To: Warner Losh In-Reply-To: Message-ID: References: <50324DB4.6080905@cabletv.dp.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 20 Aug 2012 21:18:10 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:19:10 -0000 >> or use ++. >> >> i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. > > We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. should is the most important word in Your post. what it actually do - i don't know. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 19:20:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1A501065679 for ; Mon, 20 Aug 2012 19:20:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B87768FC1B for ; Mon, 20 Aug 2012 19:20:32 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so7809390pbb.13 for ; Mon, 20 Aug 2012 12:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=KCxyECDI8FnX8CSLsoeicy0Z5QcbV3tJPV8iRNrzmKs=; b=WDFiVxqdRHWmxL/Bt1QeC6eaDKWeIcfc8CEQL8ZZX7K1Hj842N8qBekLXXAyVrFbEp EpHlYwKwR02uY/JYW+s4VMX8Wnpn+IWp2m25BtdkTs850jAfS/vfXuf43SG+fcvGtQOf 0wu/oL3x0drtKbVm82Y1yD/r2ZHDqDaQ1Ans/Dl1QdmHkjVrcfnueUL0v/DqI09AR6zN 5mLAFbxFrOm3VKp9qiSbPX49IeyY5vaD0BshsvxLXouqH/pAOeXoR5+Vf0LSYOqcAB3I jHOlxq38tYA0sCfmULo6GXzAh3lFnhn8YN7wJUUi3Ipjz0uopQncTpUOytLiBtI5RtLs ItRw== Received: by 10.68.130.65 with SMTP id oc1mr36887796pbb.29.1345490432225; Mon, 20 Aug 2012 12:20:32 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([216.51.42.66]) by mx.google.com with ESMTPS id ty1sm8562932pbc.76.2012.08.20.12.20.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 12:20:31 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 20 Aug 2012 13:20:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> To: Wojciech Puchar X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQn4h9J6iAF+1YY05Vhj0glCPMNHEj+qEPbLE4ooqGb+TVEQgY5o/ekNANcU6FJpL2F0+cjh Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:20:33 -0000 On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: >>> or use ++. >>>=20 >>> i think it is always aligned to 2 bytes and this should produce = usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. >>=20 >> We should tag it as __aligned(2) then, no? If so, then the compiler = should generate the code you posted. > should is the most important word in Your post. what it actually do - = i don't know. If we are requiring this to be __aligned(2), we should tag it as such to = enforce this. Even without this tagging, the code to do a structure level copy of 6 = bytes is going to be tiny... Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 19:26:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C43DD106564A; Mon, 20 Aug 2012 19:26:00 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id A5EC68FC12; Mon, 20 Aug 2012 19:26:00 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C8F24B827; Mon, 20 Aug 2012 12:20:32 -0700 (PDT) To: Warner Losh In-reply-to: Your message of "Mon, 20 Aug 2012 13:05:51 MDT." References: <50324DB4.6080905@cabletv.dp.ua> Comments: In-reply-to Warner Losh message dated "Mon, 20 Aug 2012 13:05:51 -0600." Date: Mon, 20 Aug 2012 12:20:32 -0700 From: Bakul Shah Message-Id: <20120820192032.C8F24B827@mail.bitblocks.com> Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:26:00 -0000 On Mon, 20 Aug 2012 13:05:51 MDT Warner Losh wrote: > > On Aug 20, 2012, at 10:48 AM, Wojciech Puchar wrote: > > >> #if defined(__i386__) || defined(__amd64__) > >> *dst =3D *src; > >> #else > >> bcopy(src, dst, ETHER_ADDR_LEN); > > #else > > short *tmp1=3D((*short)src),*tmp2=3D((*short)dst); > > *tmp2=3D*tmp1; *(tmp2+1)=3D*(tmp1+1); *(tmp2+2)=3D*(tmp1+2); > > > > or use ++. > > > > i think it is always aligned to 2 bytes and this should produce usable > code on any CPU? should be 6 instructions on MIPS and PPC IMHO. > > We should tag it as __aligned(2) then, no? If so, then the compiler > should generate the code you posted. Doesn't gcc inline memcpy these days? From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 20 22:11:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E22C8106566B; Mon, 20 Aug 2012 22:11:32 +0000 (UTC) (envelope-from dplassche@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 151C78FC1D; Mon, 20 Aug 2012 22:11:31 +0000 (UTC) Received: by wicr5 with SMTP id r5so3302424wic.13 for ; Mon, 20 Aug 2012 15:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JDVuqFvb5zamGnjpceFG7VkmTVdohw0DT2iym2XpRyM=; b=JuHloy5P9jFihUNRS6wkwhrqX6BkbLYK2h24HiAVHkvIqEBp6mxG/ONoMWBfr/sX6L Fi+e26/FUb+/qV03Ak7VUHxuEYCz1qL36hic0TBBzVMFbo4yuSOLxsCnDrePlMcz8uI6 q9gK31nroocNedZpR1NuOsl5SeMunRyAOApMr+2BXr14hg2XQG614688hRzqO7NyEkSm ZUZZY2+nr7E1FK0bbIZ0ing5jzFPGkNTbdPimvGVZgqqK+WoXYUUEmkdE1lgdPQ+7drL WdQNOzAvv620+XEawsEI+nwh+wfFjpsxQmDs4kaoGGOjio66S2WvL4hQa6SD3vQ6uH/B mrbQ== MIME-Version: 1.0 Received: by 10.180.91.228 with SMTP id ch4mr32216600wib.7.1345500685151; Mon, 20 Aug 2012 15:11:25 -0700 (PDT) Received: by 10.223.158.7 with HTTP; Mon, 20 Aug 2012 15:11:24 -0700 (PDT) In-Reply-To: <20120816130625.GT5883@deviant.kiev.zoral.com.ua> References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> <5029A9CE.8070307@freebsd.org> <20120816130625.GT5883@deviant.kiev.zoral.com.ua> Date: Mon, 20 Aug 2012 18:11:24 -0400 Message-ID: From: Dan Plassche To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 20 Aug 2012 23:11:38 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 1.x Binaries Work Except under Chroot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 22:11:33 -0000 On Thu, Aug 16, 2012 at 9:06 AM, Konstantin Belousov wrote: > Since you did not provided exact diff of your change, I cannot comment > on what goes wrong. Anyway, just merge the r239301 locally and use > sysctl kern.pid_max. Thanks, the kern.pid_max tunable works well on 8.2. The diff to /usr/src/sys/sys/proc.h before merging in r239301 was editing PID_MAX: --- proc.h.bak 2010-12-21 12:09:25.000000000 -0500 +++ proc.h 2012-08-15 13:54:25.000000000 -0400 @@ -667,7 +667,7 @@ * We use process IDs <= PID_MAX; PID_MAX + 1 must also fit in a pid_t, * as it is used to represent "no process group". */ -#define PID_MAX 99999 +define PID_MAX 30000 #define NO_PID 100000 #define SESS_LEADER(p) ((p)->p_session->s_leader == (p)) From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 03:32:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12703106566B for ; Tue, 21 Aug 2012 03:32:49 +0000 (UTC) (envelope-from dan.mcgregor@usask.ca) Received: from smtp.usask.ca (smtp.usask.ca [128.233.192.40]) by mx1.freebsd.org (Postfix) with ESMTP id DAFBE8FC08 for ; Tue, 21 Aug 2012 03:32:48 +0000 (UTC) Received: from conversion-daemon.usask.ca by usask.ca (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)) id <0M9300I0030H2Q00@usask.ca> for freebsd-hackers@freebsd.org; Mon, 20 Aug 2012 20:32:42 -0600 (CST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by usask.ca (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)) with ESMTPSA id <0M9300AJY32G2S30@usask.ca> for freebsd-hackers@freebsd.org; Mon, 20 Aug 2012 20:32:41 -0600 (CST) Received: by vcbgb22 with SMTP id gb22so7318831vcb.13 for ; Mon, 20 Aug 2012 19:32:41 -0700 (PDT) Received: by 10.221.11.197 with SMTP id pf5mr11967074vcb.29.1345516361859; Mon, 20 Aug 2012 19:32:41 -0700 (PDT) Received: by 10.58.91.169 with HTTP; Mon, 20 Aug 2012 19:32:41 -0700 (PDT) Date: Mon, 20 Aug 2012 20:32:41 -0600 From: Dan McGregor To: freebsd-hackers@freebsd.org Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_2R7SRK8nTZt/NNUkoteUNg)" X-Mailman-Approved-At: Tue, 21 Aug 2012 04:17:33 +0000 Subject: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 03:32:49 -0000 --Boundary_(ID_2R7SRK8nTZt/NNUkoteUNg) Content-type: text/plain; charset=ISO-8859-1 Hi. I've been working on porting compiler-rt/clang's support for address sanitization (asan) to FreeBSD. So far I have it building and it appears to work properly, however the build system expects to be able to build 32 bit binaries on amd64. amd64 doesn't include i386's machine/foo headers. The included patch is my proposed solution: Add i386 headers to /usr/include/i386, and in machine/foo.h, check if it's a 32 bit build and include the appropriate header from i386. For example machine/ucontext.h will include i386/ucontext.h if compiled with -m32. Thoughts? If anyone's curious about the compiler_rt port, I have it at github.com/dannomac/compiler-rt on the branch named freebsd. Dan --Boundary_(ID_2R7SRK8nTZt/NNUkoteUNg) Content-type: text/x-patch; name=0001-modify-amd64-headers-to-include-i386-versions-if-__x.patch; charset=US-ASCII Content-transfer-encoding: BASE64 Content-disposition: attachment; filename=0001-modify-amd64-headers-to-include-i386-versions-if-__x.patch X-Attachment-Id: 4af463252270eddd_0.1 ZGlmZiAtLWdpdCBhL2luY2x1ZGUvTWFrZWZpbGUgYi9pbmNsdWRlL01ha2VmaWxl DQppbmRleCBkMmY2ZDdmLi44ZTI5YTM1IDEwMDY0NA0KLS0tIGEvaW5jbHVkZS9N YWtlZmlsZQ0KKysrIGIvaW5jbHVkZS9NYWtlZmlsZQ0KQEAgLTEyNSw2ICsxMjUs OSBAQCBfTUFSQ0hTPQkke01BQ0hJTkVfQ1BVQVJDSH0NCiAuaWYgJHtNQUNISU5F X0NQVUFSQ0h9ID09ICJpMzg2IiB8fCAke01BQ0hJTkVfQ1BVQVJDSH0gPT0gImFt ZDY0Ig0KIF9NQVJDSFMrPQl4ODYNCiAuZW5kaWYNCisuaWYgJHtNQUNISU5FX0NQ VUFSQ0h9ID09ICJhbWQ2NCINCitfTUFSQ0hTKz0JaTM4Ng0KKy5lbmRpZg0KIA0K IC5pbmNsdWRlIDxic2QucHJvZy5taz4NCiANCmRpZmYgLS1naXQgYS9zeXMvYW1k NjQvaW5jbHVkZS9hY3BpY2FfbWFjaGRlcC5oIGIvc3lzL2FtZDY0L2luY2x1ZGUv YWNwaWNhX21hY2hkZXAuaA0KaW5kZXggOTk0M2FmNy4uMzkzY2QyYiAxMDA2NDQN Ci0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL2FjcGljYV9tYWNoZGVwLmgNCisrKyBi L3N5cy9hbWQ2NC9pbmNsdWRlL2FjcGljYV9tYWNoZGVwLmgNCkBAIC0zMyw2ICsz MywxMiBAQA0KICAqDQogICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLw0K IA0KKyNpZmRlZiBfX2kzODZfXw0KKw0KKyNpbmNsdWRlIDxpMzg2L2FjcGljYV9t YWNoZGVwLmg+DQorDQorI2Vsc2UgLyogX19pMzg2X18gKi8NCisNCiAjaWZuZGVm IF9fQUNQSUNBX01BQ0hERVBfSF9fDQogI2RlZmluZQlfX0FDUElDQV9NQUNIREVQ X0hfXw0KIA0KQEAgLTgyLDMgKzg4LDUgQEAgdm9pZAlhY3BpX3VubWFwX3RhYmxl KHZvaWQgKnRhYmxlKTsNCiB2bV9wYWRkcl90IGFjcGlfZmluZF90YWJsZShjb25z dCBjaGFyICpzaWcpOw0KIA0KICNlbmRpZiAvKiBfX0FDUElDQV9NQUNIREVQX0hf XyAqLw0KKw0KKyNlbmRpZiAvKiBfX2kzODZfXyAqLw0KZGlmZiAtLWdpdCBhL3N5 cy9hbWQ2NC9pbmNsdWRlL2FwaWN2YXIuaCBiL3N5cy9hbWQ2NC9pbmNsdWRlL2Fw aWN2YXIuaA0KaW5kZXggYWUyZjViOS4uMzM2OWZhMSAxMDA2NDQNCi0tLSBhL3N5 cy9hbWQ2NC9pbmNsdWRlL2FwaWN2YXIuaA0KKysrIGIvc3lzL2FtZDY0L2luY2x1 ZGUvYXBpY3Zhci5oDQpAQCAtMjksOCArMjksMTAgQEANCiAgKiAkRnJlZUJTRCQN CiAgKi8NCiANCi0jaWZuZGVmIF9NQUNISU5FX0FQSUNWQVJfSF8NCi0jZGVmaW5l IF9NQUNISU5FX0FQSUNWQVJfSF8NCisjaWZuZGVmIF9BTUQ2NF9BUElDVkFSX0hf DQorI2RlZmluZSBfQU1ENjRfQVBJQ1ZBUl9IXw0KKw0KKyNpZmRlZiBfX3g4Nl82 NF9fDQogDQogI2luY2x1ZGUgPG1hY2hpbmUvc2VnbWVudHMuaD4NCiANCkBAIC0y MjksNCArMjMxLDEwIEBAIHZvaWQJbGFwaWNfc2V0X3Rwcih1X2ludCB2ZWN0b3Ip Ow0KIHZvaWQJbGFwaWNfc2V0dXAoaW50IGJvb3QpOw0KIA0KICNlbmRpZiAvKiAh TE9DT1JFICovDQotI2VuZGlmIC8qIF9NQUNISU5FX0FQSUNWQVJfSF8gKi8NCisN CisjZWxzZSAvKiBfX3g4Nl82NF9fICovDQorDQorI2luY2x1ZGUgPGkzODYvYXBp Y3Zhci5oPg0KKw0KKyNlbmRpZiAvKiBfX3g4Nl82NF9fICovDQorI2VuZGlmIC8q IF9BTUQ2NF9BUElDVkFSX0hfICovDQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2lu Y2x1ZGUvYXNtLmggYi9zeXMvYW1kNjQvaW5jbHVkZS9hc20uaA0KaW5kZXggN2Vm ZDY0Mi4uYjFkZDhiYSAxMDA2NDQNCi0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL2Fz bS5oDQorKysgYi9zeXMvYW1kNjQvaW5jbHVkZS9hc20uaA0KQEAgLTMzLDggKzMz LDEwIEBADQogICogJEZyZWVCU0QkDQogICovDQogDQotI2lmbmRlZiBfTUFDSElO RV9BU01fSF8NCi0jZGVmaW5lCV9NQUNISU5FX0FTTV9IXw0KKyNpZm5kZWYgX0FN RDY0X0FTTV9IXw0KKyNkZWZpbmUJX0FNRDY0X0FTTV9IXw0KKw0KKyNpZmRlZiBf X3g4Nl82NF9fDQogDQogI2luY2x1ZGUgPHN5cy9jZGVmcy5oPg0KIA0KQEAgLTg4 LDQgKzkwLDkgQEANCiAjZGVmaW5lIF9fRkJTRElEKHMpCS8qIG5vdGhpbmcgKi8N CiAjZW5kaWYgLyogbm90IGxpbnQgYW5kIG5vdCBTVFJJUF9GQlNESUQgKi8NCiAN Ci0jZW5kaWYgLyogIV9NQUNISU5FX0FTTV9IXyAqLw0KKyNlbHNlIC8qIF9feDg2 XzY0X18gKi8NCisNCisjaW5jbHVkZSA8aTM4Ni9hc20uaD4NCisNCisjZW5kaWYg LyogX194ODZfNjRfXyAqLw0KKyNlbmRpZiAvKiAhX0FNRDY0X0FTTV9IXyAqLw0K ZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL2FzbWFjcm9zLmggYi9zeXMv YW1kNjQvaW5jbHVkZS9hc21hY3Jvcy5oDQppbmRleCAxZmI1OTJhLi4zODVlMTZl IDEwMDY0NA0KLS0tIGEvc3lzL2FtZDY0L2luY2x1ZGUvYXNtYWNyb3MuaA0KKysr IGIvc3lzL2FtZDY0L2luY2x1ZGUvYXNtYWNyb3MuaA0KQEAgLTI5LDggKzI5LDEw IEBADQogICogJEZyZWVCU0QkDQogICovDQogDQotI2lmbmRlZiBfTUFDSElORV9B U01BQ1JPU19IXw0KLSNkZWZpbmUgX01BQ0hJTkVfQVNNQUNST1NfSF8NCisjaWZu ZGVmIF9BTUQ2NF9BU01BQ1JPU19IXw0KKyNkZWZpbmUgX0FNRDY0X0FTTUFDUk9T X0hfDQorDQorI2lmZGVmIF9feDg2XzY0X18NCiANCiAjaW5jbHVkZSA8c3lzL2Nk ZWZzLmg+DQogDQpAQCAtMjAxLDQgKzIwMyw5IEBADQogDQogI2VuZGlmIC8qIExP Q09SRSAqLw0KIA0KLSNlbmRpZiAvKiAhX01BQ0hJTkVfQVNNQUNST1NfSF8gKi8N CisjZWxzZQ0KKw0KKyNpbmNsdWRlIDxpMzg2L2FzbWFjcm9zLmg+DQorDQorI2Vu ZGlmIC8qIF9feDg2XzY0X18gKi8NCisjZW5kaWYgLyogIV9BTUQ2NF9BU01BQ1JP U19IXyAqLw0KZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL2F0b21pYy5o IGIvc3lzL2FtZDY0L2luY2x1ZGUvYXRvbWljLmgNCmluZGV4IDk5YTk0YjcuLjMx ZmQ4ZWUgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS9hdG9taWMuaA0K KysrIGIvc3lzL2FtZDY0L2luY2x1ZGUvYXRvbWljLmgNCkBAIC0yNSw4ICsyNSwx MCBAQA0KICAqDQogICogJEZyZWVCU0QkDQogICovDQotI2lmbmRlZiBfTUFDSElO RV9BVE9NSUNfSF8NCi0jZGVmaW5lCV9NQUNISU5FX0FUT01JQ19IXw0KKyNpZm5k ZWYgX0FNRDY0X0FUT01JQ19IXw0KKyNkZWZpbmUJX0FNRDY0X0FUT01JQ19IXw0K Kw0KKyNpZmRlZiBfX3g4Nl82NF9fDQogDQogI2lmbmRlZiBfU1lTX0NERUZTX0hf DQogI2Vycm9yIHRoaXMgZmlsZSBuZWVkcyBzeXMvY2RlZnMuaCBhcyBhIHByZXJl cXVpc2l0ZQ0KQEAgLTQ4MCw0ICs0ODIsOSBAQCB1X2xvbmcJYXRvbWljX3JlYWRh bmRjbGVhcl9sb25nKHZvbGF0aWxlIHVfbG9uZyAqYWRkcik7DQogDQogI2VuZGlm IC8qICFXQU5UX0ZVTkNUSU9OUyAqLw0KIA0KLSNlbmRpZiAvKiAhX01BQ0hJTkVf QVRPTUlDX0hfICovDQorI2Vsc2UgLyogX194ODZfNjRfXyAqLw0KKw0KKyNpbmNs dWRlIDxpMzg2L2F0b21pYy5oPg0KKw0KKyNlbmRpZiAvKiBfX3g4Nl82NF9fICov DQorI2VuZGlmIC8qICFfQU1ENjRfQVRPTUlDX0hfICovDQpkaWZmIC0tZ2l0IGEv c3lzL2FtZDY0L2luY2x1ZGUvY2xvY2suaCBiL3N5cy9hbWQ2NC9pbmNsdWRlL2Ns b2NrLmgNCmluZGV4IGQyNjAyZDguLjlmMGRiNmUgMTAwNjQ0DQotLS0gYS9zeXMv YW1kNjQvaW5jbHVkZS9jbG9jay5oDQorKysgYi9zeXMvYW1kNjQvaW5jbHVkZS9j bG9jay5oDQpAQCAtNiw4ICs2LDEwIEBADQogICogJEZyZWVCU0QkDQogICovDQog DQotI2lmbmRlZiBfTUFDSElORV9DTE9DS19IXw0KLSNkZWZpbmUJX01BQ0hJTkVf Q0xPQ0tfSF8NCisjaWZuZGVmIF9BTUQ2NF9DTE9DS19IXw0KKyNkZWZpbmUJX0FN RDY0X0NMT0NLX0hfDQorDQorI2lmZGVmIF9feDg2XzY0X18NCiANCiAjaWZkZWYg X0tFUk5FTA0KIC8qDQpAQCAtMzcsNCArMzksOSBAQCB2b2lkCXRpbWVyX3Nwa3Jf c2V0ZnJlcShpbnQgZnJlcSk7DQogDQogI2VuZGlmIC8qIF9LRVJORUwgKi8NCiAN Ci0jZW5kaWYgLyogIV9NQUNISU5FX0NMT0NLX0hfICovDQorI2Vsc2UgLyogX194 ODZfNjRfXyAqLw0KKw0KKyNpbmNsdWRlIDxpMzg2L2Nsb2NrLmg+DQorDQorI2Vu ZGlmIC8qIF9feDg2XzY0X18gKi8NCisjZW5kaWYgLyogIV9BTUQ2NF9DTE9DS19I XyAqLw0KZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL2NwdS5oIGIvc3lz L2FtZDY0L2luY2x1ZGUvY3B1LmgNCmluZGV4IDFjMjg3MWYuLjBjZmNiMDMgMTAw NjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS9jcHUuaA0KKysrIGIvc3lzL2Ft ZDY0L2luY2x1ZGUvY3B1LmgNCkBAIC0zMyw4ICszMywxMCBAQA0KICAqICRGcmVl QlNEJA0KICAqLw0KIA0KLSNpZm5kZWYgX01BQ0hJTkVfQ1BVX0hfDQotI2RlZmlu ZQlfTUFDSElORV9DUFVfSF8NCisjaWZuZGVmIF9BTUQ2NF9DUFVfSF8NCisjZGVm aW5lCV9BTUQ2NF9DUFVfSF8NCisNCisjaWZkZWYgX194ODZfNjRfXw0KIA0KIC8q DQogICogRGVmaW5pdGlvbnMgdW5pcXVlIHRvIGkzODYgY3B1IHN1cHBvcnQuDQpA QCAtNzUsNCArNzcsOSBAQCBnZXRfY3ljbGVjb3VudCh2b2lkKQ0KIA0KICNlbmRp Zg0KIA0KLSNlbmRpZiAvKiAhX01BQ0hJTkVfQ1BVX0hfICovDQorI2Vsc2UgLyog X194ODZfNjRfXyAqLw0KKw0KKyNpbmNsdWRlIDxpMzg2L2NwdS5oPg0KKw0KKyNl bmRpZiAvKiBfX3g4Nl82NF9fICovDQorI2VuZGlmIC8qICFfQU1ENjRfQ1BVX0hf ICovDQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUvY3B1ZnVuYy5oIGIv c3lzL2FtZDY0L2luY2x1ZGUvY3B1ZnVuYy5oDQppbmRleCA4ODFmY2QyLi5iYWY5 MjdlIDEwMDY0NA0KLS0tIGEvc3lzL2FtZDY0L2luY2x1ZGUvY3B1ZnVuYy5oDQor KysgYi9zeXMvYW1kNjQvaW5jbHVkZS9jcHVmdW5jLmgNCkBAIC0zNiwxMyArMzYs MTUgQEANCiAgKiB1c2VkIGluIHByZWZlcmVuY2UgdG8gdGhpcy4NCiAgKi8NCiAN Ci0jaWZuZGVmIF9NQUNISU5FX0NQVUZVTkNfSF8NCi0jZGVmaW5lCV9NQUNISU5F X0NQVUZVTkNfSF8NCisjaWZuZGVmIF9BTUQ2NF9DUFVGVU5DX0hfDQorI2RlZmlu ZQlfQU1ENjRfQ1BVRlVOQ19IXw0KIA0KICNpZm5kZWYgX1NZU19DREVGU19IXw0K ICNlcnJvciB0aGlzIGZpbGUgbmVlZHMgc3lzL2NkZWZzLmggYXMgYSBwcmVyZXF1 aXNpdGUNCiAjZW5kaWYNCiANCisjaWZkZWYgX194ODZfNjRfXw0KKw0KIHN0cnVj dCByZWdpb25fZGVzY3JpcHRvcjsNCiANCiAjZGVmaW5lIHJlYWRiKHZhKQkoKih2 b2xhdGlsZSB1aW50OF90ICopICh2YSkpDQpAQCAtNzg4LDQgKzc5MCw5IEBAIGlu dAlyZG1zcl9zYWZlKHVfaW50IG1zciwgdWludDY0X3QgKnZhbCk7DQogaW50CXdy bXNyX3NhZmUodV9pbnQgbXNyLCB1aW50NjRfdCBuZXd2YWwpOw0KICNlbmRpZg0K IA0KLSNlbmRpZiAvKiAhX01BQ0hJTkVfQ1BVRlVOQ19IXyAqLw0KKyNlbHNlIC8q IF9feDg2XzY0X18gKi8NCisNCisjaW5jbHVkZSA8aTM4Ni9jcHVmdW5jLmg+DQor DQorI2VuZGlmIC8qIF9feDg2XzY0X18gKi8NCisjZW5kaWYgLyogIV9BTUQ2NF9D UFVGVU5DX0hfICovDQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUvY3B1 dHlwZXMuaCBiL3N5cy9hbWQ2NC9pbmNsdWRlL2NwdXR5cGVzLmgNCmluZGV4IGVl ZWM0ZTAuLmUyZjIzZWMgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS9j cHV0eXBlcy5oDQorKysgYi9zeXMvYW1kNjQvaW5jbHVkZS9jcHV0eXBlcy5oDQpA QCAtMjcsOCArMjcsMTAgQEANCiAgKiAkRnJlZUJTRCQNCiAgKi8NCiANCi0jaWZu ZGVmIF9NQUNISU5FX0NQVVRZUEVTX0hfDQotI2RlZmluZQlfTUFDSElORV9DUFVU WVBFU19IXw0KKyNpZm5kZWYgX0FNRDY0X0NQVVRZUEVTX0hfDQorI2RlZmluZQlf QU1ENjRfQ1BVVFlQRVNfSF8NCisNCisjaWZkZWYgX194ODZfNjRfXw0KIA0KIC8q DQogICogQ2xhc3NlcyBvZiBwcm9jZXNzb3IuDQpAQCAtNTYsNCArNTgsOSBAQCBl eHRlcm4gaW50CWNwdTsNCiBleHRlcm4gaW50CWNwdV9jbGFzczsNCiAjZW5kaWYN CiANCi0jZW5kaWYgLyogIV9NQUNISU5FX0NQVVRZUEVTX0hfICovDQorI2Vsc2Ug LyogX194ODZfNjRfXyAqLw0KKw0KKyNpbmNsdWRlIDxpMzg2L2NwdXR5cGVzLmg+ DQorDQorI2VuZGlmIC8qIF9feDg2XzY0X18gKi8NCisjZW5kaWYgLyogIV9BTUQ2 NF9DUFVUWVBFU19IXyAqLw0KZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRl L2RiX21hY2hkZXAuaCBiL3N5cy9hbWQ2NC9pbmNsdWRlL2RiX21hY2hkZXAuaA0K aW5kZXggMjllMzg1ZS4uYWU4ZTVkNiAxMDA2NDQNCi0tLSBhL3N5cy9hbWQ2NC9p bmNsdWRlL2RiX21hY2hkZXAuaA0KKysrIGIvc3lzL2FtZDY0L2luY2x1ZGUvZGJf bWFjaGRlcC5oDQpAQCAtMjYsOCArMjYsMTAgQEANCiAgKiAkRnJlZUJTRCQNCiAg Ki8NCiANCi0jaWZuZGVmIF9NQUNISU5FX0RCX01BQ0hERVBfSF8NCi0jZGVmaW5l CV9NQUNISU5FX0RCX01BQ0hERVBfSF8NCisjaWZuZGVmIF9BTUQ2NF9EQl9NQUNI REVQX0hfDQorI2RlZmluZQlfQU1ENjRfREJfTUFDSERFUF9IXw0KKw0KKyNpZmRl ZiBfX3g4Nl82NF9fDQogDQogI2luY2x1ZGUgPG1hY2hpbmUvZnJhbWUuaD4NCiAj aW5jbHVkZSA8bWFjaGluZS90cmFwLmg+DQpAQCAtOTEsNCArOTMsOSBAQCBkbyB7 CQkJCQkJXA0KICNkZWZpbmUJREJfU01BTExfVkFMVUVfTUFYCTB4N2ZmZmZmZmYN CiAjZGVmaW5lCURCX1NNQUxMX1ZBTFVFX01JTgkoLTB4NDAwMDAxKQ0KIA0KLSNl bmRpZiAvKiAhX01BQ0hJTkVfREJfTUFDSERFUF9IXyAqLw0KKyNlbHNlIC8qIF9f eDg2XzY0X18gKi8NCisNCisjaW5jbHVkZSA8aTM4Ni9kYl9tYWNoZGVwLmg+DQor DQorI2VuZGlmIC8qIF9feDg2XzY0X18gKi8NCisjZW5kaWYgLyogIV9BTUQ2NF9E Ql9NQUNIREVQX0hfICovDQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUv ZWxmLmggYi9zeXMvYW1kNjQvaW5jbHVkZS9lbGYuaA0KaW5kZXggZDY5YzZiNC4u ZGVlNDEwZSAxMDA2NDQNCi0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL2VsZi5oDQor KysgYi9zeXMvYW1kNjQvaW5jbHVkZS9lbGYuaA0KQEAgLTI2LDggKzI2LDEwIEBA DQogICogJEZyZWVCU0QkDQogICovDQogDQotI2lmbmRlZiBfTUFDSElORV9FTEZf SF8NCi0jZGVmaW5lCV9NQUNISU5FX0VMRl9IXyAxDQorI2lmbmRlZiBfQU1ENjRf RUxGX0hfDQorI2RlZmluZQlfQU1ENjRfRUxGX0hfIDENCisNCisjaWZkZWYgX194 ODZfNjRfXw0KIA0KIC8qDQogICogRUxGIGRlZmluaXRpb25zIGZvciB0aGUgQU1E NjQgYXJjaGl0ZWN0dXJlLg0KQEAgLTQ0LDcgKzQ2LDcgQEANCiAjZGVmaW5lCUVM Rl9BUkNICUVNX1g4Nl82NA0KICNkZWZpbmUJRUxGX0FSQ0gzMglFTV8zODYNCiAN Ci0jZGVmaW5lCUVMRl9NQUNISU5FX09LKHgpICgoeCkgPT0gRU1fWDg2XzY0KQ0K KyNkZWZpbmUJRUxGX0FNRDY0X09LKHgpICgoeCkgPT0gRU1fWDg2XzY0KQ0KIA0K IC8qDQogICogQXV4aWxpYXJ5IHZlY3RvciBlbnRyaWVzIGZvciBwYXNzaW5nIGlu Zm9ybWF0aW9uIHRvIHRoZSBpbnRlcnByZXRlci4NCkBAIC0xMjEsNCArMTIzLDkg QEAgX19FbGZUeXBlKEF1eGluZm8pOw0KICNkZWZpbmUJRVRfRFlOX0xPQURfQURE UiAweDAxMDIxMDAwDQogI2VuZGlmDQogDQotI2VuZGlmIC8qICFfTUFDSElORV9F TEZfSF8gKi8NCisjZWxzZSAvKiBfX3g4Nl82NF9fICovDQorDQorI2luY2x1ZGUg PGkzODYvZWxmLmg+DQorDQorI2VuZGlmIC8qIF9feDg2XzY0X18gKi8NCisjZW5k aWYgLyogIV9BTUQ2NF9FTEZfSF8gKi8NCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQv aW5jbHVkZS9leGVjLmggYi9zeXMvYW1kNjQvaW5jbHVkZS9leGVjLmgNCmluZGV4 IDhkMDc4ODcuLjBhMzFjOTUgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVk ZS9leGVjLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRlL2V4ZWMuaA0KQEAgLTMw LDkgKzMwLDE2IEBADQogICogJEZyZWVCU0QkDQogICovDQogDQotI2lmbmRlZglf TUFDSElORV9FWEVDX0hfDQotI2RlZmluZQlfTUFDSElORV9FWEVDX0hfDQorI2lm bmRlZglfQU1ENjRfRVhFQ19IXw0KKyNkZWZpbmUJX0FNRDY0X0VYRUNfSF8NCisN CisjaWZkZWYgX194ODZfNjRfXw0KIA0KICNkZWZpbmUJX19MRFBHU1oJNDA5Ng0K IA0KLSNlbmRpZiAvKiAhX01BQ0hJTkVfRVhFQ19IXyAqLw0KKyNlbHNlIC8qIF9f eDg2XzY0X18gKi8NCisNCisjaW5jbHVkZSA8aTM4Ni9leGVjLmg+DQorDQorI2Vu ZGlmIC8qIF9feDg2XzY0X18gKi8NCisjZW5kaWYgLyogIV9BTUQ2NF9FWEVDX0hf ICovDQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUvZnB1LmggYi9zeXMv YW1kNjQvaW5jbHVkZS9mcHUuaA0KaW5kZXggN2QwZjBlYS4uN2Q1MzE4YSAxMDA2 NDQNCi0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL2ZwdS5oDQorKysgYi9zeXMvYW1k NjQvaW5jbHVkZS9mcHUuaA0KQEAgLTM4LDggKzM4LDggQEANCiAgKiBXLiBKb2xp dHogMS85MA0KICAqLw0KIA0KLSNpZm5kZWYgX01BQ0hJTkVfRlBVX0hfDQotI2Rl ZmluZQlfTUFDSElORV9GUFVfSF8NCisjaWZuZGVmIF9BTUQ2NF9GUFVfSF8NCisj ZGVmaW5lCV9BTUQ2NF9GUFVfSF8NCiANCiAjaW5jbHVkZSA8eDg2L2ZwdS5oPg0K IA0KQEAgLTgxLDQgKzgxLDQgQEAgaW50CWlzX2ZwdV9rZXJuX3RocmVhZCh1X2lu dCBmbGFncyk7DQogDQogI2VuZGlmDQogDQotI2VuZGlmIC8qICFfTUFDSElORV9G UFVfSF8gKi8NCisjZW5kaWYgLyogIV9BTUQ2NF9GUFVfSF8gKi8NCmRpZmYgLS1n aXQgYS9zeXMvYW1kNjQvaW5jbHVkZS9mcmFtZS5oIGIvc3lzL2FtZDY0L2luY2x1 ZGUvZnJhbWUuaA0KaW5kZXggZTE3MTQwNy4uZTlmYjNkOCAxMDA2NDQNCi0tLSBh L3N5cy9hbWQ2NC9pbmNsdWRlL2ZyYW1lLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNs dWRlL2ZyYW1lLmgNCkBAIC0zNCw4ICszNCwxMCBAQA0KICAqICRGcmVlQlNEJA0K ICAqLw0KIA0KLSNpZm5kZWYgX01BQ0hJTkVfRlJBTUVfSF8NCi0jZGVmaW5lIF9N QUNISU5FX0ZSQU1FX0hfIDENCisjaWZuZGVmIF9BTUQ2NF9GUkFNRV9IXw0KKyNk ZWZpbmUgX0FNRDY0X0ZSQU1FX0hfIDENCisNCisjaWZkZWYgX194ODZfNjRfXw0K IA0KIC8qDQogICogU3lzdGVtIHN0YWNrIGZyYW1lcy4NCkBAIC04NCw0ICs4Niw5 IEBAIHN0cnVjdCB0cmFwZnJhbWUgew0KICNkZWZpbmUJVEZfSEFTQkFTRVMJMHgy DQogI2RlZmluZQlURl9IQVNGUFhTVEFURQkweDQNCiANCi0jZW5kaWYgLyogX01B Q0hJTkVfRlJBTUVfSF8gKi8NCisjZWxzZSAvKiBfX3g4Nl82NF9fICovDQorDQor I2luY2x1ZGUgPGkzODYvZnJhbWUuaD4NCisNCisjZW5kaWYgLyogX194ODZfNjRf XyAqLw0KKyNlbmRpZiAvKiBfQU1ENjRfRlJBTUVfSF8gKi8NCmRpZmYgLS1naXQg YS9zeXMvYW1kNjQvaW5jbHVkZS9nZGJfbWFjaGRlcC5oIGIvc3lzL2FtZDY0L2lu Y2x1ZGUvZ2RiX21hY2hkZXAuaA0KaW5kZXggZDhjMjViOS4uZjEyNzRjYSAxMDA2 NDQNCi0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL2dkYl9tYWNoZGVwLmgNCisrKyBi L3N5cy9hbWQ2NC9pbmNsdWRlL2dkYl9tYWNoZGVwLmgNCkBAIC0yNiw4ICsyNiwx MCBAQA0KICAqICRGcmVlQlNEJA0KICAqLw0KIA0KLSNpZm5kZWYgX01BQ0hJTkVf R0RCX01BQ0hERVBfSF8NCi0jZGVmaW5lCV9NQUNISU5FX0dEQl9NQUNIREVQX0hf DQorI2lmbmRlZiBfQU1ENjRfR0RCX01BQ0hERVBfSF8NCisjZGVmaW5lCV9BTUQ2 NF9HREJfTUFDSERFUF9IXw0KKw0KKyNpZmRlZiBfX3g4Nl82NF9fDQogDQogI2Rl ZmluZQlHREJfQlVGU1oJKEdEQl9OUkVHUyAqIDE2KQ0KICNkZWZpbmUJR0RCX05S RUdTCTU2DQpAQCAtNDksNCArNTEsOSBAQCB2b2lkICpnZGJfY3B1X2dldHJlZyhp bnQsIHNpemVfdCAqKTsNCiB2b2lkIGdkYl9jcHVfc2V0cmVnKGludCwgdm9pZCAq KTsNCiBpbnQgZ2RiX2NwdV9zaWduYWwoaW50LCBpbnQpOw0KIA0KLSNlbmRpZiAv KiAhX01BQ0hJTkVfR0RCX01BQ0hERVBfSF8gKi8NCisjZWxzZSAvKiBfX3g4Nl82 NF9fICovDQorDQorI2luY2x1ZGUgPGkzODYvZ2RiX21hY2hkZXAuaD4NCisNCisj ZW5kaWYgLyogX194ODZfNjRfXyAqLw0KKyNlbmRpZiAvKiAhX0FNRDY0X0dEQl9N QUNIREVQX0hfICovDQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUvaWVl ZWZwLmggYi9zeXMvYW1kNjQvaW5jbHVkZS9pZWVlZnAuaA0KaW5kZXggYTQwMzY2 MC4uMzM3ODlmOSAxMDA2NDQNCi0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL2llZWVm cC5oDQorKysgYi9zeXMvYW1kNjQvaW5jbHVkZS9pZWVlZnAuaA0KQEAgLTM1LDgg KzM1LDggQEANCiAgKiAkRnJlZUJTRCQNCiAgKi8NCiANCi0jaWZuZGVmIF9NQUNI SU5FX0lFRUVGUF9IXw0KLSNkZWZpbmUgX01BQ0hJTkVfSUVFRUZQX0hfDQorI2lm bmRlZiBfQU1ENjRfSUVFRUZQX0hfDQorI2RlZmluZSBfQU1ENjRfSUVFRUZQX0hf DQogDQogLyoNCiAgKiBEZXByZWNhdGVkIGhpc3RvcmljYWwgRlBVIGNvbnRyb2wg aW50ZXJmYWNlDQpAQCAtNDksNiArNDksOCBAQA0KICNlcnJvciB0aGlzIGZpbGUg bmVlZHMgc3lzL2NkZWZzLmggYXMgYSBwcmVyZXF1aXNpdGUNCiAjZW5kaWYNCiAN CisjaWZkZWYgX194ODZfNjRfXw0KKw0KIC8qDQogICogUm91bmRpbmcgbW9kZXMu DQogICovDQpAQCAtMzA1LDQgKzMwNyw5IEBAIF9fRU5EX0RFQ0xTDQogDQogI2Vu ZGlmIC8qICFfX0lFRUVGUF9OT0lOTElORVNfXyAmJiBfX0dOVUNMSUtFX0FTTSAq Lw0KIA0KLSNlbmRpZiAvKiAhX01BQ0hJTkVfSUVFRUZQX0hfICovDQorI2Vsc2Ug LyogX194ODZfNjRfXyAqLw0KKw0KKyNpbmNsdWRlIDxpMzg2L2llZWVmcC5oPg0K Kw0KKyNlbmRpZg0KKyNlbmRpZiAvKiAhX0FNRDY0X0lFRUVGUF9IXyAqLw0KZGlm ZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL2luX2Nrc3VtLmggYi9zeXMvYW1k NjQvaW5jbHVkZS9pbl9ja3N1bS5oDQppbmRleCAxNTYwMzVlLi41OWQyMDlkIDEw MDY0NA0KLS0tIGEvc3lzL2FtZDY0L2luY2x1ZGUvaW5fY2tzdW0uaA0KKysrIGIv c3lzL2FtZDY0L2luY2x1ZGUvaW5fY2tzdW0uaA0KQEAgLTMyLDEzICszMiwxNSBA QA0KICAqICRGcmVlQlNEJA0KICAqLw0KIA0KLSNpZm5kZWYgX01BQ0hJTkVfSU5f Q0tTVU1fSF8NCi0jZGVmaW5lCV9NQUNISU5FX0lOX0NLU1VNX0hfCTENCisjaWZu ZGVmIF9BTUQ2NF9JTl9DS1NVTV9IXw0KKyNkZWZpbmUJX0FNRDY0X0lOX0NLU1VN X0hfCTENCiANCiAjaWZuZGVmIF9TWVNfQ0RFRlNfSF8NCiAjZXJyb3IgdGhpcyBm aWxlIG5lZWRzIHN5cy9jZGVmcy5oIGFzIGEgcHJlcmVxdWlzaXRlDQogI2VuZGlm DQogDQorI2lmZGVmIF9feDg2XzY0X18NCisNCiAjaW5jbHVkZSA8c3lzL2NkZWZz Lmg+DQogDQogI2RlZmluZSBpbl9ja3N1bShtLCBsZW4pCWluX2Nrc3VtX3NraXAo bSwgbGVuLCAwKQ0KQEAgLTgxLDQgKzgzLDkgQEAgdV9zaG9ydAlpbl9wc2V1ZG8o dV9pbnQgc3VtLCB1X2ludCBiLCB1X2ludCBjKTsNCiB1X3Nob3J0CWluX2Nrc3Vt X3NraXAoc3RydWN0IG1idWYgKm0sIGludCBsZW4sIGludCBza2lwKTsNCiAjZW5k aWYNCiANCi0jZW5kaWYgLyogX01BQ0hJTkVfSU5fQ0tTVU1fSF8gKi8NCisjZWxz ZSAvKiBfX3g4Nl82NF9fICovDQorDQorI2luY2x1ZGUgPGkzODYvaW5fY2tzdW0u aD4NCisNCisjZW5kaWYgLyogX194ODZfNjRfXyAqLw0KKyNlbmRpZiAvKiBfQU1E NjRfSU5fQ0tTVU1fSF8gKi8NCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQvaW5jbHVk ZS9pbnRyX21hY2hkZXAuaCBiL3N5cy9hbWQ2NC9pbmNsdWRlL2ludHJfbWFjaGRl cC5oDQppbmRleCA5ZDA2NmIxLi4wZmJhZmUyIDEwMDY0NA0KLS0tIGEvc3lzL2Ft ZDY0L2luY2x1ZGUvaW50cl9tYWNoZGVwLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNs dWRlL2ludHJfbWFjaGRlcC5oDQpAQCAtMjYsOCArMjYsMTQgQEANCiAgKiAkRnJl ZUJTRCQNCiAgKi8NCiANCi0jaWZuZGVmIF9fTUFDSElORV9JTlRSX01BQ0hERVBf SF9fDQotI2RlZmluZQlfX01BQ0hJTkVfSU5UUl9NQUNIREVQX0hfXw0KKyNpZm5k ZWYgX19BTUQ2NF9JTlRSX01BQ0hERVBfSF9fDQorI2RlZmluZQlfX0FNRDY0X0lO VFJfTUFDSERFUF9IX18NCisNCisjaWZuZGVmIF9feDg2XzY0X18NCisNCisjaW5j bHVkZSA8aTM4Ni9pbnRyX21hY2hkZXAuaD4NCisNCisjZWxzZQ0KIA0KICNpZmRl ZiBfS0VSTkVMDQogDQpAQCAtMTY5LDQgKzE3NSw1IEBAIGludAltc2l4X3JlbGVh c2UoaW50IGlycSk7DQogDQogI2VuZGlmCS8qICFMT0NPUkUgKi8NCiAjZW5kaWYJ LyogX0tFUk5FTCAqLw0KLSNlbmRpZgkvKiAhX19NQUNISU5FX0lOVFJfTUFDSERF UF9IX18gKi8NCisjZW5kaWYJLyogIV9feDg2XzY0X18gKi8NCisjZW5kaWYJLyog IV9fQU1ENjRfSU5UUl9NQUNIREVQX0hfXyAqLw0KZGlmZiAtLWdpdCBhL3N5cy9h bWQ2NC9pbmNsdWRlL2tkYi5oIGIvc3lzL2FtZDY0L2luY2x1ZGUva2RiLmgNCmlu ZGV4IDU2ZDIwMTguLjJkYTQ0OGQgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5j bHVkZS9rZGIuaA0KKysrIGIvc3lzL2FtZDY0L2luY2x1ZGUva2RiLmgNCkBAIC0y Niw2ICsyNiwxMiBAQA0KICAqICRGcmVlQlNEJA0KICAqLw0KIA0KKyNpZmRlZiBf X2kzODZfXw0KKw0KKyNpbmNsdWRlIDxpMzg2L2tkYi5oPg0KKw0KKyNlbHNlDQor DQogI2lmbmRlZiBfTUFDSElORV9LREJfSF8NCiAjZGVmaW5lIF9NQUNISU5FX0tE Ql9IXw0KIA0KQEAgLTU3LDMgKzYzLDQgQEAga2RiX2NwdV90cmFwKGludCB0eXBl LCBpbnQgY29kZSkNCiB9DQogDQogI2VuZGlmIC8qIF9NQUNISU5FX0tEQl9IXyAq Lw0KKyNlbmRpZiAvKiBfX2kzODZfXyAqLw0KZGlmZiAtLWdpdCBhL3N5cy9hbWQ2 NC9pbmNsdWRlL21kX3Zhci5oIGIvc3lzL2FtZDY0L2luY2x1ZGUvbWRfdmFyLmgN CmluZGV4IGZmMzIyYmIuLmM0NzY1ZWEgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQv aW5jbHVkZS9tZF92YXIuaA0KKysrIGIvc3lzL2FtZDY0L2luY2x1ZGUvbWRfdmFy LmgNCkBAIC0yOSw2ICsyOSwxMiBAQA0KICAqICRGcmVlQlNEJA0KICAqLw0KIA0K KyNpZm5kZWYgX194ODZfNjRfXw0KKw0KKyNpbmNsdWRlIDxpMzg2L21kX3Zhci5o Pg0KKw0KKyNlbHNlDQorDQogI2lmbmRlZiBfTUFDSElORV9NRF9WQVJfSF8NCiAj ZGVmaW5lCV9NQUNISU5FX01EX1ZBUl9IXw0KIA0KQEAgLTExOCwzICsxMjQsNCBA QCBzdHJ1Y3Qgc2F2ZWZwdSAqZ2V0X3BjYl91c2VyX3NhdmVfcGNiKHN0cnVjdCBw Y2IgKnBjYik7DQogc3RydWN0IHBjYiAqZ2V0X3BjYl90ZChzdHJ1Y3QgdGhyZWFk ICp0ZCk7DQogDQogI2VuZGlmIC8qICFfTUFDSElORV9NRF9WQVJfSF8gKi8NCisj ZW5kaWYgLyogIV9feDg2XzY0X18gKi8NCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQv aW5jbHVkZS9taW5pZHVtcC5oIGIvc3lzL2FtZDY0L2luY2x1ZGUvbWluaWR1bXAu aA0KaW5kZXggMmFjNTI5Yy4uZWE1MTliYSAxMDA2NDQNCi0tLSBhL3N5cy9hbWQ2 NC9pbmNsdWRlL21pbmlkdW1wLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRlL21p bmlkdW1wLmgNCkBAIC0yNiw2ICsyNiwxMiBAQA0KICAqICRGcmVlQlNEJA0KICAq Lw0KIA0KKyNpZm5kZWYgX194ODZfNjRfXw0KKw0KKyNpbmNsdWRlIDxpMzg2L21p bmlkdW1wLmg+DQorDQorI2Vsc2UNCisNCiAjaWZuZGVmCV9NQUNISU5FX01JTklE VU1QX0hfDQogI2RlZmluZQlfTUFDSElORV9NSU5JRFVNUF9IXyAxDQogDQpAQCAt NDQsMyArNTAsNCBAQCBzdHJ1Y3QgbWluaWR1bXBoZHIgew0KIH07DQogDQogI2Vu ZGlmIC8qIF9NQUNISU5FX01JTklEVU1QX0hfICovDQorI2VuZGlmIC8qICFfX3g4 Nl82NF9fICovDQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUvcGFyYW0u aCBiL3N5cy9hbWQ2NC9pbmNsdWRlL3BhcmFtLmgNCmluZGV4IDlkZGNmNjguLmM0 NjRhZjQgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS9wYXJhbS5oDQor KysgYi9zeXMvYW1kNjQvaW5jbHVkZS9wYXJhbS5oDQpAQCAtNDAsOCArNDAsMTEg QEANCiAgKi8NCiANCiANCi0jaWZuZGVmIF9BTUQ2NF9JTkNMVURFX1BBUkFNX0hf DQotI2RlZmluZQlfQU1ENjRfSU5DTFVERV9QQVJBTV9IXw0KKyNpZm5kZWYgX194 ODZfNjRfXw0KKyNpbmNsdWRlIDxpMzg2L3BhcmFtLmg+DQorI2Vsc2UNCisjaWZu ZGVmIF9NQUNISU5FX0lOQ0xVREVfUEFSQU1fSF8NCisjZGVmaW5lCV9NQUNISU5F X0lOQ0xVREVfUEFSQU1fSF8NCiANCiAjaW5jbHVkZSA8bWFjaGluZS9fYWxpZ24u aD4NCiANCkBAIC0xMzksNCArMTQyLDUgQEANCiANCiAjZGVmaW5lCXBndG9rKHgp CSgodW5zaWduZWQgbG9uZykoeCkgKiAoUEFHRV9TSVpFIC8gMTAyNCkpIA0KIA0K LSNlbmRpZiAvKiAhX0FNRDY0X0lOQ0xVREVfUEFSQU1fSF8gKi8NCisjZW5kaWYg LyogIV9NQUNISU5FX0lOQ0xVREVfUEFSQU1fSF8gKi8NCisjZW5kaWYgLyogIV9f eDg2XzY0X18gKi8NCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQvaW5jbHVkZS9wYy9i aW9zLmggYi9zeXMvYW1kNjQvaW5jbHVkZS9wYy9iaW9zLmgNCmluZGV4IDM2NGY4 NmMuLjAyZThjOWMgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS9wYy9i aW9zLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRlL3BjL2Jpb3MuaA0KQEAgLTI3 LDYgKzI3LDEwIEBADQogICogJEZyZWVCU0QkDQogICovDQogDQorI2lmbmRlZiBf X3g4Nl82NF9fDQorI2luY2x1ZGUgPGkzODYvcGMvYmlvcy5oPg0KKyNlbHNlDQor DQogI2lmbmRlZiBfTUFDSElORV9QQ19CSU9TX0hfDQogI2RlZmluZSBfTUFDSElO RV9QQ19CSU9TX0hfDQogDQpAQCAtNzcsMyArODEsNCBAQCBiaW9zX29lbV9zdHJp bmdzKHN0cnVjdCBiaW9zX29lbSAqb2VtLCB1X2NoYXIgKmJ1ZmZlciwgc2l6ZV90 IG1heGxlbik7DQogDQogDQogI2VuZGlmIC8qIF9NQUNISU5FX1BDX0JJT1NfSF8g Ki8NCisjZW5kaWYgLyogIV9feDg2XzY0X18gKi8NCmRpZmYgLS1naXQgYS9zeXMv YW1kNjQvaW5jbHVkZS9wY2IuaCBiL3N5cy9hbWQ2NC9pbmNsdWRlL3BjYi5oDQpp bmRleCAyMmNiYmUyLi5kNDVhMWZmIDEwMDY0NA0KLS0tIGEvc3lzL2FtZDY0L2lu Y2x1ZGUvcGNiLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRlL3BjYi5oDQpAQCAt MzQsOCArMzQsMTQgQEANCiAgKiAkRnJlZUJTRCQNCiAgKi8NCiANCi0jaWZuZGVm IF9BTUQ2NF9QQ0JfSF8NCi0jZGVmaW5lIF9BTUQ2NF9QQ0JfSF8NCisjaWZuZGVm IF9feDg2XzY0X18NCisNCisjaW5jbHVkZSA8aTM4Ni9wY2IuaD4NCisNCisjZWxz ZQ0KKw0KKyNpZm5kZWYgX01BQ0hJTkVfUENCX0hfDQorI2RlZmluZSBfTUFDSElO RV9QQ0JfSF8NCiANCiAvKg0KICAqIEFNRDY0IHByb2Nlc3MgY29udHJvbCBibG9j aw0KQEAgLTE0Niw0ICsxNTIsNSBAQCB2b2lkCXJlc3VtZWN0eChzdHJ1Y3QgcGNi ICopOw0KIA0KICNlbmRpZg0KIA0KLSNlbmRpZiAvKiBfQU1ENjRfUENCX0hfICov DQorI2VuZGlmIC8qIF9NQUNISU5FX1BDQl9IXyAqLw0KKyNlbmRpZiAvKiAhX194 ODZfNjRfXyAqLw0KZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL3BjcHUu aCBiL3N5cy9hbWQ2NC9pbmNsdWRlL3BjcHUuaA0KaW5kZXggMjE4ODQ0Mi4uNzYz ZmY5YiAxMDA2NDQNCi0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL3BjcHUuaA0KKysr IGIvc3lzL2FtZDY0L2luY2x1ZGUvcGNwdS5oDQpAQCAtMjYsMTMgKzI2LDE1IEBA DQogICogJEZyZWVCU0QkDQogICovDQogDQotI2lmbmRlZiBfTUFDSElORV9QQ1BV X0hfDQotI2RlZmluZQlfTUFDSElORV9QQ1BVX0hfDQorI2lmbmRlZiBfQU1ENjRf UENQVV9IXw0KKyNkZWZpbmUJX0FNRDY0X1BDUFVfSF8NCiANCiAjaWZuZGVmIF9T WVNfQ0RFRlNfSF8NCiAjZXJyb3IgInN5cy9jZGVmcy5oIGlzIGEgcHJlcmVxdWlz aXRlIGZvciB0aGlzIGZpbGUiDQogI2VuZGlmDQogDQorI2lmZGVmIF9feDg2XzY0 X18NCisNCiAjaWYgZGVmaW5lZChYRU4pIHx8IGRlZmluZWQoWEVOSFZNKQ0KICNp Zm5kZWYgTlJfVklSUVMNCiAjZGVmaW5lCU5SX1ZJUlFTCTI0DQpAQCAtMjU2LDQg KzI1OCw5IEBAIF9fY3VycGNiKHZvaWQpDQogDQogI2VuZGlmIC8qIF9LRVJORUwg Ki8NCiANCi0jZW5kaWYgLyogIV9NQUNISU5FX1BDUFVfSF8gKi8NCisjZWxzZSAg LyogX194ODZfNjRfXyAqLw0KKw0KKyNpbmNsdWRlIDxpMzg2L3BjcHUuaD4NCisN CisjZW5kaWYgLyogX194ODZfNjRfXyAqLw0KKyNlbmRpZiAvKiAhX0FNRDY0X1BD UFVfSF8gKi8NCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQvaW5jbHVkZS9wbWFwLmgg Yi9zeXMvYW1kNjQvaW5jbHVkZS9wbWFwLmgNCmluZGV4IDcxMDQ1YWUuLjk0YTcy NGEgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS9wbWFwLmgNCisrKyBi L3N5cy9hbWQ2NC9pbmNsdWRlL3BtYXAuaA0KQEAgLTQyLDYgKzQyLDEyIEBADQog ICogJEZyZWVCU0QkDQogICovDQogDQorI2lmbmRlZiBfX3g4Nl82NF9fDQorDQor I2luY2x1ZGUgPGkzODYvcG1hcC5oPg0KKw0KKyNlbHNlIC8qIF9feDg2XzY0X18g Ki8NCisNCiAjaWZuZGVmIF9NQUNISU5FX1BNQVBfSF8NCiAjZGVmaW5lCV9NQUNI SU5FX1BNQVBfSF8NCiANCkBAIC0zMzgsMyArMzQ0LDUgQEAgdm9pZAlwbWFwX2lu dmFsaWRhdGVfY2FjaGVfcmFuZ2Uodm1fb2Zmc2V0X3Qgc3ZhLCB2bV9vZmZzZXRf dCBldmEpOw0KICNlbmRpZiAvKiAhTE9DT1JFICovDQogDQogI2VuZGlmIC8qICFf TUFDSElORV9QTUFQX0hfICovDQorDQorI2VuZGlmIC8qICFfX3g4Nl82NF9fICov DQpkaWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUvcHJvYy5oIGIvc3lzL2Ft ZDY0L2luY2x1ZGUvcHJvYy5oDQppbmRleCAxNDU4NWZiLi5mMDgyM2FiIDEwMDY0 NA0KLS0tIGEvc3lzL2FtZDY0L2luY2x1ZGUvcHJvYy5oDQorKysgYi9zeXMvYW1k NjQvaW5jbHVkZS9wcm9jLmgNCkBAIC0zMCw2ICszMCwxMiBAQA0KICAqICRGcmVl QlNEJA0KICAqLw0KIA0KKyNpZm5kZWYgX194ODZfNjRfXw0KKw0KKyNpbmNsdWRl IDxpMzg2L3Byb2MuaD4NCisNCisjZWxzZSAvKiBfX3g4Nl82NF9fICovDQorDQog I2lmbmRlZiBfTUFDSElORV9QUk9DX0hfDQogI2RlZmluZQlfTUFDSElORV9QUk9D X0hfDQogDQpAQCAtODksMyArOTUsNCBAQCBzdHJ1Y3Qgc3lzY2FsbF9hcmdzIHsN CiAjZW5kaWYgIC8qIF9LRVJORUwgKi8NCiANCiAjZW5kaWYgLyogIV9NQUNISU5F X1BST0NfSF8gKi8NCisjZW5kaWYgLyogIV9feDg2XzY0X18gKi8NCmRpZmYgLS1n aXQgYS9zeXMvYW1kNjQvaW5jbHVkZS9ydW5xLmggYi9zeXMvYW1kNjQvaW5jbHVk ZS9ydW5xLmgNCmluZGV4IDg1NWUzMTUuLjAwNGIzMDAgMTAwNjQ0DQotLS0gYS9z eXMvYW1kNjQvaW5jbHVkZS9ydW5xLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRl L3J1bnEuaA0KQEAgLTI2LDYgKzI2LDEwIEBADQogICogJEZyZWVCU0QkDQogICov DQogDQorI2lmbmRlZiBfX3g4Nl82NF9fDQorI2luY2x1ZGUgPGkzODYvcnVucS5o Pg0KKyNlbHNlDQorDQogI2lmbmRlZglfTUFDSElORV9SVU5RX0hfDQogI2RlZmlu ZQlfTUFDSElORV9SVU5RX0hfDQogDQpAQCAtNDQsMyArNDgsNCBAQA0KIHR5cGVk ZWYJdV9pbnQ2NF90CXJxYl93b3JkX3Q7DQogDQogI2VuZGlmDQorI2VuZGlmDQpk aWZmIC0tZ2l0IGEvc3lzL2FtZDY0L2luY2x1ZGUvc2VnbWVudHMuaCBiL3N5cy9h bWQ2NC9pbmNsdWRlL3NlZ21lbnRzLmgNCmluZGV4IGQ5ZjQyODAuLjA3NmM1YWMg MTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS9zZWdtZW50cy5oDQorKysg Yi9zeXMvYW1kNjQvaW5jbHVkZS9zZWdtZW50cy5oDQpAQCAtMzQsNiArMzQsMTAg QEANCiAgKiAkRnJlZUJTRCQNCiAgKi8NCiANCisjaWZuZGVmIF9feDg2XzY0X18N CisjaW5jbHVkZSA8aTM4Ni9zZWdtZW50cy5oPg0KKyNlbHNlDQorDQogI2lmbmRl ZiBfTUFDSElORV9TRUdNRU5UU19IXw0KICNkZWZpbmUJX01BQ0hJTkVfU0VHTUVO VFNfSF8NCiANCkBAIC0xMDQsMyArMTA4LDQgQEAgdm9pZAl1cGRhdGVfZ2R0X2Zz YmFzZShzdHJ1Y3QgdGhyZWFkICp0ZCwgdWludDMyX3QgYmFzZSk7DQogI2VuZGlm IC8qIF9LRVJORUwgKi8NCiANCiAjZW5kaWYgLyogIV9NQUNISU5FX1NFR01FTlRT X0hfICovDQorI2VuZGlmIC8qICFfX3g4Nl82NF9fICovDQpkaWZmIC0tZ2l0IGEv c3lzL2FtZDY0L2luY2x1ZGUvc2ZfYnVmLmggYi9zeXMvYW1kNjQvaW5jbHVkZS9z Zl9idWYuaA0KaW5kZXggYjUyNDVlNi4uNDgyYjNkYSAxMDA2NDQNCi0tLSBhL3N5 cy9hbWQ2NC9pbmNsdWRlL3NmX2J1Zi5oDQorKysgYi9zeXMvYW1kNjQvaW5jbHVk ZS9zZl9idWYuaA0KQEAgLTI2LDYgKzI2LDEwIEBADQogICogJEZyZWVCU0QkDQog ICovDQogDQorI2lmbmRlZiBfX3g4Nl82NF9fDQorI2luY2x1ZGUgPGkzODYvc2Zf YnVmLmg+DQorI2Vsc2UNCisNCiAjaWZuZGVmIF9NQUNISU5FX1NGX0JVRl9IXw0K ICNkZWZpbmUgX01BQ0hJTkVfU0ZfQlVGX0hfDQogDQpAQCAtNTYsMyArNjAsNCBA QCBzZl9idWZfcGFnZShzdHJ1Y3Qgc2ZfYnVmICpzZikNCiB9DQogDQogI2VuZGlm IC8qICFfTUFDSElORV9TRl9CVUZfSF8gKi8NCisjZW5kaWYgLyogIV9feDg2XzY0 X18gKi8NCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQvaW5jbHVkZS9zaWdmcmFtZS5o IGIvc3lzL2FtZDY0L2luY2x1ZGUvc2lnZnJhbWUuaA0KaW5kZXggZDEwNDUwNy4u OGFjZjBiOCAxMDA2NDQNCi0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL3NpZ2ZyYW1l LmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRlL3NpZ2ZyYW1lLmgNCkBAIC0yOCw2 ICsyOCwxMCBAQA0KICAqICRGcmVlQlNEJA0KICAqLw0KIA0KKyNpZm5kZWYgX194 ODZfNjRfXw0KKyNpbmNsdWRlIDxpMzg2L3NpZ2ZyYW1lLmg+DQorI2Vsc2UNCisN CiAjaWZuZGVmIF9NQUNISU5FX1NJR0ZSQU1FX0hfDQogI2RlZmluZQlfTUFDSElO RV9TSUdGUkFNRV9IXw0KIA0KQEAgLTQ0LDMgKzQ4LDQgQEAgc3RydWN0IHNpZ2Zy YW1lIHsNCiB9Ow0KIA0KICNlbmRpZiAvKiAhX01BQ0hJTkVfU0lHRlJBTUVfSF8g Ki8NCisjZW5kaWYgLyogIV9feDg2XzY0X18gKi8NCmRpZmYgLS1naXQgYS9zeXMv YW1kNjQvaW5jbHVkZS9zaWduYWwuaCBiL3N5cy9hbWQ2NC9pbmNsdWRlL3NpZ25h bC5oDQppbmRleCAwODVkNDNhLi43NmQ3MDE4IDEwMDY0NA0KLS0tIGEvc3lzL2Ft ZDY0L2luY2x1ZGUvc2lnbmFsLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRlL3Np Z25hbC5oDQpAQCAtMzEsNiArMzEsMTAgQEANCiAgKiAkRnJlZUJTRCQNCiAgKi8N CiANCisjaWZuZGVmIF9feDg2XzY0X18NCisjaW5jbHVkZSA8aTM4Ni9zaWduYWwu aD4NCisjZWxzZQ0KKw0KICNpZm5kZWYgX01BQ0hJTkVfU0lHTkFMX0hfDQogI2Rl ZmluZQlfTUFDSElORV9TSUdOQUxfSF8NCiANCkBAIC0xMDcsMyArMTExLDQgQEAg c3RydWN0IHNpZ2NvbnRleHQgew0KICNlbmRpZiAvKiBfX0JTRF9WSVNJQkxFICov DQogDQogI2VuZGlmIC8qICFfTUFDSElORV9TSUdOQUxfSF8gKi8NCisjZW5kaWYg LyogIV9feDg2XzY0X18gKi8NCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQvaW5jbHVk ZS9zdGFjay5oIGIvc3lzL2FtZDY0L2luY2x1ZGUvc3RhY2suaA0KaW5kZXggMjRl MjU0Ny4uYmM5OTQ4MyAxMDA2NDQNCi0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL3N0 YWNrLmgNCisrKyBiL3N5cy9hbWQ2NC9pbmNsdWRlL3N0YWNrLmgNCkBAIC0yNiw2 ICsyNiw5IEBADQogICogJEZyZWVCU0QkDQogICovDQogDQorI2lmbmRlZiBfX3g4 Nl82NF9fDQorI2luY2x1ZGUgPGkzODYvc3RhY2suaD4NCisjZWxzZQ0KICNpZm5k ZWYgX01BQ0hJTkVfU1RBQ0tfSF8NCiAjZGVmaW5lCV9NQUNISU5FX1NUQUNLX0hf DQogDQpAQCAtNDIsMyArNDUsNCBAQCBzdHJ1Y3QgYW1kNjRfZnJhbWUgew0KIH07 DQogDQogI2VuZGlmIC8qICFfTUFDSElORV9TVEFDS19IXyAqLw0KKyNlbmRpZiAv KiAhX194ODZfNjRfXyAqLw0KZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRl L3RpbWVycmVnLmggYi9zeXMvYW1kNjQvaW5jbHVkZS90aW1lcnJlZy5oDQppbmRl eCBjZjVmMjgxLi4zODliNWYzIDEwMDY0NA0KLS0tIGEvc3lzL2FtZDY0L2luY2x1 ZGUvdGltZXJyZWcuaA0KKysrIGIvc3lzL2FtZDY0L2luY2x1ZGUvdGltZXJyZWcu aA0KQEAgLTI1LDYgKzI1LDEwIEBADQogICogJEZyZWVCU0QkDQogICovDQogDQor I2lmbmRlZiBfX3g4Nl82NF9fDQorI2luY2x1ZGUgPGkzODYvdGltZXJyZWcuaD4N CisjZWxzZQ0KKw0KIC8qDQogICogVGhlIG91dHB1dHMgb2YgdGhlIHRocmVlIHRp bWVycyBhcmUgY29ubmVjdGVkIGFzIGZvbGxvd3M6DQogICoNCkBAIC01MiwzICs1 Niw0IEBADQogI2VuZGlmIC8qIF9LRVJORUwgKi8NCiANCiAjZW5kaWYgLyogX01B Q0hJTkVfVElNRVJSRUdfSF8gKi8NCisjZW5kaWYgLyogIV9feDg2XzY0X18gKi8N CmRpZmYgLS1naXQgYS9zeXMvYW1kNjQvaW5jbHVkZS90c3MuaCBiL3N5cy9hbWQ2 NC9pbmNsdWRlL3Rzcy5oDQppbmRleCBmYmJlM2FmLi4xZmQ4MmMxIDEwMDY0NA0K LS0tIGEvc3lzL2FtZDY0L2luY2x1ZGUvdHNzLmgNCisrKyBiL3N5cy9hbWQ2NC9p bmNsdWRlL3Rzcy5oDQpAQCAtMzMsNiArMzMsMTAgQEANCiAgKiAkRnJlZUJTRCQN CiAgKi8NCiANCisjaWZuZGVmIF9feDg2XzY0X18NCisjaW5jbHVkZSA8aTM4Ni90 c3MuaD4NCisjZWxzZQ0KKw0KICNpZm5kZWYgX01BQ0hJTkVfVFNTX0hfDQogI2Rl ZmluZSBfTUFDSElORV9UU1NfSF8gMQ0KIA0KQEAgLTY4LDMgKzcyLDQgQEAgZXh0 ZXJuIHN0cnVjdCBhbWQ2NHRzcyBjb21tb25fdHNzW107DQogI2VuZGlmDQogDQog I2VuZGlmIC8qIF9NQUNISU5FX1RTU19IXyAqLw0KKyNlbmRpZiAvKiAhX194ODZf NjRfXyAqLw0KZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL3Vjb250ZXh0 LmggYi9zeXMvYW1kNjQvaW5jbHVkZS91Y29udGV4dC5oDQppbmRleCA1YWI4NDFl Li5hODRkYmIxIDEwMDY0NA0KLS0tIGEvc3lzL2FtZDY0L2luY2x1ZGUvdWNvbnRl eHQuaA0KKysrIGIvc3lzL2FtZDY0L2luY2x1ZGUvdWNvbnRleHQuaA0KQEAgLTI5 LDggKzI5LDEwIEBADQogICogJEZyZWVCU0QkDQogICovDQogDQotI2lmbmRlZiBf TUFDSElORV9VQ09OVEVYVF9IXw0KLSNkZWZpbmUJX01BQ0hJTkVfVUNPTlRFWFRf SF8NCisjaWZuZGVmIF9BTUQ2NF9VQ09OVEVYVF9IXw0KKyNkZWZpbmUJX0FNRDY0 X1VDT05URVhUX0hfDQorDQorI2lmZGVmIF9feDg2XzY0X18NCiANCiAvKg0KICAq IG1jX3RyYXBubyBiaXRzLiBTaGFsbCBiZSBpbiBzeW5jIHdpdGggVEZfWFhYLg0K QEAgLTEwMCw0ICsxMDIsMTAgQEAgdHlwZWRlZiBzdHJ1Y3QgX19tY29udGV4dCB7 DQogCWxvbmcJbWNfc3BhcmVbNF07DQogfSBtY29udGV4dF90Ow0KIA0KLSNlbmRp ZiAvKiAhX01BQ0hJTkVfVUNPTlRFWFRfSF8gKi8NCisjZWxzZSAvKiBfX3g4Nl82 NF9fICovDQorDQorI2luY2x1ZGUgPGkzODYvdWNvbnRleHQuaD4NCisNCisjZW5k aWYNCisNCisjZW5kaWYgLyogIV9BTUQ2NF9VQ09OVEVYVF9IXyAqLw0KZGlmZiAt LWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL3ZhcmFyZ3MuaCBiL3N5cy9hbWQ2NC9p bmNsdWRlL3ZhcmFyZ3MuaA0KaW5kZXggOTNmYWFjNi4uNzVjN2E2ZiAxMDA2NDQN Ci0tLSBhL3N5cy9hbWQ2NC9pbmNsdWRlL3ZhcmFyZ3MuaA0KKysrIGIvc3lzL2Ft ZDY0L2luY2x1ZGUvdmFyYXJncy5oDQpAQCAtNDAsNiArNDAsMTAgQEANCiAgKiAk RnJlZUJTRCQNCiAgKi8NCiANCisjaWZuZGVmIF9feDg2XzY0X18NCisjaW5jbHVk ZSA8aTM4Ni92YXJhcmdzLmg+DQorI2Vsc2UNCisNCiAjaWZuZGVmIF9NQUNISU5F X1ZBUkFSR1NfSF8NCiAjZGVmaW5lCV9NQUNISU5FX1ZBUkFSR1NfSF8NCiANCkBA IC04NywzICs5MSw0IEBAIHR5cGVkZWYgY2hhciAqdmFfbGlzdDsNCiAjZW5kaWYg LyogX19HTlVDTElLRV9CVUlMVElOX1ZBUkFSR1MgKi8NCiANCiAjZW5kaWYgLyog IV9NQUNISU5FX1ZBUkFSR1NfSF8gKi8NCisjZW5kaWYgLyogIV9feDg2XzY0X18g Ki8NCmRpZmYgLS1naXQgYS9zeXMvYW1kNjQvaW5jbHVkZS92bXBhcmFtLmggYi9z eXMvYW1kNjQvaW5jbHVkZS92bXBhcmFtLmgNCmluZGV4IGUwNmZhMzkuLjI5NWZk ODAgMTAwNjQ0DQotLS0gYS9zeXMvYW1kNjQvaW5jbHVkZS92bXBhcmFtLmgNCisr KyBiL3N5cy9hbWQ2NC9pbmNsdWRlL3ZtcGFyYW0uaA0KQEAgLTQyLDYgKzQyLDEw IEBADQogICovDQogDQogDQorI2lmbmRlZiBfX3g4Nl82NF9fDQorI2luY2x1ZGUg PGkzODYvdm1wYXJhbS5oPg0KKyNlbHNlDQorDQogI2lmbmRlZiBfTUFDSElORV9W TVBBUkFNX0hfDQogI2RlZmluZQlfTUFDSElORV9WTVBBUkFNX0hfIDENCiANCkBA IC0yMTUsMyArMjE5LDQgQEANCiAjZGVmaW5lCVpFUk9fUkVHSU9OX1NJWkUJKDIg KiAxMDI0ICogMTAyNCkJLyogMk1CICovDQogDQogI2VuZGlmIC8qIF9NQUNISU5F X1ZNUEFSQU1fSF8gKi8NCisjZW5kaWYgLyogIV9feDg2XzY0X18gKi8NCg== --Boundary_(ID_2R7SRK8nTZt/NNUkoteUNg)-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 06:02:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20BE51065670 for ; Tue, 21 Aug 2012 06:02:05 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C07688FC12 for ; Tue, 21 Aug 2012 06:02:04 +0000 (UTC) Received: by yhfs35 with SMTP id s35so6779057yhf.13 for ; Mon, 20 Aug 2012 23:02:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=qENIk60zop6XBjI2GR1x6FBM+qbLVmFOmaKLH/r9qi0=; b=gJOgdFWYGT6j0Mp08THrC53AzWBA1eYGocCymgJLCj77gLVdZkwtw8cxKPP8X6nUUv ZpUClQFjLzDkFKrrdSRvoR+tyPeEfMegZpJvUx3LnZAh/VKfm34/9utu0/QmbIEjtvAg hAu1urz9XZjiHMU3CtYU+fqVWr6dpZxl4vyzXn91+svqR754RYX7wnIW3yIi3GI+ZVSp IwBtL3gPMe/14dKIoxWx3JDmM8tGU1LT16yBziZUvUKrt4Q9S2UuUb1oXvaPzaz3ECyX Mqr1koyViNKKhGxKvjkqVg4tV95cf36SCR++hI6SbcwSZubYQiYK9KUt0jS350EwQ4sk giAA== Received: by 10.50.154.165 with SMTP id vp5mr12363852igb.40.1345528923268; Mon, 20 Aug 2012 23:02:03 -0700 (PDT) Received: from [192.168.1.36] (ppp-124-120-194-58.revip2.asianet.co.th. [124.120.194.58]) by mx.google.com with ESMTPS id p5sm4965642igm.13.2012.08.20.23.02.00 (version=SSLv3 cipher=OTHER); Mon, 20 Aug 2012 23:02:02 -0700 (PDT) Message-ID: <503322A0.3080201@pathscale.com> Date: Tue, 21 Aug 2012 12:54:40 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:6.0.2) Gecko/20111003 Thunderbird/6.0.2 MIME-Version: 1.0 To: Dan McGregor References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQniGnMUBDsk+xu6gqIlNBCwQrUiwFlHeX/nAC79PlqPyeTtZCzt1MXAik5atXaIAFlK99SC Cc: freebsd-hackers@freebsd.org Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 06:02:05 -0000 On 08/21/12 09:32 AM, Dan McGregor wrote: > Hi. > > I've been working on porting compiler-rt/clang's support for address > sanitization (asan) to FreeBSD. So far I have it building and it > appears to work properly, however the build system expects to be able > to build 32 bit binaries on amd64. > > amd64 doesn't include i386's machine/foo headers. The included patch > is my proposed solution: > > Add i386 headers to /usr/include/i386, and in machine/foo.h, check if > it's a 32 bit build and include the appropriate header from i386. > > For example machine/ucontext.h will include i386/ucontext.h if > compiled with -m32. > > Thoughts? > > If anyone's curious about the compiler_rt port, I have it at > github.com/dannomac/compiler-rt on the branch named freebsd. Sorry for fencepost comment which may have no/little relevance here Changing the hierarchy to ISA/bits may make cross compiling easier in the future From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 07:44:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2D77106564A; Tue, 21 Aug 2012 07:44:49 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 186B48FC08; Tue, 21 Aug 2012 07:44:43 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q7L7hAjc033858; Tue, 21 Aug 2012 09:43:16 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q7L7gxEW033855; Tue, 21 Aug 2012 09:43:06 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 21 Aug 2012 09:42:59 +0200 (CEST) From: Wojciech Puchar To: Warner Losh In-Reply-To: <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> Message-ID: References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 21 Aug 2012 09:43:20 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 07:44:50 -0000 > > Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... true. just to make sure it will be absolutely portable how about bcopymacaddress(dst,src) and then define it whatever you find it fastest on any architecture? From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 08:49:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51601106566B; Tue, 21 Aug 2012 08:49:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BD9658FC08; Tue, 21 Aug 2012 08:49:34 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7L8ngJU020728; Tue, 21 Aug 2012 11:49:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q7L8nUvd094114; Tue, 21 Aug 2012 11:49:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7L8nUbd094112; Tue, 21 Aug 2012 11:49:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 21 Aug 2012 11:49:30 +0300 From: Konstantin Belousov To: Dan McGregor Message-ID: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AfkfStYJxYILZKr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, tijl@freebsd.org Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 08:49:35 -0000 --7AfkfStYJxYILZKr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: > Hi. >=20 > I've been working on porting compiler-rt/clang's support for address > sanitization (asan) to FreeBSD. So far I have it building and it > appears to work properly, however the build system expects to be able > to build 32 bit binaries on amd64. >=20 > amd64 doesn't include i386's machine/foo headers. The included patch > is my proposed solution: >=20 > Add i386 headers to /usr/include/i386, and in machine/foo.h, check if > it's a 32 bit build and include the appropriate header from i386. >=20 > For example machine/ucontext.h will include i386/ucontext.h if > compiled with -m32. >=20 > Thoughts? >=20 > If anyone's curious about the compiler_rt port, I have it at > github.com/dannomac/compiler-rt on the branch named freebsd. There was a work by Tijl Coosemans in the similar, but somewhat less hacky direction. The headers are moved into sys/x86/include and unified as much as possible, while machine/ counterpart includes corresponding header from x86/include. I even lost track of how much more headers is left to convert. In fact, not all headers are equal, some are only useful for kernel or base system. Also, parts of the critically important headers do not live in machine/ at all, e.g. the headers from libm. The work seems to be stale, do you want to cooperate with Tijl or continue ? --7AfkfStYJxYILZKr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAzS5oACgkQC3+MBN1Mb4hWrgCgsCOsNwhlsZcSYp1G106H+BXw QxUAn3qLfkvdz5dxtwQ/Cd9xqNaEnhJ3 =3lf8 -----END PGP SIGNATURE----- --7AfkfStYJxYILZKr-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 09:18:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6B8B1065795; Tue, 21 Aug 2012 09:18:38 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 47A478FC12; Tue, 21 Aug 2012 09:18:37 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 0A01F6678; Tue, 21 Aug 2012 11:18:36 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id C9C9D88BA; Tue, 21 Aug 2012 11:18:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Barton References: <5031FAAB.9020409@FreeBSD.org> Date: Tue, 21 Aug 2012 11:18:35 +0200 In-Reply-To: <5031FAAB.9020409@FreeBSD.org> (Doug Barton's message of "Mon, 20 Aug 2012 01:51:55 -0700") Message-ID: <86a9xobo2c.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , Vitaly Magerya , Garrett Wollman , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 09:18:38 -0000 Doug Barton writes: > Dag-Erling, do you have a timeline for getting started on the > ldns/unbound import? I imported the code into the vendor tree, but did not proceed any further as there was still no firm consensus at the time. I believe the conclusion - to the extent that there was one - was that people were fine with tossing out BIND and importing ldns to replace the client bits, as long as we had suitable drop-in replacements for host(1) and dig(1), but there was no consensus on whether to import unbound. I'll start working on getting ldns into head this weekend. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 10:26:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6C7D1065674; Tue, 21 Aug 2012 10:26:34 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2B48FC0A; Tue, 21 Aug 2012 10:26:34 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q7LAQVup089793; Tue, 21 Aug 2012 12:26:31 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q7LAQVVM089792; Tue, 21 Aug 2012 12:26:31 +0200 (CEST) (envelope-from marius) Date: Tue, 21 Aug 2012 12:26:30 +0200 From: Marius Strobl To: Mitya Message-ID: <20120821102630.GA89551@alchemy.franken.de> References: <50324DB4.6080905@cabletv.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50324DB4.6080905@cabletv.dp.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 10:26:35 -0000 On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote: > Hi. > I found some overhead code in /src/sys/net/if_ethersubr.c and > /src/sys/netgraph/ng_ether.c > > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > This code call every time, when we send Ethernet packet. > On example, on my machine in invoked nearly 20K per second. > > Why we are use bcopy(), to copy only 6 bytes? > Answer - in some architectures we are can not directly copy unaligned data. > > I propose this solution. > > In file /usr/src/include/net/ethernet.h add this lines: > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > #if defined(__i386__) || defined(__amd64__) > *dst = *src; > #else > bcopy(src, dst, ETHER_ADDR_LEN); > #endif > } > > On platform i386 gcc produce like this code: > leal -30(%ebp), %eax > leal 6(%eax), %ecx > leal -44(%ebp), %edx > movl (%edx), %eax > movl %eax, (%ecx) > movzwl 4(%edx), %eax > movw %ax, 4(%ecx) > And clang produce this: > movl -48(%ebp), %ecx > movl %ecx, -26(%ebp) > movw -44(%ebp), %si > movw %si, -22(%ebp) > > > All this variants are much faster, than bcopy() > A bit orthogonal to this but also related to the performance impact of these bcopy() calls, for !__NO_STRICT_ALIGNMENT architectures these places probably should use memcpy() instead as bcopy() additionally has to check for overlap while the former does not. Overlaps unlikely are an issue in these cases and at least NetBSD apparently has done the switch to memcpy() 5.5 years ago. Marius From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 11:12:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A736106564A; Tue, 21 Aug 2012 11:12:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E885E8FC17; Tue, 21 Aug 2012 11:12:48 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3DF647300A; Tue, 21 Aug 2012 13:24:15 +0200 (CEST) Date: Tue, 21 Aug 2012 13:24:15 +0200 From: Luigi Rizzo To: Marius Strobl Message-ID: <20120821112415.GA50078@onelab2.iet.unipi.it> References: <50324DB4.6080905@cabletv.dp.ua> <20120821102630.GA89551@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120821102630.GA89551@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 11:12:51 -0000 On Tue, Aug 21, 2012 at 12:26:30PM +0200, Marius Strobl wrote: ... > > Why we are use bcopy(), to copy only 6 bytes? > > Answer - in some architectures we are can not directly copy unaligned data. > > > > I propose this solution. > > > > In file /usr/src/include/net/ethernet.h add this lines: > > > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > > #if defined(__i386__) || defined(__amd64__) > > *dst = *src; > > #else > > bcopy(src, dst, ETHER_ADDR_LEN); > > #endif > > } ... > > All this variants are much faster, than bcopy() > > > > A bit orthogonal to this but also related to the performance > impact of these bcopy() calls, for !__NO_STRICT_ALIGNMENT > architectures these places probably should use memcpy() > instead as bcopy() additionally has to check for overlap > while the former does not. Overlaps unlikely are an issue > in these cases and at least NetBSD apparently has done the > switch to memcpy() 5.5 years ago. even more orthogonal: I found that copying 8n + (5, 6 or 7) bytes was much much slower than copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, other cases are slow (turned into 2 or 3 different writes). The netmap code uses a pkt_copy routine that does exactly this rounding, gaining some 10-20ns per packet for small sizes. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 11:27:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CFF51065672; Tue, 21 Aug 2012 11:27:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 92C848FC08; Tue, 21 Aug 2012 11:26:59 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q7LBQtKZ090094; Tue, 21 Aug 2012 13:26:55 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q7LBQtv0090093; Tue, 21 Aug 2012 13:26:55 +0200 (CEST) (envelope-from marius) Date: Tue, 21 Aug 2012 13:26:55 +0200 From: Marius Strobl To: Warner Losh Message-ID: <20120821112655.GA90066@alchemy.franken.de> References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: Wojciech Puchar , freebsd-net@freebsd.org, Mitya , freebsd-hackers@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 11:27:00 -0000 On Mon, Aug 20, 2012 at 01:20:29PM -0600, Warner Losh wrote: > > On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: > > >>> or use ++. > >>> > >>> i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. > >> > >> We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. > > should is the most important word in Your post. what it actually do - i don't know. > > If we are requiring this to be __aligned(2), we should tag it as such to enforce this. > > Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... > While the __aligned(2) approach certainly works, I've actually rather mixed experiences on x86 with it as the compiler doesn't necessarily produce the small and efficient one would expect from code it. Such a change certainly shouldn't be done just on the assumption that the compiler has all hints required to produce good code from it but the resulting asm should be verified across all affected architectures. Marius From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 06:35:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC53A106566B; Tue, 21 Aug 2012 06:35:57 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id 831A58FC19; Tue, 21 Aug 2012 06:35:57 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T3iXa-000FDf-N9; Tue, 21 Aug 2012 10:06:18 +0300 Message-ID: <50332AD8.6020800@cabletv.dp.ua> Date: Tue, 21 Aug 2012 09:29:44 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> In-Reply-To: <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 21 Aug 2012 11:39:56 +0000 Cc: Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 06:35:57 -0000 20.08.2012 22:20, Warner Losh напиÑал: > On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: > >>>> or use ++. >>>> >>>> i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. >>> We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. >> should is the most important word in Your post. what it actually do - i don't know. > If we are requiring this to be __aligned(2), we should tag it as such to enforce this. > > Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... > > Warner > I try some times different algorithms. This is one of thees: *(u_int32_t *)(dst) = *(u_int32_t *)(src); *(u_int16_t *)&(dst->octet[4]) = *(u_int16_t *)&(src->octet[4]); But, internal gcc and clang optimisations are much better, than my attempt. For aligned platforms (2 bytes aligned) best choice is *dst = *src; From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 11:52:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A28EB106566C; Tue, 21 Aug 2012 11:52:50 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id 586228FC08; Tue, 21 Aug 2012 11:52:49 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T3nUG-000C1A-Uv; Tue, 21 Aug 2012 15:23:12 +0300 Message-ID: <5033751C.1050405@cabletv.dp.ua> Date: Tue, 21 Aug 2012 14:46:36 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: Marius Strobl , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> <20120821112655.GA90066@alchemy.franken.de> In-Reply-To: <20120821112655.GA90066@alchemy.franken.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 21 Aug 2012 11:58:50 +0000 Cc: Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 11:52:50 -0000 21.08.2012 14:26, Marius Strobl напиÑал: > On Mon, Aug 20, 2012 at 01:20:29PM -0600, Warner Losh wrote: >> On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: >> >>>>> or use ++. >>>>> >>>>> i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. >>>> We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. >>> should is the most important word in Your post. what it actually do - i don't know. >> If we are requiring this to be __aligned(2), we should tag it as such to enforce this. >> >> Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... >> > While the __aligned(2) approach certainly works, I've actually rather > mixed experiences on x86 with it as the compiler doesn't necessarily > produce the small and efficient one would expect from code it. Such > a change certainly shouldn't be done just on the assumption that the > compiler has all hints required to produce good code from it but the > resulting asm should be verified across all affected architectures. > > Marius > Yes. I totally agree. That is why I have limited use of this feature only i386 and amd64 architectures. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 14:31:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A92E106566B for ; Tue, 21 Aug 2012 14:31:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 475FF8FC15 for ; Tue, 21 Aug 2012 14:31:06 +0000 (UTC) Received: by yenl7 with SMTP id l7so7107587yen.13 for ; Tue, 21 Aug 2012 07:31:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Z8zhGvHY93h9EY1pX0YkjsVQ0qYTIAiQ0DLQIrqs7y8=; b=H0KUgH4QqfH6MymGHpi6wgn5bfA4NSqi1Et7jUxED1+L2qU77DI5UX2WI/9LT0xaQr +M65FzjY6qwO16SDIv5aQs/AgHYkWElJcPnhZyqruTrdb1yFFrNrwFwjALw0VT3b5n8o MoJPM+hAdMlt+LpGaHbMvirj8ZOa3QwqyW3llNszDZp1zVX4AErUBdg+htFcAvUMODyI L7U9UvrJYeN71SYdaBdF92iO2QdvNekxr2NAzQFpt1STomS8GY/4Zeodo9fi3GisbubC mQ9e90gqw5ruIBIHucv+r+2doB9uXs7pn0JSbwDuSdkxfAzoQTgCRTcvMCvDEE2UB8in toSA== Received: by 10.60.3.202 with SMTP id e10mr12977176oee.52.1345559465531; Tue, 21 Aug 2012 07:31:05 -0700 (PDT) Received: from [192.168.100.235] (70-90-212-28-saltlake.hfc.comcastbusiness.net. [70.90.212.28]) by mx.google.com with ESMTPS id th3sm1375715obb.6.2012.08.21.07.31.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 07:31:04 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120821112655.GA90066@alchemy.franken.de> Date: Tue, 21 Aug 2012 08:31:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <92186FE4-F83A-43A2-B1C9-85A1C42513AC@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> <20120821112655.GA90066@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnaq2qVyzrz43TPGvQTZDHK+N4yj+gZSuLbwjSRMR/YDm2WMUHDEuWdKxGvsMFU1a8ct3LP Cc: Wojciech Puchar , freebsd-net@freebsd.org, Mitya , freebsd-hackers@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:31:07 -0000 On Aug 21, 2012, at 5:26 AM, Marius Strobl wrote: > On Mon, Aug 20, 2012 at 01:20:29PM -0600, Warner Losh wrote: >>=20 >> On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: >>=20 >>>>> or use ++. >>>>>=20 >>>>> i think it is always aligned to 2 bytes and this should produce = usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. >>>>=20 >>>> We should tag it as __aligned(2) then, no? If so, then the = compiler should generate the code you posted. >>> should is the most important word in Your post. what it actually do = - i don't know. >>=20 >> If we are requiring this to be __aligned(2), we should tag it as such = to enforce this. >>=20 >> Even without this tagging, the code to do a structure level copy of 6 = bytes is going to be tiny... >>=20 >=20 > While the __aligned(2) approach certainly works, I've actually rather > mixed experiences on x86 with it as the compiler doesn't necessarily > produce the small and efficient one would expect from code it. Such > a change certainly shouldn't be done just on the assumption that the > compiler has all hints required to produce good code from it but the > resulting asm should be verified across all affected architectures. Very true... I would have thought that went without saying... Warner= From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 14:47:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B41E106564A for ; Tue, 21 Aug 2012 14:47:15 +0000 (UTC) (envelope-from adscomplex@gmail.com) Received: from mail-lpp01m010-f68.google.com (mail-lpp01m010-f68.google.com [209.85.215.68]) by mx1.freebsd.org (Postfix) with ESMTP id DE4CE8FC1E for ; Tue, 21 Aug 2012 14:47:14 +0000 (UTC) Received: by lagp5 with SMTP id p5so1703495lag.7 for ; Tue, 21 Aug 2012 07:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7dGs2H5zNKyJtXpw/3dy2hbE8n1FQNGdva7Zvqx5wJg=; b=I1HKLwalyDd2C8ZkgztXYAtzizzBbxUk4L2SIAY3GvP+RyQsp6YuSnejmOTm0dTSac zDRNdL1RA5yXq1dPiWgRsJB0X0HkSqfY+mwMeLx5jWEQIXG9G5AzB8QfVTdvRfKNsjp6 u/XsPGeRRNltKkFdHbWI0GrGlqvgIcqhxLNBlvdNaMhtpHi/KEIBXy3awT6xwqia/vBH djVqKlbVhMe8QZ3iUPtaMdstaUMuH7F2RdOaMDC68g8bY7uq8rF28C21McbK3qrEH9kg cm1sQF5IMv0DAoHmoCkt5uAqKyoqJnTjnGErG7ZoJ4Bhytp6yljP56/BE8Nj+z8x2Ze4 JGpw== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr17748637lab.2.1345560128333; Tue, 21 Aug 2012 07:42:08 -0700 (PDT) Received: by 10.112.44.134 with HTTP; Tue, 21 Aug 2012 07:42:08 -0700 (PDT) Date: Tue, 21 Aug 2012 17:42:08 +0300 Message-ID: From: Remme To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Help needed with possible kernel memory leak (FreeBSD 9.0 Release) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:47:15 -0000 Hi All, Please help to solve a kernel memory leak problem. After few weeks searching forums and googling any help is welcome. Here is the problem description: We are installed the latest 9.0 FreeBSD with all recent patches. Ports tree is also up to date. Host running a nginx, php-fpm, memcached, mysqld, sphinxsearch. Two WD HDD is gmirrored (each partition). Also we are using a small ssd for nginx cache and mysql databases. 8 GB RAM. We have always growing active memory till kernel panic. (it's takes about 2 weeks till memory leak kills host) According to top - active memory is always growing but sum of all processes memory is stable about 3.5 Gb. So looks like kernel slowly eating all our memory Please visit http://forums.freebsd.org/showthread.php?t=34023 to get datailed information about this problem. Thank you, Remme. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 14:52:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9DEB1065676; Tue, 21 Aug 2012 14:52:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C00D58FC0A; Tue, 21 Aug 2012 14:52:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D4B9B96C; Tue, 21 Aug 2012 10:52:56 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 21 Aug 2012 09:43:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <50324DB4.6080905@cabletv.dp.ua> In-Reply-To: <50324DB4.6080905@cabletv.dp.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208210943.08341.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Aug 2012 10:52:56 -0400 (EDT) Cc: freebsd-net@freebsd.org, Mitya Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:52:57 -0000 On Monday, August 20, 2012 10:46:12 am Mitya wrote: > Hi. > I found some overhead code in /src/sys/net/if_ethersubr.c and > /src/sys/netgraph/ng_ether.c > > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > This code call every time, when we send Ethernet packet. > On example, on my machine in invoked nearly 20K per second. > > Why we are use bcopy(), to copy only 6 bytes? > Answer - in some architectures we are can not directly copy unaligned data. > > I propose this solution. > > In file /usr/src/include/net/ethernet.h add this lines: > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > #if defined(__i386__) || defined(__amd64__) > *dst = *src; > #else > bcopy(src, dst, ETHER_ADDR_LEN); > #endif > } Doesn't '*dst = *src' just work on all platforms? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 14:52:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DC7E106564A; Tue, 21 Aug 2012 14:52:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 415F58FC0C; Tue, 21 Aug 2012 14:52:59 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2D6DBB964; Tue, 21 Aug 2012 10:52:58 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 21 Aug 2012 09:44:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> In-Reply-To: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208210944.31001.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Aug 2012 10:52:58 -0400 (EDT) Cc: Konstantin Belousov , tijl@freebsd.org, Dan McGregor Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:52:59 -0000 On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: > On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: > > Hi. > > > > I've been working on porting compiler-rt/clang's support for address > > sanitization (asan) to FreeBSD. So far I have it building and it > > appears to work properly, however the build system expects to be able > > to build 32 bit binaries on amd64. > > > > amd64 doesn't include i386's machine/foo headers. The included patch > > is my proposed solution: > > > > Add i386 headers to /usr/include/i386, and in machine/foo.h, check if > > it's a 32 bit build and include the appropriate header from i386. > > > > For example machine/ucontext.h will include i386/ucontext.h if > > compiled with -m32. > > > > Thoughts? > > > > If anyone's curious about the compiler_rt port, I have it at > > github.com/dannomac/compiler-rt on the branch named freebsd. > > There was a work by Tijl Coosemans in the similar, but somewhat less hacky > direction. The headers are moved into sys/x86/include and unified as much > as possible, while machine/ counterpart includes corresponding header > from x86/include. > > I even lost track of how much more headers is left to convert. In fact, > not all headers are equal, some are only useful for kernel or base system. > Also, parts of the critically important headers do not live in machine/ > at all, e.g. the headers from libm. > > The work seems to be stale, do you want to cooperate with Tijl or continue ? I think we should probably follow Tijl's model since we are on that path. I originally preferred the /usr/include/i386 approach, but have come around to Tjil's approach instead. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 15:04:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 124991065674; Tue, 21 Aug 2012 15:04:17 +0000 (UTC) (envelope-from danismostlikely@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9798FC15; Tue, 21 Aug 2012 15:04:16 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so8053275vcb.13 for ; Tue, 21 Aug 2012 08:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s3gaiK5ZBjP/+ZKM8jlPDpG4P8J5mIuerIUQERtD6wY=; b=ikxv3XOo4eGlP5tcvpFF8vUXCDbVrCxLRcNbS+0EC4kYyOJneul1BSF6hFsIfBBTwU x6bGlMELZGKWNkrOzsodhvAyqdQWW14bGmqHPsdgYPiwbmOKmBphQoRdA3y2RQ0WpMzr ASQpnWNOtB3HA6hTGXROhV6SN3RMPYASrIiSGDgBGjj4AOQBEE5ycDLVN82BMxQiCiXz eV6hpF0aeuSMJlbN3gLxRTVSVeyEHCnobT9bHnY3ItUafd8IrTmi/XOX1z8NVLWDrDHG oJjBBIfh0zKlhx0HUdtwDpsL5/diwMtjG3IAjM8tRVt1XzRZHmYTPW0+5VwTVpc99xHX kmsw== MIME-Version: 1.0 Received: by 10.52.67.7 with SMTP id j7mr11721783vdt.91.1345561455722; Tue, 21 Aug 2012 08:04:15 -0700 (PDT) Received: by 10.58.91.169 with HTTP; Tue, 21 Aug 2012 08:04:15 -0700 (PDT) In-Reply-To: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> Date: Tue, 21 Aug 2012 09:04:15 -0600 Message-ID: From: Dan McGregor To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, tijl@freebsd.org Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:04:17 -0000 My solution is certainly fairly hacky, I just took inspiration from NetBSD. I wanted to see if it could be done. While I was there I did identify several files that should be common between i386 and amd64, such as exec.h. Since reading your email I started looking at the x86 common code, and have made some more code common; specifically asm.h ans ucontext.h. I'll be putting that on github shortly. Since it does look like tijl hasn't committed anything since March, I would like to co-operate and see what his plans were. The idea of merging the i386 and amd64 headers into a common area seems like a better idea to me. Dan On 21 August 2012 02:49, Konstantin Belousov wrote: > On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >> Hi. >> >> I've been working on porting compiler-rt/clang's support for address >> sanitization (asan) to FreeBSD. So far I have it building and it >> appears to work properly, however the build system expects to be able >> to build 32 bit binaries on amd64. >> >> amd64 doesn't include i386's machine/foo headers. The included patch >> is my proposed solution: >> >> Add i386 headers to /usr/include/i386, and in machine/foo.h, check if >> it's a 32 bit build and include the appropriate header from i386. >> >> For example machine/ucontext.h will include i386/ucontext.h if >> compiled with -m32. >> >> Thoughts? >> >> If anyone's curious about the compiler_rt port, I have it at >> github.com/dannomac/compiler-rt on the branch named freebsd. > > There was a work by Tijl Coosemans in the similar, but somewhat less hacky > direction. The headers are moved into sys/x86/include and unified as much > as possible, while machine/ counterpart includes corresponding header > from x86/include. > > I even lost track of how much more headers is left to convert. In fact, > not all headers are equal, some are only useful for kernel or base system. > Also, parts of the critically important headers do not live in machine/ > at all, e.g. the headers from libm. > > The work seems to be stale, do you want to cooperate with Tijl or continue ? From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 15:20:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C57E1106564A for ; Tue, 21 Aug 2012 15:20:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8D5778FC0A for ; Tue, 21 Aug 2012 15:20:46 +0000 (UTC) Received: by dadr6 with SMTP id r6so3237445dad.13 for ; Tue, 21 Aug 2012 08:20:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=cacyrk3J+IwdSKDlz7T2ePwBidhF7kPNpUh4nz7UdIA=; b=QtqhpOg90ymiIIyfVHd2jpw36Ry5vxxr89kXFr8CnnhwdXbEMFxoZWzpvQ9MpK3MkQ k/B5fefuFQy34EHqae6lSfccEj7dfaqtJAsNrNig5YosoHeHVqo7dOziOPp9NNKVMiZz l9QHBNGHAl9VHe7dL8BJesBik+5CUgmhtrNkMSzE9i3FzE02UOKNwxvCAAUVuYJTTEat NsURpLlwphkAFOcxSq4DaYIJ41eiY6XiJCZomWaWXcIghdBqDEdIyrZWNmG7vM1VR3c3 rhw1xa0dPEZXPHUzUXb6JXJv+L3Hf3wAbKzf4GnhkQ5C+eU3uoW4cuM7i7BEh17tVtM5 kf8g== Received: by 10.68.232.138 with SMTP id to10mr7286064pbc.77.1345562440844; Tue, 21 Aug 2012 08:20:40 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([216.51.42.66]) by mx.google.com with ESMTPS id sr3sm1634505pbc.44.2012.08.21.08.20.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 08:20:40 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 21 Aug 2012 09:20:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> To: Wojciech Puchar X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnTMt8lj5tKgQIzkt/evX0bFSWei8bSZTK+wwPc3s/KB35xSqSMe5raDfkI53ljBtRSXZPK Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:20:46 -0000 On Aug 21, 2012, at 1:42 AM, Wojciech Puchar wrote: >>=20 >> Even without this tagging, the code to do a structure level copy of 6 = bytes is going to be tiny... >=20 > true. >=20 > just to make sure it will be absolutely portable how about >=20 > bcopymacaddress(dst,src) >=20 > and then define it whatever you find it fastest on any architecture? How about just changing it to the *dst =3D *src, compiling it on all = architectures and then deciding if the improvement of the code from a = hand-tweaked thing is worth that uglification? Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 15:24:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18618106564A; Tue, 21 Aug 2012 15:24:11 +0000 (UTC) (envelope-from danismostlikely@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 964EA8FC12; Tue, 21 Aug 2012 15:24:10 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so8081446vcb.13 for ; Tue, 21 Aug 2012 08:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uqXACuKnK2hPBxw+Yx3ndOWojZIcOlo1uTRq9RFPp8I=; b=t1z1NFb4AhXucsxdNbGryjvnWDWZaGwduGlOQCovIIsB2w+09DeheTk9kVtoNUvYVQ WIrM0VZof7GRVj/SI+3etmt3BHRWK/byTVNLAsSyDs1MmcT5p0RBi4eeC+CYNKYCfFSy eoLFBeFxpY3K1X0rVKbELHpFXUdqCwralKg+uOSlPnIRRHn+WcptQLDyC61OH/f8Zkmi FpoEetj9cK3a7mrS5ko8wP17duf6FNQiSaw6AjYhEF19OUSgXmfNa7b55/XE9lGZ9rFd CzVoyTPyoUWGnJGNJaZaKN7QAC1t7woNkrfQa2ABizbW8OQhBao6KsCuhXUBpy61ib+S hMwQ== MIME-Version: 1.0 Received: by 10.52.21.82 with SMTP id t18mr11705647vde.66.1345562649956; Tue, 21 Aug 2012 08:24:09 -0700 (PDT) Received: by 10.58.91.169 with HTTP; Tue, 21 Aug 2012 08:24:09 -0700 (PDT) In-Reply-To: <201208210944.31001.jhb@freebsd.org> References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <201208210944.31001.jhb@freebsd.org> Date: Tue, 21 Aug 2012 09:24:09 -0600 Message-ID: From: Dan McGregor To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, tijl@freebsd.org Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:24:11 -0000 I think I agree now. The more code shared between archtectures the better. I've committed some patches to my github freebsd fork that merge exec.h, asm.h and ucontex.h into x86. I'll probably do more later tonight. On 21 August 2012 07:44, John Baldwin wrote: > On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: >> On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >> > Hi. >> > >> > I've been working on porting compiler-rt/clang's support for address >> > sanitization (asan) to FreeBSD. So far I have it building and it >> > appears to work properly, however the build system expects to be able >> > to build 32 bit binaries on amd64. >> > >> > amd64 doesn't include i386's machine/foo headers. The included patch >> > is my proposed solution: >> > >> > Add i386 headers to /usr/include/i386, and in machine/foo.h, check if >> > it's a 32 bit build and include the appropriate header from i386. >> > >> > For example machine/ucontext.h will include i386/ucontext.h if >> > compiled with -m32. >> > >> > Thoughts? >> > >> > If anyone's curious about the compiler_rt port, I have it at >> > github.com/dannomac/compiler-rt on the branch named freebsd. >> >> There was a work by Tijl Coosemans in the similar, but somewhat less hacky >> direction. The headers are moved into sys/x86/include and unified as much >> as possible, while machine/ counterpart includes corresponding header >> from x86/include. >> >> I even lost track of how much more headers is left to convert. In fact, >> not all headers are equal, some are only useful for kernel or base system. >> Also, parts of the critically important headers do not live in machine/ >> at all, e.g. the headers from libm. >> >> The work seems to be stale, do you want to cooperate with Tijl or continue ? > > I think we should probably follow Tijl's model since we are on that path. > I originally preferred the /usr/include/i386 approach, but have come around > to Tjil's approach instead. > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 16:31:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F511065670 for ; Tue, 21 Aug 2012 16:31:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 281A28FC0C for ; Tue, 21 Aug 2012 16:31:55 +0000 (UTC) Received: by dadr6 with SMTP id r6so3292468dad.13 for ; Tue, 21 Aug 2012 09:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Wl4lAwOkSHoPv+M0KVrXyNoGc3e5VQhNyDcpzQaRreU=; b=OVxqyMIY9eosAp3sb2N9ojC6Qr+vFsGZbgIWojsXOR4ZO5f445p4KYCcehUSmY+JBb +Db50haYTeItu8DGiFs2vis5zgEAoxGxP9FVdfRG4DzQlvL3JKJdZ3RH23SfPB5Nsql1 F5I+FtrDPUs/oBw4wPPl7/d25jpJr4K4xZka+A2Dt7GlVRZbCyP0fOYjygbW/IL89bwG uWTRlnSk7fk5ADSH49Ho2TeEp+W+4E4xGNdEfuOJNMTHCQixu/f4KqIHP+9wBFEKwKBO slXnoOSo5bRUxUdXlRWXoCITHrwqLQDfFirxlA8tRCH2fjg/ScdW+Ddacf+s/yNiS389 8UMg== MIME-Version: 1.0 Received: by 10.66.85.4 with SMTP id d4mr29985997paz.11.1345566714890; Tue, 21 Aug 2012 09:31:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Tue, 21 Aug 2012 09:31:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Aug 2012 09:31:54 -0700 X-Google-Sender-Auth: WKdst1pH88y8YXdrlWCNe3ZhZiI Message-ID: From: Adrian Chadd To: Remme Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Help needed with possible kernel memory leak (FreeBSD 9.0 Release) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:31:55 -0000 FWIW - there's lots of statistics and some dtrace scripts + output here. So for those knowlegable in this area, this forum thread is well worth your time. Adrian On 21 August 2012 07:42, Remme wrote: > Hi All, > > Please help to solve a kernel memory leak problem. > After few weeks searching forums and googling any help is welcome. > > Here is the problem description: > We are installed the latest 9.0 FreeBSD with all recent patches. > Ports tree is also up to date. > Host running a nginx, php-fpm, memcached, mysqld, sphinxsearch. > Two WD HDD is gmirrored (each partition). > Also we are using a small ssd for nginx cache and mysql databases. > 8 GB RAM. > > We have always growing active memory till kernel panic. > (it's takes about 2 weeks till memory leak kills host) > > According to top - active memory is always growing but sum of all processes > memory is stable about 3.5 Gb. > So looks like kernel slowly eating all our memory > > Please visit > http://forums.freebsd.org/showthread.php?t=34023 > to get datailed information about this problem. > > Thank you, > Remme. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 16:34:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF9B91065672; Tue, 21 Aug 2012 16:34:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 770548FC0A; Tue, 21 Aug 2012 16:34:43 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so189613pbb.13 for ; Tue, 21 Aug 2012 09:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8b6dj4QLnpKsuRXtWfPCdrNkT7HS90hq7Qkk5biz7bM=; b=QQSjN2u6i4xaoqlTwxOgJzEoxbmg/99TIBP5YwYbrfilkLB/j0Xtb6mmk85NGieBLt mvQZ7brxZiA0LHlVBYj9fjt7ZR74BNrBMxBGC8chm3LTLK3eB0DVVMA28gA9Ex8sfcv2 A2yrsaYkUS+AUi7G0z4MVbNsl46GDF6WZ0hwkbMVfgAD/kzItKM1PIwYdDePDlY/zuUS dryejfQ+QbdzTx/Vr8067su3W0CbmbZrjsYdZCNLVjShyfbBh5Eh9sRDHyXen4NEcT8t abNW0o+7BlG/wD7GrrXs7IRwmFVytO5ZYHtUQTQi6MGvzAkfF9+QZfkKCFQKquf0rGXN zP2g== MIME-Version: 1.0 Received: by 10.68.129.131 with SMTP id nw3mr45314162pbb.43.1345566882982; Tue, 21 Aug 2012 09:34:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Tue, 21 Aug 2012 09:34:42 -0700 (PDT) In-Reply-To: <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <5452BF37-3658-4C1F-B965-CE3EA28B6EA5@bsdimp.com> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> Date: Tue, 21 Aug 2012 09:34:42 -0700 X-Google-Sender-Auth: YEx0_ajkug3Y5gCsY8HfBAF0JqU Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Wojciech Puchar , freebsd-net@freebsd.org, Mitya , freebsd-hackers@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:34:43 -0000 Hi, What about just creating an ETHER_ADDR_COPY(dst, src) and putting that in a relevant include file, then hide the ugliness there? The same benefits will likely appear when copying wifi MAC addresses to/from headers. Thanks, I'm glad someone noticed this. Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 17:11:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3046A1065674 for ; Tue, 21 Aug 2012 17:11:32 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id D0EFB8FC25 for ; Tue, 21 Aug 2012 17:11:31 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 58D4C25D3A17; Tue, 21 Aug 2012 17:11:25 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 795A5BE84BD; Tue, 21 Aug 2012 17:11:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id A7qZd99wSguM; Tue, 21 Aug 2012 17:11:23 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id F0DBABE84BA; Tue, 21 Aug 2012 17:11:22 +0000 (UTC) Date: Tue, 21 Aug 2012 17:11:21 +0000 (UTC) From: "Bjoern A. Zeeb" To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86a9xobo2c.fsf@ds4.des.no> Message-ID: References: <5031FAAB.9020409@FreeBSD.org> <86a9xobo2c.fsf@ds4.des.no> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1522165586-1345569083=:78446" Cc: FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 17:11:32 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1522165586-1345569083=:78446 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote: > Doug Barton writes: >> Dag-Erling, do you have a timeline for getting started on the >> ldns/unbound import? > > I imported the code into the vendor tree, but did not proceed any > further as there was still no firm consensus at the time. > > I believe the conclusion - to the extent that there was one - was that > people were fine with tossing out BIND and importing ldns to replace the > client bits, as long as we had suitable drop-in replacements for host(1) > and dig(1), but there was no consensus on whether to import unbound. > > I'll start working on getting ldns into head this weekend. I think ldns really is not what we want; can you defer this for a week and we could chat in person, also wtih brooks around, next week? There is a wwaayy larger thing to the picture of resolver libraries, exspecially validating once, which includes standardization, acceptance, application support, etc. and I admit there should be a summary of that on the wiki but isn't yet as some of the things only very last-weekishly materialized for real for us. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. --0-1522165586-1345569083=:78446-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 17:34:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B48FE1065677; Tue, 21 Aug 2012 17:34:46 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 82EA18FC1D; Tue, 21 Aug 2012 17:34:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0M940090261SLB00@smtpauth1.wiscmail.wisc.edu>; Tue, 21 Aug 2012 11:34:40 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-user-nat.icecube.wisc.edu [128.104.255.12]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0M9400FUE61OSE20@smtpauth1.wiscmail.wisc.edu>; Tue, 21 Aug 2012 11:34:37 -0500 (CDT) Date: Tue, 21 Aug 2012 11:34:36 -0500 From: Nathan Whitehorn In-reply-to: <201208210944.31001.jhb@freebsd.org> To: John Baldwin Message-id: <5033B89C.7070201@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.255.12 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.21.162418, SenderIP=128.104.255.12 References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <201208210944.31001.jhb@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, tijl@freebsd.org, Dan McGregor Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 17:34:46 -0000 On 08/21/12 08:44, John Baldwin wrote: > On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: >> On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >>> Hi. >>> >>> I've been working on porting compiler-rt/clang's support for address >>> sanitization (asan) to FreeBSD. So far I have it building and it >>> appears to work properly, however the build system expects to be able >>> to build 32 bit binaries on amd64. >>> >>> amd64 doesn't include i386's machine/foo headers. The included patch >>> is my proposed solution: >>> >>> Add i386 headers to /usr/include/i386, and in machine/foo.h, check if >>> it's a 32 bit build and include the appropriate header from i386. >>> >>> For example machine/ucontext.h will include i386/ucontext.h if >>> compiled with -m32. >>> >>> Thoughts? >>> >>> If anyone's curious about the compiler_rt port, I have it at >>> github.com/dannomac/compiler-rt on the branch named freebsd. >> There was a work by Tijl Coosemans in the similar, but somewhat less hacky >> direction. The headers are moved into sys/x86/include and unified as much >> as possible, while machine/ counterpart includes corresponding header >> from x86/include. >> >> I even lost track of how much more headers is left to convert. In fact, >> not all headers are equal, some are only useful for kernel or base system. >> Also, parts of the critically important headers do not live in machine/ >> at all, e.g. the headers from libm. >> >> The work seems to be stale, do you want to cooperate with Tijl or continue ? > I think we should probably follow Tijl's model since we are on that path. > I originally preferred the /usr/include/i386 approach, but have come around > to Tjil's approach instead. > I just wanted to add that the unified 32/64 header route is where we went on PowerPC (and MIPS?) and it works very well for -m32. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 17:39:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B8D78106564A for ; Tue, 21 Aug 2012 17:39:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6581C14E919; Tue, 21 Aug 2012 17:39:06 +0000 (UTC) Message-ID: <5033C7BB.1040702@FreeBSD.org> Date: Tue, 21 Aug 2012 10:39:07 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <5031FAAB.9020409@FreeBSD.org> <86a9xobo2c.fsf@ds4.des.no> In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 17:39:06 -0000 On 8/21/2012 10:11 AM, Bjoern A. Zeeb wrote: > On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote: > >> Doug Barton writes: >>> Dag-Erling, do you have a timeline for getting started on the >>> ldns/unbound import? >> >> I imported the code into the vendor tree, but did not proceed any >> further as there was still no firm consensus at the time. >> >> I believe the conclusion - to the extent that there was one - was that >> people were fine with tossing out BIND and importing ldns to replace the >> client bits, as long as we had suitable drop-in replacements for host(1) >> and dig(1), but there was no consensus on whether to import unbound. >> >> I'll start working on getting ldns into head this weekend. > > I think ldns really is not what we want; can you defer this for a week > and we could chat in person, also wtih brooks around, next week? > > There is a wwaayy larger thing to the picture of resolver libraries, > exspecially validating once, which includes standardization, > acceptance, application support, etc. and I admit there should be a > summary of that on the wiki but isn't yet as some of the things only > very last-weekishly materialized for real for us. Neither importing ldns nor removing BIND is going to have any effect on the stub resolver library in libc. And if you have much larger plans for resolver libraries, especially validating ones, it would be great if they were discussed IN PUBLIC, so that those of us who know a little something about the topic can be involved in the discussion BEFORE all the decisions are made, and all the balls start rolling. Thanks, Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 18:08:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A35301065670; Tue, 21 Aug 2012 18:08:51 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id F07638FC0C; Tue, 21 Aug 2012 18:08:50 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id EB6CF25D3888; Tue, 21 Aug 2012 18:08:48 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1202EBE84BC; Tue, 21 Aug 2012 18:08:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gJOr2_nJ2bov; Tue, 21 Aug 2012 18:08:45 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9C6A2BE799F; Tue, 21 Aug 2012 18:08:45 +0000 (UTC) Date: Tue, 21 Aug 2012 18:08:44 +0000 (UTC) From: "Bjoern A. Zeeb" To: Doug Barton In-Reply-To: <5033C7BB.1040702@FreeBSD.org> Message-ID: References: <5031FAAB.9020409@FreeBSD.org> <86a9xobo2c.fsf@ds4.des.no> <5033C7BB.1040702@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-344042496-1345572525=:78446" Cc: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 18:08:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-344042496-1345572525=:78446 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 21 Aug 2012, Doug Barton wrote: > On 8/21/2012 10:11 AM, Bjoern A. Zeeb wrote: >> On Tue, 21 Aug 2012, Dag-Erling Smørgrav wrote: >> >>> Doug Barton writes: >>>> Dag-Erling, do you have a timeline for getting started on the >>>> ldns/unbound import? >>> >>> I imported the code into the vendor tree, but did not proceed any >>> further as there was still no firm consensus at the time. >>> >>> I believe the conclusion - to the extent that there was one - was that >>> people were fine with tossing out BIND and importing ldns to replace the >>> client bits, as long as we had suitable drop-in replacements for host(1) >>> and dig(1), but there was no consensus on whether to import unbound. >>> >>> I'll start working on getting ldns into head this weekend. >> >> I think ldns really is not what we want; can you defer this for a week >> and we could chat in person, also wtih brooks around, next week? >> >> There is a wwaayy larger thing to the picture of resolver libraries, >> exspecially validating once, which includes standardization, >> acceptance, application support, etc. and I admit there should be a >> summary of that on the wiki but isn't yet as some of the things only >> very last-weekishly materialized for real for us. > > Neither importing ldns nor removing BIND is going to have any effect on > the stub resolver library in libc. Yes it does as if we are not carefull, we'll neither have a _proper_ validating caching resolver but 4 different resolver libraries 3 of which needing crypto and only 2 with a well known support plan and only 2 with the same interface in base. Can you see why Simon's question is important to not make the current problem worse? (rhetorical for you, Des will answer). Can we make sure if we do this that things like portsnap and freebsd-update will not stop working (using the command line tools for example)? Can we have a longer plan of where we want to be in a year, which parts we need from where and how to get them, and if we feel like it, add names to this? It's strange that others in this thread have asked for it already, not just me yelling "stop". > And if you have much larger plans for resolver libraries, especially > validating ones, it would be great if they were discussed IN PUBLIC, so > that those of us who know a little something about the topic can be > involved in the discussion BEFORE all the decisions are made, and all > the balls start rolling. Do you understand the part about the wiki from above? I can put an ACL on to exclude everyone but the secret cabal, having investigated days the last 18 months on the topic, talked to people on multiple continents, from different projects, ... but I hadn't planned to .. and I am not the only one. The fact that it's not written down is, as I said, things are only no longer totally nebulous since last week. Given the only thing you currently want to do is getting rid of solving the problem of no longer maintaing named in base (which I think no one disagrees with per se) but do not want to invest in any of the other work, I'd highly appreciate a lower noise level so others could in fact move forward in a more productive way. I could have started the wiki page rather than replying for example. Thanks. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. --0-344042496-1345572525=:78446-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 21 18:56:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 5580C1065678 for ; Tue, 21 Aug 2012 18:56:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 22B5914DACE; Tue, 21 Aug 2012 18:56:21 +0000 (UTC) Message-ID: <5033D9D7.808@FreeBSD.org> Date: Tue, 21 Aug 2012 11:56:23 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <5031FAAB.9020409@FreeBSD.org> <86a9xobo2c.fsf@ds4.des.no> <5033C7BB.1040702@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Hackers Subject: Re: Replacing BIND with unbound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 18:56:27 -0000 On 8/21/2012 11:08 AM, Bjoern A. Zeeb wrote: > On Tue, 21 Aug 2012, Doug Barton wrote: >> Neither importing ldns nor removing BIND is going to have any effect on >> the stub resolver library in libc. > > Yes it does as if we are not carefull, we'll neither have a _proper_ > validating caching resolver but 4 different resolver libraries 3 of > which needing crypto and only 2 with a well known support plan and > only 2 with the same interface in base. Can you please enumerate what resolver libraries you're talking about, because I don't understand what you're referring to here. The way that I'm using the terms above: 1. A validating, caching resolver is a full server type thing, such as BIND or Unbound. 2. The stub resolver library is (as currently implemented) part of libc, and currently uses code from a completely separate import of the BIND resolver library implementation. To be clear, removing src/contrib/bind9 won't affect that at all. 3. ldns _can_ be used to make a resolver library, but it does not have to be. Under the plan that des and I have it would be used as the basis of the dig-like tool called drill, and the host-alike tool that Vitaly provided. It's also a dependency of Unbound, FWIW. I have also said on numerous occasions that I don't think we should have a _single_ validating resolver in the base at all, however I understand that you think differently, which is why you raise the objection above. > Can you see why Simon's question > is important to not make the current problem worse? Of course I understand Simon's question. That's why I answered it. :) > (rhetorical for > you, Des will answer). Can we make sure if we do this that things > like portsnap and freebsd-update will not stop working (using the > command line tools for example)? I've been testing Vitaly's host-alike tool, and haven't run into any problems where the output is different. Obviously we would have to test the dependencies before we pulled BIND out altogether. That's why we are only contemplating doing this in HEAD, long before 10.0-RELEASE. It's also worth pointing out that if we stick to the plan *cough* that we have less than a year before 10-RELEASE, so getting started sooner rather than later here is a good thing. > Can we have a longer plan of where > we want to be in a year, which parts we need from where and how to get > them, and if we feel like it, add names to this? It's strange that > others in this thread have asked for it already, not just me yelling > "stop". But those things have already been discussed, most recently in this thread. Really, you need to pay attention if you want to be involved. :) Plan 0: Import ldns/drill/host-alike, remove BIND. Following which ... Plan A: Allow user to choose from a list of validating resolvers at install time, including at minimum Unbound and BIND. Plan B: Import Unbound Both Plans [AB] involve support for DNSSEC for whatever solutions we make available to the users. IMO in order to be considered for inclusion as a validating resolver the software has to support RFC 5011 rollovers, which means that the difficult part of DNSSEC support is the bootstrapping of the root trust anchor. I have an idea for how I want to do that for BIND in the ports, but lately I have been thinking that it might make more sense to write an rc.d script for the base that can do this in a generic way at boot time. What is definitely *not* going to be acceptable is a hard-coded "set and forget" scheme. We've already seen that fail in another OS, and I don't want to repeat that mistake. >> And if you have much larger plans for resolver libraries, especially >> validating ones, it would be great if they were discussed IN PUBLIC, so >> that those of us who know a little something about the topic can be >> involved in the discussion BEFORE all the decisions are made, and all >> the balls start rolling. > > Do you understand the part about the wiki from above? I can put an > ACL on to exclude everyone but the secret cabal, having investigated > days the last 18 months on the topic, talked to people on multiple > continents, from different projects, ... but I hadn't planned to .. > and I am not the only one. The fact that it's not written down is, > as I said, things are only no longer totally nebulous since last week. I'm sorry, I don't understand most of the paragraph above, but what it sounds like is that you have been talking to people privately about what you think this stuff should look like for 1 1/2 years. I think that's great, but whatever private discussions you may have had don't give you ownership of the problem. This is too important for any one person (myself included) to deal with on their own. Whatever plans we may have in this area need to be thoroughly discussed, IN PUBLIC, before decisions are made, or actions are taken. Not to mention that if the discussion had been public we could potentially have benefited from the ability of many contributors being able to make progress faster than 1 person trying to own the problem solo (no matter how many continents they travel to). > Given the only thing you currently want to do is getting rid of > solving the problem of no longer maintaing named in base (which I > think no one disagrees with per se) but do not want to invest in any > of the other work, That isn't true, and you know it isn't. I was the one who first raised the issue of how important robust DNSSEC support is going to be to re@ (of which you are a member) years ago. I said at the time that I am not only willing, but highly motivated to provide assistance in that area. When you first mentioned your private discussions and plans for a validating resolver in the base in that context a year or so ago, I asked to be included at that time. You have chosen not to do that. So, either you have an incredibly selective memory, or you are blatantly lying in order to make me look bad. I find either option highly disturbing. > I'd highly appreciate a lower noise level so > others could in fact move forward in a more productive way. Um, no, I am definitely NOT going to lower the noise level on this. It's too important. > I could > have started the wiki page rather than replying for example. The fact that you chose one course of action over the other says more about you than it does about me. :) Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 02:07:54 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8BE0106564A; Wed, 22 Aug 2012 02:07:54 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id A1A468FC15; Wed, 22 Aug 2012 02:07:54 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7M27svc020139; Wed, 22 Aug 2012 02:07:54 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7M27r3A020138; Wed, 22 Aug 2012 02:07:53 GMT (envelope-from bde) Date: Wed, 22 Aug 2012 02:07:53 GMT From: Bruce Evans Message-Id: <201208220207.q7M27r3A020138@ref10-i386.freebsd.org> To: marius@alchemy.franken.de, mitya@cabletv.dp.ua In-Reply-To: <20120821102630.GA89551@alchemy.franken.de> Cc: freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 02:07:54 -0000 > On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote: > > Hi. > > I found some overhead code in /src/sys/net/if_ethersubr.c and > > /src/sys/netgraph/ng_ether.c > > > > It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > > When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. Only ng_ether.c contains such strings. if_ethersubr.c doesn't exist. if_ether.c exists, but was converted to use memcpy() 17.25 years ago. > > This code call every time, when we send Ethernet packet. > > On example, on my machine in invoked nearly 20K per second. > > > > Why we are use bcopy(), to copy only 6 bytes? > > Answer - in some architectures we are can not directly copy unaligned data. > > > > I propose this solution. > > > > In file /usr/src/include/net/ethernet.h add this lines: > > > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > > #if defined(__i386__) || defined(__amd64__) > > *dst = *src; > > #else > > bcopy(src, dst, ETHER_ADDR_LEN); > > #endif > > } > > > > On platform i386 gcc produce like this code: > > leal -30(%ebp), %eax > > leal 6(%eax), %ecx > > leal -44(%ebp), %edx > > movl (%edx), %eax > > movl %eax, (%ecx) > > movzwl 4(%edx), %eax > > movw %ax, 4(%ecx) > > And clang produce this: > > movl -48(%ebp), %ecx > > movl %ecx, -26(%ebp) > > movw -44(%ebp), %si > > movw %si, -22(%ebp) > > > > All this variants are much faster, than bcopy() You mean "as much as 5 nanoseconds faster". Possibly even 10 nanoseconds faster. > A bit orthogonal to this but also related to the performance > impact of these bcopy() calls, for !__NO_STRICT_ALIGNMENT > architectures these places probably should use memcpy() > instead as bcopy() additionally has to check for overlap > while the former does not. Overlaps unlikely are an issue > in these cases and at least NetBSD apparently has done the > switch to memcpy() 5.5 years ago. This is essentially just a style bug. FreeBSD switched to memcpy() 17.25 years ago for selected networking copying. memcpy() is supposed to be used if and only if compilers can optimize it. This means that the size must be fixed and small, and of course that the copies don't overlap. Otherwise, compilers can't do any better than call an extern copying routine, which is memcpy() in practice. memcpy() was interntionally left out in FreeBSD until it was added 17.25 years ago to satisfy the changes to use memcpy() in networking code (since with -O0, memcpy() won't be inlined and the extern memcpy() gets used). Other uses are style bugs, but there are many now :-(. bcopy() is still the primary interface, and might be faster than memcpy(), especially for misaligned cases, but in practice it isn't, except in the kernel on Pentium1 in 1996-1998 where I only optimized (large) bcopy()s. Since it has to support overlapping copies it is inherently slower. Although compilers can't do better for large copying than call an extern routine, some compilers bogusly inline it to something like "rep movsd" on i386, (or worse, to a very large number of loads and stores). gcc used to have a very large threshold for inlining moderately-sized copies and/or for switching between "rep movsd" and load/store. It now understands better than ut doesn't understand memory, and has more reasonable thresholds. Or rather the thresholds are more MD. gcc still makes a mess with some CFLAGS: % struct foo % { % short x; % struct bar { % short yy[31]; % } y; % } s, t; % % foo() % { % s.y = t.y; % } With just -O, gcc-4.2.1 -O on i386 handles this very badly, by generating 15 misaligned 32-bit load/stores followed by 1 aligned 16-bit load/store. With -march=, it generates 1 16-bit aligned load-store followed by an aligned "rep movsd" with a count of 15. The latter is not too bad. Similarly for yy[32]. But for yy[33] it switches to a call to memcpy() even with plain -O. However, improvements in memory systems and branch prediction since Pentium1 in 1996-98 mean that optimimizing copying mostly gets nowhere. Copying is either from the cache[s], in which case it is fast (~1 nanosecond per 128 bits for L1), or it is not from the caches in which case it is slow (~50-200 nanseconds per cache miss). With 6-byte ethernet addresses, using bcopy() does slow the copying to considerably below 1 nanosecond per 128 bits (a sloppy estimate gives 5-10 ns/call), but it's hard for a single call to be made often enough to make a significant difference. Someone mentioned 20000 calls. That's the same as 0 calls: 20000 * 10 nsec = 200 usec = 0.05% of 1 CPU. If anyone cared about this, then they would use __builtin_memcpy() instead of memcpy(). (Note that the point of the 17.25-year old optimization has been defeated for ~10 years by turning off _all_ builtins, which was initially done mainly to kill builtin putc(). (-ffreestanding should have done that.) So gcc inlines struct copying for small structs, but never inlines memcpy(), or strlen(), or other unimportant things.) I once used the following to partially fix this, but stopped using it because it made no observable difference: % diff -c2 ./sys/systm.h~ ./sys/systm.h % *** ./sys/systm.h~ Sat Oct 13 12:43:54 2007 % --- ./sys/systm.h Sat Oct 13 12:43:56 2007 % *************** % *** 188,193 **** % --- 188,204 ---- % void bcopy(const void *from, void *to, size_t len) __nonnull(1) __nonnull(2); % void bzero(void *buf, size_t len) __nonnull(1); % + #if 1 % + #define bzero(p, n) ({ \ % + if (__builtin_constant_p(n) && (n) <= 64) \ % + __builtin_memset((p), 0, (n)); \ % + else \ % + (bzero)((p), (n)); \ % + }) % + #endif % % void *memcpy(void *to, const void *from, size_t len) __nonnull(1) __nonnull(2); % + #if 1 % + #define memcpy(to, from, n) __builtin_memcpy((to), (from), (n)) % + #endif % % int copystr(const void * __restrict kfaddr, void * __restrict kdaddr, In another set of dead patches, I changed lots of memcpy()s in networking code to __builtin_memcpy()'s. There is another set of style bugs and micro-pessimizations involving other mem* functions starting with bzero(). The above avoids the micro-pessimizations for the usual case of memset() to 0, at a cost of rewarding the style bug. Summary: use builtin memcpy() for small copies, and don't try hard to otherwise optimize this. Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 02:25:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46558106564A; Wed, 22 Aug 2012 02:25:23 +0000 (UTC) (envelope-from danismostlikely@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C92A8FC17; Wed, 22 Aug 2012 02:25:22 +0000 (UTC) Received: by vbmv11 with SMTP id v11so701702vbm.13 for ; Tue, 21 Aug 2012 19:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nRJZRWS5CM8Zndn0aMcG0zZk22aRPsMKmGkCB05rgwM=; b=k28gMbYbbDvGEzdP7SdlvaapYUGxcDznwVlJTYhmVV2FHU0f4GbUKevKJEr4s3Li9B GMEEE07uCy2lgkqV9NFfz3Z1Ua6aGnwTqzXJUY0GSN7bplh5VUJi3jmbpYQ/8WmY3w75 2+7eZndZdVCKosVDtvAKUtedrEcd21h2XVDbaERwRB2J2YL9KNEQzF+DeNbW/yC4BHbP hrHNt1BfYlOsoo5uAUJ/6tizfUNjKJXwvzWDpNqTDiZ4a1do/CM7rkDEwp/BR5lZEQDW Y154zoEnvc/LJO7uJO6wSdtubSY66rEvAOcNpdRan8YYBoW4bhXbq34avOLzY6KDkBtq ZdZQ== MIME-Version: 1.0 Received: by 10.52.67.7 with SMTP id j7mr13070586vdt.91.1345602321493; Tue, 21 Aug 2012 19:25:21 -0700 (PDT) Received: by 10.58.91.169 with HTTP; Tue, 21 Aug 2012 19:25:21 -0700 (PDT) In-Reply-To: <5033B89C.7070201@freebsd.org> References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <201208210944.31001.jhb@freebsd.org> <5033B89C.7070201@freebsd.org> Date: Tue, 21 Aug 2012 20:25:21 -0600 Message-ID: From: Dan McGregor To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, tijl@freebsd.org Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 02:25:23 -0000 How do the unified powerpc headers work? Is it just one architecture for both PowerPC and 64 bit PowerPC? If so, was that tijl's ultimate goal? One architecture for i386 and AMD64? On the unifying headers front, I've make a bunch of progress towards merging i386 and amd64 headers into x86; also available on github. Dan On 21 August 2012 10:34, Nathan Whitehorn wrote: > On 08/21/12 08:44, John Baldwin wrote: >> >> On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: >>> >>> On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >>>> >>>> Hi. >>>> >>>> I've been working on porting compiler-rt/clang's support for address >>>> sanitization (asan) to FreeBSD. So far I have it building and it >>>> appears to work properly, however the build system expects to be able >>>> to build 32 bit binaries on amd64. >>>> >>>> amd64 doesn't include i386's machine/foo headers. The included patch >>>> is my proposed solution: >>>> >>>> Add i386 headers to /usr/include/i386, and in machine/foo.h, check if >>>> it's a 32 bit build and include the appropriate header from i386. >>>> >>>> For example machine/ucontext.h will include i386/ucontext.h if >>>> compiled with -m32. >>>> >>>> Thoughts? >>>> >>>> If anyone's curious about the compiler_rt port, I have it at >>>> github.com/dannomac/compiler-rt on the branch named freebsd. >>> >>> There was a work by Tijl Coosemans in the similar, but somewhat less >>> hacky >>> direction. The headers are moved into sys/x86/include and unified as much >>> as possible, while machine/ counterpart includes corresponding header >>> from x86/include. >>> >>> I even lost track of how much more headers is left to convert. In fact, >>> not all headers are equal, some are only useful for kernel or base >>> system. >>> Also, parts of the critically important headers do not live in machine/ >>> at all, e.g. the headers from libm. >>> >>> The work seems to be stale, do you want to cooperate with Tijl or >>> continue ? >> >> I think we should probably follow Tijl's model since we are on that path. >> I originally preferred the /usr/include/i386 approach, but have come >> around >> to Tjil's approach instead. >> > > I just wanted to add that the unified 32/64 header route is where we went on > PowerPC (and MIPS?) and it works very well for -m32. > -Nathan > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 02:32:21 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC9871065672; Wed, 22 Aug 2012 02:32:21 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id C7E948FC0A; Wed, 22 Aug 2012 02:32:21 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7M2WLmY020205; Wed, 22 Aug 2012 02:32:21 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7M2WLCL020204; Wed, 22 Aug 2012 02:32:21 GMT (envelope-from bde) Date: Wed, 22 Aug 2012 02:32:21 GMT From: Bruce Evans Message-Id: <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> To: marius@alchemy.franken.de, rizzo@iet.unipi.it In-Reply-To: <20120821112415.GA50078@onelab2.iet.unipi.it> Cc: freebsd-hackers@FreeBSD.org, mitya@cabletv.dp.ua, freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 02:32:22 -0000 luigi wrote: > even more orthogonal: > > I found that copying 8n + (5, 6 or 7) bytes was much much slower than > copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, > other cases are slow (turned into 2 or 3 different writes). > > The netmap code uses a pkt_copy routine that does exactly this > rounding, gaining some 10-20ns per packet for small sizes. I don't believe 10-20ns for just the extra bytes. memcpy() ends up with a movsb to copy the extra bytes. This can be slow, but I don't believe 10-20ns (except on machines running at i486 speeds of course). % ENTRY(memcpy) % pushl %edi % pushl %esi % movl 12(%esp),%edi % movl 16(%esp),%esi % movl 20(%esp),%ecx % movl %edi,%eax % shrl $2,%ecx /* copy by 32-bit words */ % cld /* nope, copy forwards */ % rep % movsl % movl 20(%esp),%ecx % andl $3,%ecx /* any bytes left? */ This avoids a branch. Some optimization manuals say that the branch is actually better for some machines, The above 2 instructions have a throughput of 1 per cycle each on modern x86. Latency might be 6 cycles. % rep Maybe 5-15 cycles throughput. % movsb Now hopefully at most 1 cycle/byte. Some hardware might combine the bytes as much as possible, so the whole function should use 1 single "rep movsb" and let the hardware do it all. % popl %esi % popl %edi % ret Well, it's easy to get a latency of 20 cycles 5-10 ns) and maybe even a throughput of that. But all of thus is out of order on modern x86. The extra cycles for the movsb might not cost at all if nothing accesses the part of the target that they were written to soon. With builtin memcpy, 6 bytes would be done using load/store of 4+2 bytes and thus take the same time as 8 bytes on i386, but on amd64 8 bytes would be faster. Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 02:55:55 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05D571065674; Wed, 22 Aug 2012 02:55:55 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id 9879C8FC0C; Wed, 22 Aug 2012 02:55:54 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7M2tsAZ020281; Wed, 22 Aug 2012 02:55:54 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7M2tsxa020280; Wed, 22 Aug 2012 02:55:54 GMT (envelope-from bde) Date: Wed, 22 Aug 2012 02:55:54 GMT From: Bruce Evans Message-Id: <201208220255.q7M2tsxa020280@ref10-i386.freebsd.org> To: freebsd-hackers@FreeBSD.org, jhb@FreeBSD.org In-Reply-To: <201208210943.08341.jhb@freebsd.org> Cc: freebsd-net@FreeBSD.org, mitya@cabletv.dp.ua Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 02:55:55 -0000 jhb wrote: > On Monday, August 20, 2012 10:46:12 am Mitya wrote: > > ... > > I propose this solution. > > > > In file /usr/src/include/net/ethernet.h add this lines: > > > > static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) { > > #if defined(__i386__) || defined(__amd64__) > > *dst = *src; > > #else > > bcopy(src, dst, ETHER_ADDR_LEN); > > #endif > > } > > Doesn't '*dst = *src' just work on all platforms? It does when you have an actual struct, but often in networking code you only have an array of bytes, and then casting the pointers from uint8_t * to full object pointers fails iff there is an alignment problem. Even on i386, it may be pessimal to use struct copying for 6 bytes, The bytes should be copied as 4+2 or 2+4 depending on alignment of the first bytes. Oops, not even that -- this reminds me of a problem with penalties for mismatched loads and stores which affects at least AthlonXP and Athlon64 significantly (10-20 cycle penalty = enough to copy 80-160 bytes unpenalized). The 6 should probably be copied as 2+2+2 or even as 1+1+1+1+1+1 to match previous stores and later loads, also as 2+2+2, etc. But if the 6 are part of another struct, they might be accessed as 8+0 or 4+4 as part of copying the full struct. gcc is not smart about this. Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 03:17:02 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 472A9106566B; Wed, 22 Aug 2012 03:17:02 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 138178FC1C; Wed, 22 Aug 2012 03:17:01 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:57620 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1T41RE-0005HT-Qb; Tue, 21 Aug 2012 23:17:01 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: George Neville-Neil In-Reply-To: Date: Tue, 21 Aug 2012 23:17:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2533EA82-0ACA-48B1-B56D-A3B922A02CF3@freebsd.org> References: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1485) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org Cc: arm@freebsd.org, arch@freebsd.org, hackers@freebsd.org Subject: Re: projects/armv6 merged to HEAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 03:17:02 -0000 On Aug 17, 2012, at 05:24 , Robert Watson wrote: >=20 > On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: >=20 >> projects/armv6 branch was merged to HEAD and should be considered = dead now. This patch is a result of a joint effort by many people. = Including but not limited to: >=20 > Amazing work -- many thanks are due to to everyone who was involved! >=20 And this ought to simplify work on both the Rasberry Pi and BeagleBone, = as well as the rest of the arm systems. Great! Best, George From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 08:00:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75BE0106564A; Wed, 22 Aug 2012 08:00:49 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE388FC08; Wed, 22 Aug 2012 08:00:49 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7M80n3q021456; Wed, 22 Aug 2012 08:00:49 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7M80m08021455; Wed, 22 Aug 2012 08:00:48 GMT (envelope-from bde) Date: Wed, 22 Aug 2012 08:00:48 GMT From: Bruce Evans Message-Id: <201208220800.q7M80m08021455@ref10-i386.freebsd.org> To: bde@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, mitya@cabletv.dp.ua In-Reply-To: <50347CAB.30309@cabletv.dp.ua> Cc: Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 08:00:49 -0000 mitya wrote: > 22.08.2012 05:07, Bruce Evans íàïèñàë: > >> On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote: > >>> Hi. > >>> I found some overhead code in /src/sys/net/if_ethersubr.c and > >>> /src/sys/netgraph/ng_ether.c > >>> > >>> It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN); > >>> When src and dst are "struct ether_addr*", and ETHER_ADDR_LEN equal 6. > > Only ng_ether.c contains such strings. if_ethersubr.c doesn't exist. > > if_ether.c exists, but was converted to use memcpy() 17.25 years ago. Oops, if_ethersubr.c does exist (in net/. if_ether.c is a misnamed file in netinet/). > > Summary: use builtin memcpy() for small copies, and don't try hard to > > otherwise optimize this. > You are very surprised to learn that bcopy() and memcpy() are used for > copy "struct in_addr", whose length is equal to 4 bytes ? > I found this in sys/netinet/if_ether.c. And I think, there is a chance > to find them in other files. Since memcpy() is the correct method, us of it is only slightly surprising. Use of bcopy() is a regression. Bugs are never surprising :-). > And I found bzero(mtod(m, void *), sizeof(struct in_addr)); in ip_options.c Speed of options processing isn't important. Anyway, I dug out some of my old unimportant fixes for some of the copying pessimizations: % diff -c2 ./net/if_ethersubr.c~ ./net/if_ethersubr.c % *** ./net/if_ethersubr.c~ Wed Dec 27 10:49:51 2006 % --- ./net/if_ethersubr.c Wed Dec 27 10:49:52 2006 % *************** % *** 253,257 **** % hdrcmplt = 1; % eh = (struct ether_header *)dst->sa_data; % ! (void)memcpy(esrc, eh->ether_shost, sizeof (esrc)); % /* FALLTHROUGH */ % % --- 253,257 ---- % hdrcmplt = 1; % eh = (struct ether_header *)dst->sa_data; % ! __builtin_memcpy(esrc, eh->ether_shost, sizeof(esrc)); % /* FALLTHROUGH */ % Not the right fix (except to fix the style bug (cast to void)). memcpy() should be used, and then if the builtin is good then it shoukd be used. % *************** % *** 259,263 **** % loop_copy = 0; /* if this is for us, don't do it */ % eh = (struct ether_header *)dst->sa_data; % ! (void)memcpy(edst, eh->ether_dhost, sizeof (edst)); % type = eh->ether_type; % break; % --- 259,263 ---- % loop_copy = 0; /* if this is for us, don't do it */ % eh = (struct ether_header *)dst->sa_data; % ! __builtin_memcpy(edst, eh->ether_dhost, sizeof(edst)); % type = eh->ether_type; % break; % *************** % *** 276,288 **** % senderr(ENOBUFS); % eh = mtod(m, struct ether_header *); % ! (void)memcpy(&eh->ether_type, &type, % ! sizeof(eh->ether_type)); % ! (void)memcpy(eh->ether_dhost, edst, sizeof (edst)); % if (hdrcmplt) % ! (void)memcpy(eh->ether_shost, esrc, % ! sizeof(eh->ether_shost)); % else % ! (void)memcpy(eh->ether_shost, IF_LLADDR(ifp), % ! sizeof(eh->ether_shost)); % % /* % --- 276,287 ---- % senderr(ENOBUFS); % eh = mtod(m, struct ether_header *); % ! __builtin_memcpy(&eh->ether_type, &type, sizeof(eh->ether_type)); % ! __builtin_memcpy(eh->ether_dhost, edst, sizeof(edst)); % if (hdrcmplt) % ! __builtin_memcpy(eh->ether_shost, esrc, % ! sizeof(eh->ether_shost)); % else % ! __builtin_memcpy(eh->ether_shost, IF_LLADDR(ifp), % ! sizeof(eh->ether_shost)); % % /* Larger style fixes. Non-style fixes/breakages are in the z subdir: % diff -c2 ./net/z/if_ethersubr.c~ ./net/z/if_ethersubr.c % *** ./net/z/if_ethersubr.c~ Wed Dec 27 10:49:51 2006 % --- ./net/z/if_ethersubr.c Wed Dec 27 20:28:06 2006 % *************** % *** 191,197 **** % % if (m->m_flags & M_BCAST) % ! bcopy(ifp->if_broadcastaddr, edst, ETHER_ADDR_LEN); % else % ! bcopy(ar_tha(ah), edst, ETHER_ADDR_LEN); % % } % --- 191,198 ---- % % if (m->m_flags & M_BCAST) % ! __builtin_memcpy(edst, ifp->if_broadcastaddr, % ! sizeof(edst)); % else % ! __builtin_memcpy(edst, ar_tha(ah), sizeof(edst)); % % } bcopy() can't be replaced by a builtin since it is required to handle overlapping copies, which I think can't happen here (but I didn't check this). The builtin shouldn't be hard-coded like this, as above. % *************** % *** 214,219 **** % } else % type = htons(ETHERTYPE_IPX); % ! bcopy((caddr_t)&(((struct sockaddr_ipx *)dst)->sipx_addr.x_host), % ! (caddr_t)edst, sizeof (edst)); % break; % #endif % --- 215,221 ---- % } else % type = htons(ETHERTYPE_IPX); % ! __buitin_memcpy(edst, % ! &(((struct sockaddr_ipx *)dst)->sipx_addr.x_host), % ! sizeof(edst)); % break; % #endif As above, plus fix grosser style bugs (use of caddr_t. bcopy() hasn't take args of type caddr_t for more than 20 years). % *************** % *** 238,244 **** % llc.llc_dsap = llc.llc_ssap = LLC_SNAP_LSAP; % llc.llc_control = LLC_UI; % ! bcopy(at_org_code, llc.llc_snap_org_code, sizeof(at_org_code)); % llc.llc_snap_ether_type = htons( ETHERTYPE_AT ); % ! bcopy(&llc, mtod(m, caddr_t), LLC_SNAPFRAMELEN); % type = htons(m->m_pkthdr.len); % hlen = LLC_SNAPFRAMELEN + ETHER_HDR_LEN; % --- 240,247 ---- % llc.llc_dsap = llc.llc_ssap = LLC_SNAP_LSAP; % llc.llc_control = LLC_UI; % ! __builtin_memcpy(llc.llc_snap_org_code, at_org_code, % ! sizeof(at_org_code)); % llc.llc_snap_ether_type = htons( ETHERTYPE_AT ); % ! __builtin_memcpy(mtod(m, caddr_t), &llc, LLC_SNAPFRAMELEN); % type = htons(m->m_pkthdr.len); % hlen = LLC_SNAPFRAMELEN + ETHER_HDR_LEN; % *************** % *** 253,257 **** % hdrcmplt = 1; % eh = (struct ether_header *)dst->sa_data; % ! (void)memcpy(esrc, eh->ether_shost, sizeof (esrc)); % /* FALLTHROUGH */ % % --- 256,260 ---- % hdrcmplt = 1; % eh = (struct ether_header *)dst->sa_data; % ! __builtin_memcpy(esrc, eh->ether_shost, sizeof(esrc)); % /* FALLTHROUGH */ % % *************** % *** 259,263 **** % loop_copy = 0; /* if this is for us, don't do it */ % eh = (struct ether_header *)dst->sa_data; % ! (void)memcpy(edst, eh->ether_dhost, sizeof (edst)); % type = eh->ether_type; % break; % --- 262,266 ---- % loop_copy = 0; /* if this is for us, don't do it */ % eh = (struct ether_header *)dst->sa_data; % ! __builtin_memcpy(edst, eh->ether_dhost, sizeof(edst)); % type = eh->ether_type; % break; % *************** % *** 276,288 **** % senderr(ENOBUFS); % eh = mtod(m, struct ether_header *); % ! (void)memcpy(&eh->ether_type, &type, % ! sizeof(eh->ether_type)); % ! (void)memcpy(eh->ether_dhost, edst, sizeof (edst)); % if (hdrcmplt) % ! (void)memcpy(eh->ether_shost, esrc, % ! sizeof(eh->ether_shost)); % else % ! (void)memcpy(eh->ether_shost, IF_LLADDR(ifp), % ! sizeof(eh->ether_shost)); % % /* % --- 279,290 ---- % senderr(ENOBUFS); % eh = mtod(m, struct ether_header *); % ! __builtin_memcpy(&eh->ether_type, &type, sizeof(eh->ether_type)); % ! __builtin_memcpy(eh->ether_dhost, edst, sizeof(edst)); % if (hdrcmplt) % ! __builtin_memcpy(eh->ether_shost, esrc, % ! sizeof(eh->ether_shost)); % else % ! __builtin_memcpy(eh->ether_shost, IF_LLADDR(ifp), % ! sizeof(eh->ether_shost)); % % /* % *************** % *** 454,459 **** % } % if (eh != mtod(m, struct ether_header *)) % ! bcopy(&save_eh, mtod(m, struct ether_header *), % ! ETHER_HDR_LEN); % } % *m0 = m; % --- 456,461 ---- % } % if (eh != mtod(m, struct ether_header *)) % ! __builtin_memcpy(mtod(m, struct ether_header *), % ! &save_eh, sizeof(struct ether_header)); % } % *m0 = m; % *************** % *** 1028,1034 **** % IF_LLADDR(ifp); % else { % ! bcopy((caddr_t) ina->x_host.c_host, % ! (caddr_t) IF_LLADDR(ifp), % ! ETHER_ADDR_LEN); % } % % --- 1030,1035 ---- % IF_LLADDR(ifp); % else { % ! __builtin_memcpy(IF_LLADDR(ifp), % ! ina->x_host.c_host, ETHER_ADDR_LEN); % } % % *************** % *** 1050,1056 **** % struct sockaddr *sa; % % ! sa = (struct sockaddr *) & ifr->ifr_data; % ! bcopy(IF_LLADDR(ifp), % ! (caddr_t) sa->sa_data, ETHER_ADDR_LEN); % } % break; % --- 1051,1057 ---- % struct sockaddr *sa; % % ! sa = (struct sockaddr *)&ifr->ifr_data; % ! __builtin_memcpy(sa->sa_data, IF_LLADDR(ifp), % ! ETHER_ADDR_LEN); % } % break; % *************** % *** 1208,1212 **** % KASSERT(m->m_len >= sizeof(struct ether_header), % ("%s: mbuf not large enough for header", __func__)); % ! bcopy(mtod(m, char *), &vlan, sizeof(struct ether_header)); % vlan.evl_proto = vlan.evl_encap_proto; % vlan.evl_encap_proto = htons(ETHERTYPE_VLAN); % --- 1209,1213 ---- % KASSERT(m->m_len >= sizeof(struct ether_header), % ("%s: mbuf not large enough for header", __func__)); % ! __builtin_memcpy(&vlan, mtod(m, char *), sizeof(&vlan)); % vlan.evl_proto = vlan.evl_encap_proto; % vlan.evl_encap_proto = htons(ETHERTYPE_VLAN); This is supposed to fix all the bcopy()'s and (mis)rename all the memcpy()'s use by a UDP throughput benchmark, and any nearby that were easy to change. Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 10:39:18 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AD601065672; Wed, 22 Aug 2012 10:39:18 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id BE0E08FC08; Wed, 22 Aug 2012 10:39:17 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q7MAdB08011468; Wed, 22 Aug 2012 11:39:11 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <2533EA82-0ACA-48B1-B56D-A3B922A02CF3@freebsd.org> Date: Wed, 22 Aug 2012 11:39:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3440928F-900B-4894-BCFE-5E738B644D59@gid.co.uk> References: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> <2533EA82-0ACA-48B1-B56D-A3B922A02CF3@freebsd.org> To: George Neville-Neil X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org, Oleksandr Tymoshenko , hackers@freebsd.org, arch@freebsd.org Subject: Re: projects/armv6 merged to HEAD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:39:18 -0000 On 22 Aug 2012, at 04:17, George Neville-Neil wrote: >=20 > On Aug 17, 2012, at 05:24 , Robert Watson wrote: >=20 >>=20 >> On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: >>=20 >>> projects/armv6 branch was merged to HEAD and should be considered = dead now. This patch is a result of a joint effort by many people. = Including but not limited to: >>=20 >> Amazing work -- many thanks are due to to everyone who was involved! >>=20 >=20 > And this ought to simplify work on both the Rasberry Pi and = BeagleBone, as well as the > rest of the arm systems. Great! What he said. Big thanks to all concerned! -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 12:46:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F20B106566C; Wed, 22 Aug 2012 12:46:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9DF8FC15; Wed, 22 Aug 2012 12:46:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 683ADB95D; Wed, 22 Aug 2012 08:46:17 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 22 Aug 2012 08:02:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208220802.14588.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 Aug 2012 08:46:17 -0400 (EDT) Cc: Wojciech Puchar , Adrian Chadd , Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 12:46:18 -0000 On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > Hi, > > What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > in a relevant include file, then hide the ugliness there? > > The same benefits will likely appear when copying wifi MAC addresses > to/from headers. > > Thanks, I'm glad someone noticed this. I doubt we even _need_ the ugliness. We should just use *dst = *src unless there is a compelling reason not to. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 13:26:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E95A106564A for ; Wed, 22 Aug 2012 13:26:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 182078FC1B for ; Wed, 22 Aug 2012 13:26:40 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1525179pbb.13 for ; Wed, 22 Aug 2012 06:26:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=cNzWHgU9ZibzOlCTJUGq2Bl4M+lRChyXB/vpy0ofcTg=; b=MQuomDCVJGcK/cIa01cJeLs91taE4wxsrd7GIULu9wFyb6WCh5toGvDbKtq9Vd6MaD +FddBcg5EdFQ1bQwRUY27Tc9S7W8suqe+ORstA5ktrv7G67vnI91+G/AiB4Icx6UNmid C/uDlWC11xgVN4PoApn/6BwS7PI88va8lgvN1M3EJyI65tH9rqgPEElQ9kKN9/Y0TCfO oArE83731vgCJ4WooPwl8Fe+yygd0oCG44b0dp5O3saDDGgIvaH3UUytwXbzVqu8ori+ IC/3yZ2T+s4clrN53hUDlgYVcg7uUplq8vOZK0fHceukWS+DL9vLqxn1/FMMa3+AnED2 V6eA== Received: by 10.66.86.166 with SMTP id q6mr45967443paz.83.1345642000454; Wed, 22 Aug 2012 06:26:40 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id hx9sm3710761pbc.68.2012.08.22.06.26.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 06:26:37 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201208220802.14588.jhb@freebsd.org> Date: Wed, 22 Aug 2012 07:26:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2DB48390-4FB8-49ED-A176-CF593ED57502@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> <201208220802.14588.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnMvKR2EzvDaGunu/4ka6nomGFFvbQVfETeHXPfpGPXa7iFgY7SdMeR0hhQ/0hw5E73QvtH Cc: freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-net@freebsd.org, Mitya , Wojciech Puchar Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 13:26:41 -0000 On Aug 22, 2012, at 6:02 AM, John Baldwin wrote: > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: >> Hi, >>=20 >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting = that >> in a relevant include file, then hide the ugliness there? >>=20 >> The same benefits will likely appear when copying wifi MAC addresses >> to/from headers. >>=20 >> Thanks, I'm glad someone noticed this. >=20 > I doubt we even _need_ the ugliness. We should just use *dst =3D *src > unless there is a compelling reason not to. Agreed. We should do that, and then check the generated code to be sure = there isn't a compelling reason there :) Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 14:17:26 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BFA31065676; Wed, 22 Aug 2012 14:17:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B2CD68FC17; Wed, 22 Aug 2012 14:17:25 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5D42E7300A; Wed, 22 Aug 2012 16:36:32 +0200 (CEST) Date: Wed, 22 Aug 2012 16:36:32 +0200 From: Luigi Rizzo To: Bruce Evans Message-ID: <20120822143632.GA64686@onelab2.iet.unipi.it> References: <20120821112415.GA50078@onelab2.iet.unipi.it> <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, mitya@cabletv.dp.ua, marius@alchemy.franken.de Subject: speed tests (Re: Replace bcopy() to update ether_addr) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:17:26 -0000 On Wed, Aug 22, 2012 at 02:32:21AM +0000, Bruce Evans wrote: > luigi wrote: > > > even more orthogonal: > > > > I found that copying 8n + (5, 6 or 7) bytes was much much slower than > > copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, > > other cases are slow (turned into 2 or 3 different writes). > > > > The netmap code uses a pkt_copy routine that does exactly this > > rounding, gaining some 10-20ns per packet for small sizes. > > I don't believe 10-20ns for just the extra bytes. memcpy() ends up > with a movsb to copy the extra bytes. This can be slow, but I don't > believe 10-20ns (except on machines running at i486 speeds of course). I am adding at the end a test program so people can try things on their hw. Build it with cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock and on my i7 i get these results: ./testlock -m memcpy -l 7 -> ~23 Mops/s 43 ns/cycle ./testlock -m bcopy -l 7 -> ~10 Mops/sA 100 ns/cycle ./testlock -m fastcopy -l 7 -> ~64 Mops/s 16 ns/cycle (fastcopy rounds to the next multiple of 8) Changing the length (-l ...) changes the speed, of course. For some reason my machine is fast for 8n+(0,1,2,3) and slow for 8n+(4,5,6,7). cheers luigi -------------------- /* * Copyright (C) 2012 Luigi Rizzo. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ /* * $Id: testlock.c 11731 2012-08-22 14:19:50Z luigi $ * * Test program to study various ops and concurrency issues. * Create multiple threads, possibly bind to cpus, and run a workload. * * cc -O2 -Werror -Wall testlock.c -o testlock -lpthread * you might need -lrt */ #include #include #include /* pthread_* */ #if defined(__APPLE__) #include #define atomic_add_int(p, n) OSAtomicAdd32(n, (int *)p) #define atomic_cmpset_32(p, o, n) OSAtomicCompareAndSwap32(o, n, (int *)p) #elif defined(linux) int atomic_cmpset_32(volatile uint32_t *p, uint32_t old, uint32_t new) { int ret = *p == old; *p = new; return ret; } #if defined(HAVE_GCC_ATOMICS) int atomic_add_int(volatile int *p, int v) { return __sync_fetch_and_add(p, v); } #else inline uint32_t atomic_add_int(uint32_t *p, int v) { __asm __volatile ( " lock xaddl %0, %1 ; " : "+r" (v), /* 0 (result) */ "=m" (*p) /* 1 */ : "m" (*p)); /* 2 */ return (v); } #endif #else /* FreeBSD */ #include #include #include /* pthread w/ affinity */ #if __FreeBSD_version > 500000 #include /* cpu_set */ #if __FreeBSD_version > 800000 #define HAVE_AFFINITY #endif inline void prefetch (const void *x) { __asm volatile("prefetcht0 %0" :: "m" (*(const unsigned long *)x)); } #else /* FreeBSD 4.x */ int atomic_cmpset_32(volatile uint32_t *p, uint32_t old, uint32_t new) { int ret = *p == old; *p = new; return ret; } #define PRIu64 "llu" #endif /* FreeBSD 4.x */ #endif /* FreeBSD */ #include /* signal */ #include #include #include #include /* PRI* macros */ #include /* strcmp */ #include /* open */ #include /* getopt */ #include /* sysctl */ #include /* timersub */ static inline int min(int a, int b) { return a < b ? a : b; } #define ONE_MILLION 1000000 /* debug support */ #define ND(format, ...) #define D(format, ...) \ fprintf(stderr, "%s [%d] " format "\n", \ __FUNCTION__, __LINE__, ##__VA_ARGS__) int verbose = 0; #if 1//def MY_RDTSC /* Wrapper around `rdtsc' to take reliable timestamps flushing the pipeline */ #define my_rdtsc(t) \ do { \ u_int __regs[4]; \ \ do_cpuid(0, __regs); \ (t) = rdtsc(); \ } while (0) static __inline void do_cpuid(u_int ax, u_int *p) { __asm __volatile("cpuid" : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3]) : "0" (ax) ); } static __inline uint64_t rdtsc(void) { uint64_t rv; // XXX does not work on linux-64 bit __asm __volatile("rdtscp" : "=A" (rv) : : "%rax"); return (rv); } #endif /* 1 */ struct targ; /*** global arguments for all threads ***/ struct glob_arg { struct { uint32_t ctr[1024]; } v __attribute__ ((aligned(256) )); int m_cycles; /* million cycles */ int nthreads; int cpus; int privs; // 1 if has IO privileges int arg; // microseconds in usleep char *test_name; void (*fn)(struct targ *); uint64_t scale; // scaling factor char *scale_name; // scaling factor }; /* * Arguments for a new thread. */ struct targ { struct glob_arg *g; int completed; u_int *glob_ctr; uint64_t volatile count; struct timeval tic, toc; int me; pthread_t thread; int affinity; }; static struct targ *ta; static int global_nthreads; /* control-C handler */ static void sigint_h(int sig) { int i; (void)sig; /* UNUSED */ for (i = 0; i < global_nthreads; i++) { /* cancel active threads. */ if (ta[i].completed) continue; D("Cancelling thread #%d\n", i); pthread_cancel(ta[i].thread); ta[i].completed = 0; } signal(SIGINT, SIG_DFL); } /* sysctl wrapper to return the number of active CPUs */ static int system_ncpus(void) { #ifdef linux return 1; #else int mib[2] = { CTL_HW, HW_NCPU}, ncpus; size_t len = sizeof(mib); sysctl(mib, len / sizeof(mib[0]), &ncpus, &len, NULL, 0); D("system had %d cpus", ncpus); return (ncpus); #endif } /* * try to get I/O privileges so we can execute cli/sti etc. */ int getprivs(void) { int fd = open("/dev/io", O_RDWR); if (fd < 0) { D("cannot open /dev/io, fd %d", fd); return 0; } return 1; } /* set the thread affinity. */ /* ARGSUSED */ #ifdef HAVE_AFFINITY static int setaffinity(pthread_t me, int i) { cpuset_t cpumask; if (i == -1) return 0; /* Set thread affinity affinity.*/ CPU_ZERO(&cpumask); CPU_SET(i, &cpumask); if (pthread_setaffinity_np(me, sizeof(cpuset_t), &cpumask) != 0) { D("Unable to set affinity"); return 1; } return 0; } #endif static void * td_body(void *data) { struct targ *t = (struct targ *) data; #ifdef HAVE_AFFINITY if (0 == setaffinity(t->thread, t->affinity)) #endif { /* main loop.*/ D("testing %d cycles", t->g->m_cycles); gettimeofday(&t->tic, NULL); t->g->fn(t); gettimeofday(&t->toc, NULL); } t->completed = 1; return (NULL); } void test_sel(struct targ *t) { int m; for (m = 0; m < t->g->m_cycles; m++) { fd_set r; struct timeval to = { 0, t->g->arg}; FD_ZERO(&r); FD_SET(0,&r); // FD_SET(1,&r); select(1, &r, NULL, NULL, &to); t->count++; } } void test_poll(struct targ *t) { int m, ms = t->g->arg/1000; for (m = 0; m < t->g->m_cycles; m++) { struct pollfd x; x.fd = 0; x.events = POLLIN; poll(&x, 1, ms); t->count++; } } void test_usleep(struct targ *t) { int m; for (m = 0; m < t->g->m_cycles; m++) { usleep(t->g->arg); t->count++; } } void test_cli(struct targ *t) { int m, i; if (!t->g->privs) { D("%s", "privileged instructions not available"); return; } for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { __asm __volatile("cli;"); __asm __volatile("and %eax, %eax;"); __asm __volatile("sti;"); t->count++; } } } void test_nop(struct targ *t) { int m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { __asm __volatile("nop;"); __asm __volatile("nop; nop; nop; nop; nop;"); //__asm __volatile("nop; nop; nop; nop; nop;"); t->count++; } } } void test_rdtsc1(struct targ *t) { int m, i; uint64_t v; (void)v; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { my_rdtsc(v); t->count++; } } } void test_rdtsc(struct targ *t) { int m, i; volatile uint64_t v; (void)v; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { v = rdtsc(); t->count++; } } } void test_add(struct targ *t) { int m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { t->glob_ctr[0] ++; t->count++; } } } void test_atomic_add(struct targ *t) { int m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { atomic_add_int(t->glob_ctr, 1); t->count++; } } } void test_atomic_cmpset(struct targ *t) { int m, i; for (m = 0; m < t->g->m_cycles; m++) { for (i = 0; i < ONE_MILLION; i++) { atomic_cmpset_32(t->glob_ctr, m, i); t->count++; } } } void test_time(struct targ *t) { int m; for (m = 0; m < t->g->m_cycles; m++) { #ifndef __APPLE__ struct timespec ts; clock_gettime(t->g->arg, &ts); #endif t->count++; } } void test_gettimeofday(struct targ *t) { int m; struct timeval ts; for (m = 0; m < t->g->m_cycles; m++) { gettimeofday(&ts, NULL); t->count++; } } #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) static void fast_bcopy(void *_src, void *_dst, int l) { uint64_t *src = _src; uint64_t *dst = _dst; if (unlikely(l >= 1024)) { bcopy(src, dst, l); return; } for (; likely(l > 0); l-=64) { *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; *dst++ = *src++; } } // XXX if you want to make sure there is no inlining... // static void (*fp)(void *_src, void *_dst, int l) = fast_bcopy; #define HU 0x3ffff static struct glob_arg huge[HU+1]; void test_fastcopy(struct targ *t) { int m, len; len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("fast copying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { fast_bcopy(t->g, (void *)&huge[m & HU], len); t->count+=1; } } void test_bcopy(struct targ *t) { int m, len; len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("bcopying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { __builtin_memcpy(t->g, (void *)&huge[m & HU], len); t->count+=1; } } void test_memcpy(struct targ *t) { int m, len; len = t->g->arg; if (len > (int)sizeof(struct glob_arg)) len = sizeof(struct glob_arg); D("memcopying %d bytes", len); for (m = 0; m < t->g->m_cycles; m++) { memcpy((void *)&huge[m & HU], t->g, len); t->count+=1; } } struct entry { void (*fn)(struct targ *); char *name; uint64_t scale; uint64_t m_cycles; }; struct entry tests[] = { { test_sel, "select", 1, 1000 }, { test_poll, "poll", 1, 1000 }, { test_usleep, "usleep", 1, 1000 }, { test_time, "time", 1, 1000 }, { test_gettimeofday, "gettimeofday", 1, 1000000 }, { test_bcopy, "bcopy", 1, 100000000 }, { test_memcpy, "memcpy", 1, 100000000 }, { test_fastcopy, "fastcopy", 1, 100000000 }, { test_add, "add", ONE_MILLION, 100000000 }, { test_nop, "nop", ONE_MILLION, 100000000 }, { test_atomic_add, "atomic-add", ONE_MILLION, 100000000 }, { test_cli, "cli", ONE_MILLION, 100000000 }, { test_rdtsc, "rdtsc", ONE_MILLION, 100000000 }, // unserialized { test_rdtsc1, "rdtsc1", ONE_MILLION, 100000000 }, // serialized { test_atomic_cmpset, "cmpset", ONE_MILLION, 100000000 }, { NULL, NULL, 0, 0 } }; static void usage(void) { const char *cmd = "test"; int i; fprintf(stderr, "Usage:\n" "%s arguments\n" "\t-m name test name\n" "\t-n cycles (millions) of cycles\n" "\t-l arg bytes, usec, ... \n" "\t-t threads total threads\n" "\t-c cores cores to use\n" "\t-a n force affinity every n cores\n" "\t-A n cache contention every n bytes\n" "\t-w report_ms milliseconds between reports\n" "", cmd); fprintf(stderr, "Available tests:\n"); for (i = 0; tests[i].name; i++) { fprintf(stderr, "%12s\n", tests[i].name); } exit(0); } struct glob_arg g; int main(int argc, char **argv) { int i, ch, report_interval, affinity, align; ND("g has size %d", (int)sizeof(g)); report_interval = 250; /* ms */ affinity = 0; /* no affinity */ align = 0; /* global variable */ bzero(&g, sizeof(g)); g.privs = getprivs(); g.nthreads = 1; g.cpus = 1; g.m_cycles = 0; while ( (ch = getopt(argc, argv, "A:a:m:n:w:c:t:vl:")) != -1) { switch(ch) { default: D("bad option %c %s", ch, optarg); usage(); break; case 'A': /* align */ align = atoi(optarg); break; case 'a': /* force affinity */ affinity = atoi(optarg); break; case 'n': /* cycles */ g.m_cycles = atoi(optarg); break; case 'w': /* report interval */ report_interval = atoi(optarg); break; case 'c': g.cpus = atoi(optarg); break; case 't': g.nthreads = atoi(optarg); break; case 'm': g.test_name = optarg; break; case 'l': g.arg = atoi(optarg); break; case 'v': verbose++; break; } } argc -= optind; argv += optind; if (!g.test_name && argc > 0) g.test_name = argv[0]; if (g.test_name) { for (i = 0; tests[i].name; i++) { if (!strcmp(g.test_name, tests[i].name)) { g.fn = tests[i].fn; g.scale = tests[i].scale; if (g.m_cycles == 0) g.m_cycles = tests[i].m_cycles; if (g.scale == ONE_MILLION) g.scale_name = "M"; else if (g.scale == 1000) g.scale_name = "M"; else { g.scale = 1; g.scale_name = ""; } break; } } } if (!g.fn) { D("%s", "missing/unknown test name"); usage(); } i = system_ncpus(); if (g.cpus < 0 || g.cpus > i) { D("%d cpus is too high, have only %d cpus", g.cpus, i); usage(); } if (g.cpus == 0) g.cpus = i; if (g.nthreads < 1) { D("bad nthreads %d, using 1", g.nthreads); g.nthreads = 1; } i = sizeof(g.v.ctr) / g.nthreads*sizeof(g.v.ctr[0]); if (align < 0 || align > i) { D("bad align %d, max is %d", align, i); align = i; } /* Install ^C handler. */ global_nthreads = g.nthreads; signal(SIGINT, sigint_h); ta = calloc(g.nthreads, sizeof(*ta)); /* * Now create the desired number of threads, each one * using a single descriptor. */ D("start %d threads on %d cores", g.nthreads, g.cpus); for (i = 0; i < g.nthreads; i++) { struct targ *t = &ta[i]; bzero(t, sizeof(*t)); t->g = &g; t->me = i; t->glob_ctr = &g.v.ctr[(i*align)/sizeof(g.v.ctr[0])]; D("thread %d ptr %p", i, t->glob_ctr); t->affinity = affinity ? (affinity*i) % g.cpus : -1; if (pthread_create(&t->thread, NULL, td_body, t) == -1) { D("Unable to create thread %d", i); t->completed = 1; } } /* the main loop */ { uint64_t my_count = 0, prev = 0; uint64_t count = 0; double delta_t; struct timeval tic, toc; gettimeofday(&toc, NULL); for (;;) { struct timeval now, delta; uint64_t pps; int done = 0; delta.tv_sec = report_interval/1000; delta.tv_usec = (report_interval%1000)*1000; select(0, NULL, NULL, NULL, &delta); gettimeofday(&now, NULL); timersub(&now, &toc, &toc); my_count = 0; for (i = 0; i < g.nthreads; i++) { my_count += ta[i].count; if (ta[i].completed) done++; } pps = toc.tv_sec* ONE_MILLION + toc.tv_usec; if (pps < 10000) continue; pps = (my_count - prev)*ONE_MILLION / pps; D("%" PRIu64 " %scycles/s scale %" PRIu64 " in %dus", pps/g.scale, g.scale_name, g.scale, (int)(toc.tv_sec* ONE_MILLION + toc.tv_usec)); prev = my_count; toc = now; if (done == g.nthreads) break; } D("total %" PRIu64 " cycles", prev); timerclear(&tic); timerclear(&toc); for (i = 0; i < g.nthreads; i++) { pthread_join(ta[i].thread, NULL); if (ta[i].completed == 0) continue; /* * Collect threads o1utput and extract information about * how log it took to send all the packets. */ count += ta[i].count; if (!timerisset(&tic) || timercmp(&ta[i].tic, &tic, <)) tic = ta[i].tic; if (!timerisset(&toc) || timercmp(&ta[i].toc, &toc, >)) toc = ta[i].toc; } /* print output. */ timersub(&toc, &tic, &toc); delta_t = toc.tv_sec + 1e-6* toc.tv_usec; D("total %8.6f seconds", delta_t); } return (0); } /* end of file */ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 14:35:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D71CD106564A; Wed, 22 Aug 2012 14:35:22 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 94B468FC18; Wed, 22 Aug 2012 14:35:22 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A75E57300A; Wed, 22 Aug 2012 16:54:29 +0200 (CEST) Date: Wed, 22 Aug 2012 16:54:29 +0200 From: Luigi Rizzo To: Mitya Message-ID: <20120822145429.GB64686@onelab2.iet.unipi.it> References: <20120821112415.GA50078@onelab2.iet.unipi.it> <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> <20120822143632.GA64686@onelab2.iet.unipi.it> <5034EC27.1070203@cabletv.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5034EC27.1070203@cabletv.dp.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: speed tests (Re: Replace bcopy() to update ether_addr) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:35:23 -0000 On Wed, Aug 22, 2012 at 05:26:47PM +0300, Mitya wrote: > 22.08.2012 17:36, Luigi Rizzo ??????????????: > >On Wed, Aug 22, 2012 at 02:32:21AM +0000, Bruce Evans wrote: > >>luigi wrote: > >> > >>>even more orthogonal: > >>> > >>>I found that copying 8n + (5, 6 or 7) bytes was much much slower than > >>>copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, > >>>other cases are slow (turned into 2 or 3 different writes). > >>> > >>>The netmap code uses a pkt_copy routine that does exactly this > >>>rounding, gaining some 10-20ns per packet for small sizes. > >>I don't believe 10-20ns for just the extra bytes. memcpy() ends up > >>with a movsb to copy the extra bytes. This can be slow, but I don't > >>believe 10-20ns (except on machines running at i486 speeds of course). > >I am adding at the end a test program so people can try things on their hw. > > > >Build it with > > > > cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock > > > > > > # uname -a > FreeBSD m18.cabletv.dp.ua 9.0-STABLE FreeBSD 9.0-STABLE #1: Tue Apr 24 > 13:23:05 EEST 2012 root@m18.cabletv.dp.ua:/usr/src/sys/i386/compile/m18 i386 > > cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock > > testlock.c: In function 'test_rdtsc': > testlock.c:151: error: can't find a register in class 'AD_REGS' while > reloading 'asm' > testlock.c:151: error: 'asm' operand has impossible constraints i forgot to mention that i tried this only on amd64, my ASM is horrible. Just comment out the offending lines and do not run those tests. Or, if you have a portable fix, let me know and everybody will appreciate it. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 14:33:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AE87106564A; Wed, 22 Aug 2012 14:33:02 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id F2B988FC14; Wed, 22 Aug 2012 14:33:01 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1T4CSz-000KVR-3d; Wed, 22 Aug 2012 18:03:33 +0300 Message-ID: <5034EC27.1070203@cabletv.dp.ua> Date: Wed, 22 Aug 2012 17:26:47 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: Luigi Rizzo , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <20120821112415.GA50078@onelab2.iet.unipi.it> <201208220232.q7M2WLCL020204@ref10-i386.freebsd.org> <20120822143632.GA64686@onelab2.iet.unipi.it> In-Reply-To: <20120822143632.GA64686@onelab2.iet.unipi.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 22 Aug 2012 15:32:02 +0000 Cc: Subject: Re: speed tests (Re: Replace bcopy() to update ether_addr) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:33:02 -0000 22.08.2012 17:36, Luigi Rizzo напиÑал: > On Wed, Aug 22, 2012 at 02:32:21AM +0000, Bruce Evans wrote: >> luigi wrote: >> >>> even more orthogonal: >>> >>> I found that copying 8n + (5, 6 or 7) bytes was much much slower than >>> copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient, >>> other cases are slow (turned into 2 or 3 different writes). >>> >>> The netmap code uses a pkt_copy routine that does exactly this >>> rounding, gaining some 10-20ns per packet for small sizes. >> I don't believe 10-20ns for just the extra bytes. memcpy() ends up >> with a movsb to copy the extra bytes. This can be slow, but I don't >> believe 10-20ns (except on machines running at i486 speeds of course). > I am adding at the end a test program so people can try things on their hw. > > Build it with > > cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock > > # uname -a FreeBSD m18.cabletv.dp.ua 9.0-STABLE FreeBSD 9.0-STABLE #1: Tue Apr 24 13:23:05 EEST 2012 root@m18.cabletv.dp.ua:/usr/src/sys/i386/compile/m18 i386 cc -O2 -Werror -Wall -Wextra -lpthread -lrt testlock.c -o testlock testlock.c: In function 'test_rdtsc': testlock.c:151: error: can't find a register in class 'AD_REGS' while reloading 'asm' testlock.c:151: error: 'asm' operand has impossible constraints From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 17:03:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3613C1065689 for ; Wed, 22 Aug 2012 17:03:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFACF8FC21 for ; Wed, 22 Aug 2012 17:03:00 +0000 (UTC) Received: by yenl7 with SMTP id l7so1039879yen.13 for ; Wed, 22 Aug 2012 10:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Wj34K4q7YyOGXku0lKk6ZhsDYukgFPNXYgzxyU5n1E4=; b=jyLU65WCDSB0kqg0nejXq+Zw45S+DPl2CqmV9/+WfTHFxX8e2FlHrlN6pRBv85pOFE fI505xZ/gR49GCcAKlOdCb8Q7Xi0qgBGXBR+WAtXM+ujkLWuuSoDUc1nXMEGRPiAiaep 7aJGdqzu/h+NGC80F1ukCQEI4CQ4wHfs7sNmuv/sxrGxi8qKSdG8sVwYLxv28prsMtnz h/+0Zw/zl4DwlRP/fD7MCWGq9ahYQm7RCobHT9RzaVo8JlSOBt8fkw043ZSJ5Cgj/NwO ybkA3T6HoyUr2Q6KlquJginSYwUifSgtUKNFD+MqP/VN3rRexyHTULZzexpTw6iVrwcA 9l1g== Received: by 10.60.172.15 with SMTP id ay15mr1876150oec.64.1345654980026; Wed, 22 Aug 2012 10:03:00 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id el2sm36876obc.8.2012.08.22.10.02.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 10:02:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <5033B89C.7070201@freebsd.org> Date: Wed, 22 Aug 2012 11:02:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <201208210944.31001.jhb@freebsd.org> <5033B89C.7070201@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQly4WOLLO6PH37c/0WjG6BTjjF5+LgpFhEm1RnowGAHYe3dVmtBH++Ps2uNGpkYjJJv4u/g Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, tijl@freebsd.org, Dan McGregor Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 17:03:01 -0000 On Aug 21, 2012, at 10:34 AM, Nathan Whitehorn wrote: > On 08/21/12 08:44, John Baldwin wrote: >> On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: >>> On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: >>>> Hi. >>>>=20 >>>> I've been working on porting compiler-rt/clang's support for = address >>>> sanitization (asan) to FreeBSD. So far I have it building and it >>>> appears to work properly, however the build system expects to be = able >>>> to build 32 bit binaries on amd64. >>>>=20 >>>> amd64 doesn't include i386's machine/foo headers. The included = patch >>>> is my proposed solution: >>>>=20 >>>> Add i386 headers to /usr/include/i386, and in machine/foo.h, check = if >>>> it's a 32 bit build and include the appropriate header from i386. >>>>=20 >>>> For example machine/ucontext.h will include i386/ucontext.h if >>>> compiled with -m32. >>>>=20 >>>> Thoughts? >>>>=20 >>>> If anyone's curious about the compiler_rt port, I have it at >>>> github.com/dannomac/compiler-rt on the branch named freebsd. >>> There was a work by Tijl Coosemans in the similar, but somewhat less = hacky >>> direction. The headers are moved into sys/x86/include and unified as = much >>> as possible, while machine/ counterpart includes corresponding = header >>> from x86/include. >>>=20 >>> I even lost track of how much more headers is left to convert. In = fact, >>> not all headers are equal, some are only useful for kernel or base = system. >>> Also, parts of the critically important headers do not live in = machine/ >>> at all, e.g. the headers from libm. >>>=20 >>> The work seems to be stale, do you want to cooperate with Tijl or = continue ? >> I think we should probably follow Tijl's model since we are on that = path. >> I originally preferred the /usr/include/i386 approach, but have come = around >> to Tjil's approach instead. >>=20 >=20 > I just wanted to add that the unified 32/64 header route is where we = went on PowerPC (and MIPS?) and it works very well for -m32. I don't know if mips has full -m32 support yet, but we do have one set = of headers there and that works for all mips modes. We also have one = set of headers for ARM too, but that's all ISA related, not 32 vs 64 = related... yet. The original i386 headers were copied to amd64 so they could be cleansed = of all the historical baggage from i386. This turned out to be a good = approach in many parts of the code, but not such a good idea for the = headers. I'm glad to see we're finally cleaning this up. Warner= From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 18:54:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCE5F106564A; Wed, 22 Aug 2012 18:54:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 817AF8FC12; Wed, 22 Aug 2012 18:54:07 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1953318pbb.13 for ; Wed, 22 Aug 2012 11:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rZfpz1tHNTTbKu38ojel5PANQA/rJ6lxn/hzSdvoPfU=; b=i43JnjXohwftbPVV7ETFoNBPqMNitbFlA4cf6Fcx+ACbV3tfRv6wL2q8tjCIICbK2S fOKAwsUc9dHNCVnh8kQMaZFbt1Ha+SFsm8vR7aCUQGACKYmTWHhvxOieijY5sLTkYtrv yQoW19LSj8y4j9GgCvwyQZ6wUqce5cFEtkpAvw5KPqE/bXnxQCjPvhnugP31bL7Gyx7t rhIW+3sjbMCGyiclGld/mhCKycGJjO5X2KiDBpngFuLRAlh4gicnqjijIYlE5hwhH7YS WdExxnlGFKTWvS2wrcQqj6nF8xO0H59MlbemSezxKTt0ASq16s+XomJpXqZaRX5DZRQQ V4yw== MIME-Version: 1.0 Received: by 10.68.129.131 with SMTP id nw3mr55048357pbb.43.1345661647286; Wed, 22 Aug 2012 11:54:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Wed, 22 Aug 2012 11:54:07 -0700 (PDT) In-Reply-To: <201208220802.14588.jhb@freebsd.org> References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> <201208220802.14588.jhb@freebsd.org> Date: Wed, 22 Aug 2012 11:54:07 -0700 X-Google-Sender-Auth: x8ry_dNw4_u3xMxdchT3PDLjlps Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, Mitya , Wojciech Puchar Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:54:07 -0000 On 22 August 2012 05:02, John Baldwin wrote: > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: >> Hi, >> >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that >> in a relevant include file, then hide the ugliness there? >> >> The same benefits will likely appear when copying wifi MAC addresses >> to/from headers. >> >> Thanks, I'm glad someone noticed this. > > I doubt we even _need_ the ugliness. We should just use *dst = *src > unless there is a compelling reason not to. Because it's not very clear? :-) I'd much prefer my array-of-things copies to be explicit. Also, the optimisation and compiler silliness may not be THAT obvious on intel (except when you're luigi and using netmap) but I can't help but wonder whether the same does hold for MIPS/ARM. Getting it wrong there will lead to some very very poor performing code. Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 19:50:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA8911065680 for ; Wed, 22 Aug 2012 19:50:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 875E98FC28 for ; Wed, 22 Aug 2012 19:50:08 +0000 (UTC) Received: by ghrr13 with SMTP id r13so1221599ghr.13 for ; Wed, 22 Aug 2012 12:50:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2nr5oaNJ/Yw6eN8tJNsoJaGPzKQjz8Q5DxvSC/Dz7I8=; b=NxdXWmevD4kqpMsneF2zT27Vlcn84oHku2lQQR9TMf9Pn+xBGWnxogpc3pj2fsxYNz s41UaZUlj3KA7zW7D9PXdcmTRUDWYwVXifawbEfaOBRN7cs8kfSlR3rJCiHYfTxju76s HbXWy1luI9yWDrre4HXgDKufvHmYpFIetjWEdV0ohNILjBtD5pcmRS4hRVRqKtdT8ZLS 8NLzC6Y4iWD/AE4RBOG2Ps40JK0iVjQZY0om2yTMVawvtVZG0HqlvLpQp5PvuChGxe2u y74MZC27vzm/9dJmzc5m2iywBAHMiYVzZgg+/KAnNcv3/eImaEIs2XyURxsTaBlx1QEU nXHg== Received: by 10.60.29.169 with SMTP id l9mr16384557oeh.14.1345665007575; Wed, 22 Aug 2012 12:50:07 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id k3sm4706410obw.4.2012.08.22.12.50.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 12:50:06 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 22 Aug 2012 13:50:04 -0600 Content-Transfer-Encoding: 7bit Message-Id: <3952D2BB-2181-430C-86BC-F9F90706C7A0@bsdimp.com> References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> <201208220802.14588.jhb@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQm+5z2satYkU2wTc+rtVf18/kmkPVsRbAad3LaqEhgUcMCc1+MW8qwbO1Z6gN5pAaUI6+Xg Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, Mitya , Wojciech Puchar Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:50:09 -0000 On Aug 22, 2012, at 12:54 PM, Adrian Chadd wrote: > On 22 August 2012 05:02, John Baldwin wrote: >> On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: >>> Hi, >>> >>> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that >>> in a relevant include file, then hide the ugliness there? >>> >>> The same benefits will likely appear when copying wifi MAC addresses >>> to/from headers. >>> >>> Thanks, I'm glad someone noticed this. >> >> I doubt we even _need_ the ugliness. We should just use *dst = *src >> unless there is a compelling reason not to. > > Because it's not very clear? :-) I'd much prefer my array-of-things > copies to be explicit. But it isn't an array of things. It is a structure.a > Also, the optimisation and compiler silliness may not be THAT obvious > on intel (except when you're luigi and using netmap) but I can't help > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > there will lead to some very very poor performing code. Which is why we need to check that output to make sure it isn't too horrible. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 20:06:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 637A41065675; Wed, 22 Aug 2012 20:06:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 35F1E8FC21; Wed, 22 Aug 2012 20:06:31 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 87355B97E; Wed, 22 Aug 2012 16:06:30 -0400 (EDT) From: John Baldwin To: Adrian Chadd Date: Wed, 22 Aug 2012 15:21:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <50324DB4.6080905@cabletv.dp.ua> <201208220802.14588.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208221521.06954.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 Aug 2012 16:06:30 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, Mitya , Wojciech Puchar Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:06:31 -0000 On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote: > On 22 August 2012 05:02, John Baldwin wrote: > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > >> Hi, > >> > >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > >> in a relevant include file, then hide the ugliness there? > >> > >> The same benefits will likely appear when copying wifi MAC addresses > >> to/from headers. > >> > >> Thanks, I'm glad someone noticed this. > > > > I doubt we even _need_ the ugliness. We should just use *dst = *src > > unless there is a compelling reason not to. > > Because it's not very clear? :-) I'd much prefer my array-of-things > copies to be explicit. Eh? 'struct foo *src, *dst; *dst = *src' is pretty bog-standard C. That isn't really all that obtuse. > Also, the optimisation and compiler silliness may not be THAT obvious > on intel (except when you're luigi and using netmap) but I can't help > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > there will lead to some very very poor performing code. Don't you think there's a really good chance the compiler knows how to copy a structure appropriately for each architecture already? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 20:10:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A38F4106564A for ; Wed, 22 Aug 2012 20:10:46 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay006.isp.belgacom.be (mailrelay006.isp.belgacom.be [195.238.6.172]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2008FC1D for ; Wed, 22 Aug 2012 20:10:44 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAFs7NVBbsUsY/2dsb2JhbAA7Crcdgy+BCIIgAQEFViIRCxgJFg8JAwIBAgEnHgYBDAgBAReHdrkriwgQhwwDjl2BIJVogmWBXw Received: from 24.75-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.75.24]) by relay.skynet.be with ESMTP; 22 Aug 2012 22:09:35 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.5/8.14.5) with ESMTP id q7MK9Yo1007388; Wed, 22 Aug 2012 22:09:34 +0200 (CEST) (envelope-from tijl@freebsd.org) Message-ID: <50353C77.2070602@freebsd.org> Date: Wed, 22 Aug 2012 22:09:27 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120804 Thunderbird/14.0 MIME-Version: 1.0 To: Dan McGregor , freebsd-hackers@freebsd.org References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE8133964C8851F885FB99C4D" Cc: Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:10:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE8133964C8851F885FB99C4D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21-08-2012 17:04, Dan McGregor wrote: > My solution is certainly fairly hacky, I just took inspiration from=20 > NetBSD. I wanted to see if it could be done. While I was there I did > identify several files that should be common between i386 and amd64, > such as exec.h. >=20 > Since reading your email I started looking at the x86 common code, > and have made some more code common; specifically asm.h ans > ucontext.h. I'll be putting that on github shortly. >=20 > Since it does look like tijl hasn't committed anything since March, > I would like to co-operate and see what his plans were. The idea of > merging the i386 and amd64 headers into a common area seems like a > better idea to me. For now my goal was to merge headers that can be used by user code so it can be compiled with -m32. Eventually, I think it would be nice to merge all headers and install x86/ as machine/ for both i386 and amd64. That would make the x86 headers similar to powerpc and mips headers (and arm when 64bit support is added there). I think I still have one or two (untested) patches. I'll have a look at it during the weekend. --------------enigE8133964C8851F885FB99C4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iF4EAREIAAYFAlA1PH4ACgkQfoCS2CCgtiv52AD+Loo7vrNn6Bdfbxyc+Hsg7VPf f1tl5sdN/0jcLP1WhVEA/AxM1R+D8yP1DN9XphBV4IZzo9E2k6BbjNwGmsEz/vnL =ge49 -----END PGP SIGNATURE----- --------------enigE8133964C8851F885FB99C4D-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 20:28:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 693D1106566B; Wed, 22 Aug 2012 20:28:48 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 0B77E8FC1B; Wed, 22 Aug 2012 20:28:37 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q7MJsdZ0061881; Wed, 22 Aug 2012 21:54:40 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q7MJsWkq061878; Wed, 22 Aug 2012 21:54:36 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 22 Aug 2012 21:54:32 +0200 (CEST) From: Wojciech Puchar To: Adrian Chadd In-Reply-To: Message-ID: References: <50324DB4.6080905@cabletv.dp.ua> <420BA06C-C776-47DB-B3BB-F1414C115F99@bsdimp.com> <201208220802.14588.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 22 Aug 2012 21:54:42 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:28:48 -0000 > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > there will lead to some very very poor performing code. > 1) do - as already pointed out - standard copy of structure in C. 2) if compiler is found to generate bad code on some archs put assembly. 1 even if compiler is not smart is already far better than calling a function to copy 6 bytes that is plain stupid. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 21:33:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 751AC106566B; Wed, 22 Aug 2012 21:33:37 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCBC8FC12; Wed, 22 Aug 2012 21:33:36 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 695477300A; Wed, 22 Aug 2012 23:52:44 +0200 (CEST) Date: Wed, 22 Aug 2012 23:52:44 +0200 From: Luigi Rizzo To: John Baldwin Message-ID: <20120822215244.GC67796@onelab2.iet.unipi.it> References: <50324DB4.6080905@cabletv.dp.ua> <201208220802.14588.jhb@freebsd.org> <201208221521.06954.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208221521.06954.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Adrian Chadd , Mitya , Wojciech Puchar , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:33:37 -0000 On Wed, Aug 22, 2012 at 03:21:06PM -0400, John Baldwin wrote: > On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote: > > On 22 August 2012 05:02, John Baldwin wrote: > > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > > >> Hi, > > >> > > >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > > >> in a relevant include file, then hide the ugliness there? > > >> > > >> The same benefits will likely appear when copying wifi MAC addresses > > >> to/from headers. > > >> > > >> Thanks, I'm glad someone noticed this. > > > > > > I doubt we even _need_ the ugliness. We should just use *dst = *src > > > unless there is a compelling reason not to. > > > > Because it's not very clear? :-) I'd much prefer my array-of-things > > copies to be explicit. > > Eh? 'struct foo *src, *dst; *dst = *src' is pretty bog-standard C. That > isn't really all that obtuse. the thread has probably forked causing people to miss the explanation that Bruce gave: quite often the function is called by casting arbitrary pointers into 'struct foo *', so the compiler's expectations about alignment do not necessarily match the user's lies. Unfortunately we are building kernels with many compiler checks disabled, so there is a fair chance that the compiler will not detect such invalid casts. Probably addresses are aligned to 2-byte boundaries, but certainly not on a 4-byte, which means that a safe copy might require 3 instructions, even though a compiler could otherwise decide to align all non-packed 'struct foo' to a 4- or 8-byte boundary and possibly do the copy with 2 or even 1 instruction. I would also suggest to try the code i posted in response to bruce so you can check how good or bad are the various solutions on different architectures or CPUs, and see if there is a reasonable compromise. cheers luigi > > Also, the optimisation and compiler silliness may not be THAT obvious > > on intel (except when you're luigi and using netmap) but I can't help > > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > > there will lead to some very very poor performing code. > > Don't you think there's a really good chance the compiler knows how to copy a > structure appropriately for each architecture already? > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 21:40:42 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B69EB106566B; Wed, 22 Aug 2012 21:40:42 +0000 (UTC) (envelope-from danismostlikely@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8DF8FC16; Wed, 22 Aug 2012 21:40:41 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so107979vcb.13 for ; Wed, 22 Aug 2012 14:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iw3scMSyeVeMUjHXFO8Je+w4ufXx8LZa9HoeegKeoKo=; b=LIP84mqwLBPqyNkkF2vBfcqpTDcEY4A89mVyl/kxFiIM3iLI31O0jygMJ10J8HpnIh KxBOKuUk3/sAyR2vuWCwQrU7LkIHZa7VMn77GbaLXpofvT0BkDXScpHmuACwTIkKXtNe Ro2hFp1dNz4HSuuryP2siPUY4YO4xRPJyTG1+dFVIZiGlI95x3i3kniiVTsuE11cMuVi s0h3+4yNjlu7alIPx64VWXG6D7ZBqPiwipaQVYYEWX0IHLt5HJONHBITZHS30KoYospG 7i+M7B6IIGwBE2baT/W7nGoP8bvFK4pZ9sHq1zBmhcxLkCKU8xfaXXYZsx4G3DOrq9mF PNgQ== MIME-Version: 1.0 Received: by 10.58.211.71 with SMTP id na7mr19601288vec.39.1345671641363; Wed, 22 Aug 2012 14:40:41 -0700 (PDT) Received: by 10.58.91.169 with HTTP; Wed, 22 Aug 2012 14:40:41 -0700 (PDT) In-Reply-To: <50353C77.2070602@freebsd.org> References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <50353C77.2070602@freebsd.org> Date: Wed, 22 Aug 2012 15:40:41 -0600 Message-ID: From: Dan McGregor To: Tijl Coosemans Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:40:42 -0000 On 22 August 2012 14:09, Tijl Coosemans wrote: > On 21-08-2012 17:04, Dan McGregor wrote: >> My solution is certainly fairly hacky, I just took inspiration from >> NetBSD. I wanted to see if it could be done. While I was there I did >> identify several files that should be common between i386 and amd64, >> such as exec.h. >> >> Since reading your email I started looking at the x86 common code, >> and have made some more code common; specifically asm.h ans >> ucontext.h. I'll be putting that on github shortly. >> >> Since it does look like tijl hasn't committed anything since March, >> I would like to co-operate and see what his plans were. The idea of >> merging the i386 and amd64 headers into a common area seems like a >> better idea to me. > > For now my goal was to merge headers that can be used by user code so > it can be compiled with -m32. Eventually, I think it would be nice to > merge all headers and install x86/ as machine/ for both i386 and amd64. > That would make the x86 headers similar to powerpc and mips headers > (and arm when 64bit support is added there). > > I think I still have one or two (untested) patches. I'll have a look at > it during the weekend. > That sounds very handy. I didn't know where you got to, so I've been plugging away at the same goal for the last couple of days. Is there anything specific I could help you with? From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 22 22:51:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A3F106564A; Wed, 22 Aug 2012 22:51:09 +0000 (UTC) (envelope-from danismostlikely@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A33FF8FC0A; Wed, 22 Aug 2012 22:51:08 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so180824vcb.13 for ; Wed, 22 Aug 2012 15:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hVCvNN37hXmqRtaiDP+4TyzdNbGE44EWNLD1mj10jYY=; b=Fqq2wAaQ8+Obbkav2J9vun3Es2CBC6un9R4Kwsoo/lWnuku4BkChdVbp/G3HA7tL5W uIcomdEqdMDeGBSFUC1D6gkttiR+V6i5gQuoZCH6RKOwdZKsa/sWi1YFdeSu3EDBtjYT td0hQANJYex3HM12LhLZ74v44ZzdhmUqxzmuknQdiSY7Tu+DWfZQTfA6VQ8vBbcbPRsd +AXLmN2AHWU60yhZcVRyZvLCG583Z/F7GBN9+BScSpYTpKg+tSEmNjNzRgLp9AQr6M1t xEdXjzuG2SrAhqSTj7rF9UmeXkwjxzJZYLga6r6CKZ0eUr+2gkYMZ+ob2KO+aQ97kZ19 VtQQ== MIME-Version: 1.0 Received: by 10.221.10.148 with SMTP id pa20mr6704986vcb.26.1345675868002; Wed, 22 Aug 2012 15:51:08 -0700 (PDT) Received: by 10.58.91.169 with HTTP; Wed, 22 Aug 2012 15:51:07 -0700 (PDT) In-Reply-To: References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <50353C77.2070602@freebsd.org> Date: Wed, 22 Aug 2012 16:51:07 -0600 Message-ID: From: Dan McGregor To: Eric McCorkle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , Tijl Coosemans Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 22:51:09 -0000 I can't speak for Tijl, but being able to build anything simply by passing -m32 to the compiler is my goal. Did your Intel EFI work involve #defining _KERNEL anywhere? On 22 August 2012 16:04, Eric McCorkle wrote: > I ran into some bugs compiling things with -m32 in the intel EFI work. A= s things stand now, there's a lot more involved in setting up a 32 bit buil= d environment. I'm not sure if it's possible to reduce this down to passin= g -m32 to the compiler, though it would certainly be nice. > > Sent from my iPhone > > On Aug 22, 2012, at 4:09 PM, Tijl Coosemans wrote: > >> On 21-08-2012 17:04, Dan McGregor wrote: >>> My solution is certainly fairly hacky, I just took inspiration from >>> NetBSD. I wanted to see if it could be done. While I was there I did >>> identify several files that should be common between i386 and amd64, >>> such as exec.h. >>> >>> Since reading your email I started looking at the x86 common code, >>> and have made some more code common; specifically asm.h ans >>> ucontext.h. I'll be putting that on github shortly. >>> >>> Since it does look like tijl hasn't committed anything since March, >>> I would like to co-operate and see what his plans were. The idea of >>> merging the i386 and amd64 headers into a common area seems like a >>> better idea to me. >> >> For now my goal was to merge headers that can be used by user code so >> it can be compiled with -m32. Eventually, I think it would be nice to >> merge all headers and install x86/ as machine/ for both i386 and amd64. >> That would make the x86 headers similar to powerpc and mips headers >> (and arm when 64bit support is added there). >> >> I think I still have one or two (untested) patches. I'll have a look at >> it during the weekend. >> From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 23 08:56:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C9F106567C; Thu, 23 Aug 2012 08:56:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1C95B8FC21; Thu, 23 Aug 2012 08:56:21 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7N8uTen051935; Thu, 23 Aug 2012 11:56:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q7N8uHBv015032; Thu, 23 Aug 2012 11:56:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7N8uHEB015031; Thu, 23 Aug 2012 11:56:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 23 Aug 2012 11:56:17 +0300 From: Konstantin Belousov To: Tijl Coosemans Message-ID: <20120823085617.GL33100@deviant.kiev.zoral.com.ua> References: <20120821084930.GM33100@deviant.kiev.zoral.com.ua> <50353C77.2070602@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uY6A4WM8GrQcEArj" Content-Disposition: inline In-Reply-To: <50353C77.2070602@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, das@freebsd.org, Dan McGregor Subject: Re: Build 32 bit binaries on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 08:56:22 -0000 --uY6A4WM8GrQcEArj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2012 at 10:09:27PM +0200, Tijl Coosemans wrote: > On 21-08-2012 17:04, Dan McGregor wrote: > > My solution is certainly fairly hacky, I just took inspiration from=20 > > NetBSD. I wanted to see if it could be done. While I was there I did > > identify several files that should be common between i386 and amd64, > > such as exec.h. > >=20 > > Since reading your email I started looking at the x86 common code, > > and have made some more code common; specifically asm.h ans > > ucontext.h. I'll be putting that on github shortly. > >=20 > > Since it does look like tijl hasn't committed anything since March, > > I would like to co-operate and see what his plans were. The idea of > > merging the i386 and amd64 headers into a common area seems like a > > better idea to me. >=20 > For now my goal was to merge headers that can be used by user code so > it can be compiled with -m32. Eventually, I think it would be nice to > merge all headers and install x86/ as machine/ for both i386 and amd64. > That would make the x86 headers similar to powerpc and mips headers > (and arm when 64bit support is added there). Having only the usermode-usable headers merged is enough, IMO. Eventually merging everything between i386 and amd64, removing the excessive duplication of the similar code is worthy goal, but is not neccessary for the already very high-profile feature of working -m32. >=20 > I think I still have one or two (untested) patches. I'll have a look at > it during the weekend. If only several (small ?) things left, then the news are actually great. I think that we (you) shall announce that much louder. The feature is very demanded and needed. As I noted earlier, the big untracked issue is the lib/msun//fenv.h. This is really important and hopefully last obstacle to have -m32 working. In fact, quick look at the i386 and amd64 versions of fenv.h shows that they are quite similar, as it shall be. The issue there would be mostly distribution problem, how to merge the files in the build and installation system. --uY6A4WM8GrQcEArj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlA18DEACgkQC3+MBN1Mb4gdqACg6hnKkuiEEDmRjyl0HJ6dBvwB 2dYAoIBduyw7GoMEcZIxD1WvB81FCgdC =OjAH -----END PGP SIGNATURE----- --uY6A4WM8GrQcEArj-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 23 20:45:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5C83106566B; Thu, 23 Aug 2012 20:45:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 791B08FC12; Thu, 23 Aug 2012 20:45:37 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2221055pbb.13 for ; Thu, 23 Aug 2012 13:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eTs2PDCvXo7HJ4XyB3Z7nXzztmeJZO27snyZbgEdlj4=; b=qUu9nVbvlEtvRhOXcVR/7/WsbrLdmN91xKPJ6kf/ZdqCNXgdJIQQTftCM4Lo0LHhN5 spYO9JsLOkRhXXqThR5otK6SceocRLgzETNJ3gEql8NjBzeSa/lUw6ho6fdrkmMRej1P ZfUWl1PycXy0ov5H2ZgzJTtEng0D93LtnKwT78dL+VTnvnNjNeguusQ6gbBh6V+JIV66 1PHZ9crCEYy/MWCwbsA5G7JJ7n+f5JgBPVmGezKwGoZqZ0B18SSaydMfpuUYk9CBpj7G fFdH7+D4LS83kXDtV2EXXXgY5PacQuxa+c6IhgQLEIr5RaWihkqcZAQME60d4hQyVvQN Sa2g== MIME-Version: 1.0 Received: by 10.68.238.74 with SMTP id vi10mr7562884pbc.48.1345754737174; Thu, 23 Aug 2012 13:45:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 23 Aug 2012 13:45:37 -0700 (PDT) In-Reply-To: <20120822215244.GC67796@onelab2.iet.unipi.it> References: <50324DB4.6080905@cabletv.dp.ua> <201208220802.14588.jhb@freebsd.org> <201208221521.06954.jhb@freebsd.org> <20120822215244.GC67796@onelab2.iet.unipi.it> Date: Thu, 23 Aug 2012 13:45:37 -0700 X-Google-Sender-Auth: cEMIlt1cCvnwt95ul82zb1EHs6E Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Wojciech Puchar , Mitya , freebsd-net@freebsd.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:45:37 -0000 You can't assume the ethernet addresses will be aligned. For wifi headers you're definitely going to have at least one address be non-dword aligned, even if the header itself is dword aligned. The whole point of using a macro is so it becomes really easy to change the copy type at compile time. Otherwise I'll have to go through the code, find all the (CPU intensive/stalling) places where those 6 byte copies are occuring and replace them. Adrian From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 24 00:39:34 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 420E7106566B; Fri, 24 Aug 2012 00:39:34 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id 2B38E8FC08; Fri, 24 Aug 2012 00:39:34 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7O0dYZK029436; Fri, 24 Aug 2012 00:39:34 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7O0dUbl029143; Fri, 24 Aug 2012 00:39:30 GMT (envelope-from bde) Date: Fri, 24 Aug 2012 00:39:30 GMT From: Bruce Evans Message-Id: <201208240039.q7O0dUbl029143@ref10-i386.freebsd.org> To: jhb@FreeBSD.org, rizzo@iet.unipi.it In-Reply-To: <20120822215244.GC67796@onelab2.iet.unipi.it> Cc: freebsd-hackers@FreeBSD.org, adrian@FreeBSD.org, mitya@cabletv.dp.ua, wojtek@wojtek.tensor.gdynia.pl, freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 00:39:34 -0000 >From owner-freebsd-net@FreeBSD.org Thu Aug 23 10:58:03 2012 Delivered-To: freebsd-net@freebsd.org Date: Wed, 22 Aug 2012 23:52:44 +0200 From: Luigi Rizzo To: John Baldwin References: <50324DB4.6080905@cabletv.dp.ua> <201208220802.14588.jhb@freebsd.org> <201208221521.06954.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208221521.06954.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@FreeBSD.org, Adrian Chadd , Mitya , Wojciech Puchar , freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-net@FreeBSD.org Errors-To: owner-freebsd-net@FreeBSD.org Content-Length: 2762 Lines: 64 On Wed, Aug 22, 2012 at 03:21:06PM -0400, John Baldwin wrote: > On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote: > > On 22 August 2012 05:02, John Baldwin wrote: > > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > > >> Hi, > > >> > > >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > > >> in a relevant include file, then hide the ugliness there? > > >> > > >> The same benefits will likely appear when copying wifi MAC addresses > > >> to/from headers. > > >> > > >> Thanks, I'm glad someone noticed this. > > > > > > I doubt we even _need_ the ugliness. We should just use *dst = *src > > > unless there is a compelling reason not to. > > > > Because it's not very clear? :-) I'd much prefer my array-of-things > > copies to be explicit. > > Eh? 'struct foo *src, *dst; *dst = *src' is pretty bog-standard C. That > isn't really all that obtuse. the thread has probably forked causing people to miss the explanation that Bruce gave: quite often the function is called by casting arbitrary pointers into 'struct foo *', so the compiler's expectations about alignment do not necessarily match the user's lies. Unfortunately we are building kernels with many compiler checks disabled, so there is a fair chance that the compiler will not detect such invalid casts. Probably addresses are aligned to 2-byte boundaries, but certainly not on a 4-byte, which means that a safe copy might require 3 instructions, even though a compiler could otherwise decide to align all non-packed 'struct foo' to a 4- or 8-byte boundary and possibly do the copy with 2 or even 1 instruction. I would also suggest to try the code i posted in response to bruce so you can check how good or bad are the various solutions on different architectures or CPUs, and see if there is a reasonable compromise. cheers luigi > > Also, the optimisation and compiler silliness may not be THAT obvious > > on intel (except when you're luigi and using netmap) but I can't help > > but wonder whether the same does hold for MIPS/ARM. Getting it wrong > > there will lead to some very very poor performing code. > > Don't you think there's a really good chance the compiler knows how to copy a > structure appropriately for each architecture already? > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 24 01:08:38 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13056106566B; Fri, 24 Aug 2012 01:08:38 +0000 (UTC) (envelope-from bde@FreeBSD.org) Received: from ref10-i386.freebsd.org (unknown [IPv6:2001:4f8:fff6::5e]) by mx1.freebsd.org (Postfix) with ESMTP id EF9AD8FC14; Fri, 24 Aug 2012 01:08:37 +0000 (UTC) Received: from ref10-i386.freebsd.org (localhost [127.0.0.1]) by ref10-i386.freebsd.org (8.14.5/8.14.5) with ESMTP id q7O18bCU009633; Fri, 24 Aug 2012 01:08:37 GMT (envelope-from bde@ref10-i386.freebsd.org) Received: (from bde@localhost) by ref10-i386.freebsd.org (8.14.5/8.14.5/Submit) id q7O18bej009632; Fri, 24 Aug 2012 01:08:37 GMT (envelope-from bde) Date: Fri, 24 Aug 2012 01:08:37 GMT From: Bruce Evans Message-Id: <201208240108.q7O18bej009632@ref10-i386.freebsd.org> To: jhb@FreeBSD.org, rizzo@iet.unipi.it In-Reply-To: <20120822215244.GC67796@onelab2.iet.unipi.it> Cc: freebsd-hackers@FreeBSD.org, adrian@FreeBSD.org, mitya@cabletv.dp.ua, wojtek@wojtek.tensor.gdynia.pl, freebsd-net@FreeBSD.org Subject: Re: Replace bcopy() to update ether_addr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 01:08:38 -0000 luigi wrote: > On Wed, Aug 22, 2012 at 03:21:06PM -0400, John Baldwin wrote: > > On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote: > > > On 22 August 2012 05:02, John Baldwin wrote: > > > > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: > > > >> Hi, > > > >> > > > >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting that > > > >> in a relevant include file, then hide the ugliness there? Good for source code ugliness and bloat (not just in the macro). > > > >> The same benefits will likely appear when copying wifi MAC addresses > > > >> to/from headers. Why stop there? Change all assignments to use the ASSIGN() macro. The compiler doesn't understand assignment, but we do ;-). > > > >> Thanks, I'm glad someone noticed this. > > > > > > > > I doubt we even _need_ the ugliness. We should just use *dst = *src > > > > unless there is a compelling reason not to. > > > > > > Because it's not very clear? :-) I'd much prefer my array-of-things > > > copies to be explicit. > > > > Eh? 'struct foo *src, *dst; *dst = *src' is pretty bog-standard C. That > > isn't really all that obtuse. (Builtin) memcpy is better for this in general (no sarcasm now). It reduces to a struct copy if the object being copy is a struct, and is not limited to structs. However, ethernet address types are now fully pessimized, so compilers are almost forced to assume that they are fully misaligned. From net/ethernet.h: % /* % * Structure of a 10Mb/s Ethernet header. % */ Wow, 10Mb/s. % struct ether_header { % u_char ether_dhost[ETHER_ADDR_LEN]; % u_char ether_shost[ETHER_ADDR_LEN]; % u_short ether_type; % } __packed; This used to be not quite guaranteed to be 16-bit aligned by the short in it. Perhaps it is still aligned in practice, But in 2006, it was fully pessimized by adding __packed without adding __aligned(2). This __packed prevents the struct being padded to a multiple of 32 bits in size on arm. It has the side effect of allowing the compiler to not add padding for alignment before instances of this struct, and allowing embedded short to be misaligned, so all accesses to this short might require 2 1-byte load/store instructions and more instructions to combine the bytes. On x86, the accesses can be a single load/store (or sometimes an arithmetic operation), with the hardware doing the combination, possibly more slowly than for aligned accesses. The pessimization is better on other arches. % /* % * Structure of a 48-bit Ethernet address. % */ % struct ether_addr { % u_char octet[ETHER_ADDR_LEN]; % } __packed; This was always just an array of bytes, so it was nevever required to have more than byte alignment. However, the compiler was permitted to add padding before and after it to align it and the thing after it. __packed on it may prevent this. I hope that it actually takes a __packed on the containing struct or on the struct member with this type to prevent external padding, but __packed on everything may be needed anyway for __packed on this to have much effect. An ETHER_ADDR_COPY() macro can only do worse than the compiler here, since the object is nothing more than an array of bytes after forgetting the extra packing info that may be known to the compiler. On x86, the macro can use 2 possibly-misaligned load/stores, but so can the compiler, or the macro can use a dynamic comparison of the address to find the alignment point and then do 1, 2 or 3 aligned load/store pairs, but so can the compiler, or the macro can use "rep movsb", but so can the compiler... The best choice depends on CFLAGS (a static test that is easiest for the compiler) or on the CPU. For a complete implementation, the macro must of course patch the instructions used to best suit the current CPU. This would be a lot of work for an unimportant (~0.1% max) optimization. On non-x86 or any arch with strict alignment requirements, the only obviously correct implementions of the macro are 6 1-byte load/store pairs, or memcpy(), or bcopy(). The compiler can easily beat all of these. > the thread has probably forked causing people to miss the explanation > that Bruce gave: quite often the function is called by casting > arbitrary pointers into 'struct foo *', so the compiler's expectations > about alignment do not necessarily match the user's lies. Except for struct ether_addr, the cast would actually reduce alignment (unless the compiler is smart enough to not do it literally). > Unfortunately we are building kernels with many compiler checks > disabled, so there is a fair chance that the compiler will not > detect such invalid casts. Er, we check more in the kernel than almost everywhere else. > Probably addresses are aligned to 2-byte boundaries, but certainly > not on a 4-byte, which means that a safe copy might require 3 > instructions, even though a compiler could otherwise decide to align > all non-packed 'struct foo' to a 4- or 8-byte boundary and possibly > do the copy with 2 or even 1 instruction. The code actually asks for 1-byte alignment. From if_ethersubr.c: % int % ether_output(struct ifnet *ifp, struct mbuf *m, % struct sockaddr *dst, struct route *ro) % { % short type; % int error = 0, hdrcmplt = 0; % u_char esrc[ETHER_ADDR_LEN], edst[ETHER_ADDR_LEN]; This asks for raw byte arrays. gcc tends to align even arrays of char more than asked for but the code asks for minimal alignment. % struct llentry *lle = NULL; % struct rtentry *rt0 = NULL; % struct ether_header *eh; This points into an array of data. Such pointers may lose extra alignment info that may be present in the original type. % struct pf_mtag *t; % int loop_copy = 1; % int hlen; /* link layer header length */ Another pessimization technique used in this code is to initialize many variables in their declarations, despite unbroken versions of style(9) forbidding this. Out of order execution and x86 speed hides the slowness from this about as well as it hides the slowness from extra memcpy()'s. (gcc likes to do all of these inititializations "early" in program order, but with out of order execution there is no strict order and you can't do much better by delaying or avoiding the initializations.) Bruce From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 24 15:18:11 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E81001065677 for ; Fri, 24 Aug 2012 15:18:11 +0000 (UTC) (envelope-from jhein@symmetricom.com) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B523C8FC0A for ; Fri, 24 Aug 2012 15:18:11 +0000 (UTC) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q7OFI3Z9012108 for ; Fri, 24 Aug 2012 09:18:03 -0600 (MDT) (envelope-from jhein@symmetricom.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.5/8.14.5) with ESMTP id q7OFHMAT043936; Fri, 24 Aug 2012 09:17:22 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.5/8.14.5/Submit) id q7OFHMnS043935; Fri, 24 Aug 2012 09:17:22 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20535.39682.330250.337503@gromit.timing.com> Date: Fri, 24 Aug 2012 09:17:22 -0600 From: John Hein To: hackers@freebsd.org X-Mailer: VM 8.2.0b-trunk-1408 under 23.4.1 (i386-portbld-freebsd7.4) Cc: Subject: LD_PRELOADed code before or after exec - different behavior after 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 15:18:12 -0000 head sl.cc pe.c ==> sl.cc <== #include #include class C { public: C(){ printf("C\n"); unsetenv("XXX"); } }; static C c; ==> pe.c <== #include #include int main() { char *p=getenv("XXX"); if (p != NULL) printf("XXX=%s\n",p); return 0; } % g++ -fpic -shared sl.cc -o sl.so % gcc pe.c -o pe 7.x & 8.x ... % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' C XXX=1 6.x & 4.x ... % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' C In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env var apparently in time to affect the exec'd process. In 8.x & 9.x, it seems the environment is set and passed to the exec'd process and the LD_PRELOADed code does not affect that despite its best efforts. It seems to me that 6.x behavior is more correct, but I'm seeking opinions before contemplating if / how to put together a fix. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 24 15:35:05 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FFFF1065675 for ; Fri, 24 Aug 2012 15:35:05 +0000 (UTC) (envelope-from jhein@symmetricom.com) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id DC24A8FC1C for ; Fri, 24 Aug 2012 15:35:04 +0000 (UTC) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q7OFZ4jB012430 for ; Fri, 24 Aug 2012 09:35:04 -0600 (MDT) (envelope-from jhein@symmetricom.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.5/8.14.5) with ESMTP id q7OFYZwv044196; Fri, 24 Aug 2012 09:34:35 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.5/8.14.5/Submit) id q7OFYT6c044195; Fri, 24 Aug 2012 09:34:29 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20535.40709.486888.887048@gromit.timing.com> Date: Fri, 24 Aug 2012 09:34:29 -0600 From: John Hein To: hackers@freebsd.org In-Reply-To: <20535.39682.330250.337503@gromit.timing.com> References: <20535.39682.330250.337503@gromit.timing.com> X-Mailer: VM 8.2.0b-trunk-1408 under 23.4.1 (i386-portbld-freebsd7.4) Cc: Subject: Re: LD_PRELOADed code before or after exec - different behavior after 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 15:35:05 -0000 John Hein wrote at 09:17 -0600 on Aug 24, 2012: > > head sl.cc pe.c > ==> sl.cc <== > #include > #include > class C > { > public: > C(){ > printf("C\n"); > unsetenv("XXX"); > } > }; > static C c; > > ==> pe.c <== > #include > #include > int > main() > { > char *p=getenv("XXX"); > if (p != NULL) > printf("XXX=%s\n",p); > return 0; > } > > > % g++ -fpic -shared sl.cc -o sl.so > % gcc pe.c -o pe > > 7.x & 8.x ... > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' > C > XXX=1 I meant to write: 7.x & 8.x ... % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' C % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe' C XXX=1 > 6.x & 4.x ... > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' > C and 6.x & 4.x ... % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' C % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe' C > In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env > var apparently in time to affect the exec'd process. In 8.x & 9.x, it > seems the environment is set and passed to the exec'd process and the > LD_PRELOADed code does not affect that despite its best efforts. > > It seems to me that 6.x behavior is more correct, but I'm seeking > opinions before contemplating if / how to put together a fix. > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 24 15:38:46 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EDA8106566B for ; Fri, 24 Aug 2012 15:38:46 +0000 (UTC) (envelope-from jhein@symmetricom.com) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E79EC8FC19 for ; Fri, 24 Aug 2012 15:38:45 +0000 (UTC) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q7OFcixX012467; Fri, 24 Aug 2012 09:38:44 -0600 (MDT) (envelope-from jhein@symmetricom.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.5/8.14.5) with ESMTP id q7OFciQM044268; Fri, 24 Aug 2012 09:38:44 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.5/8.14.5/Submit) id q7OFciYU044267; Fri, 24 Aug 2012 09:38:44 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20535.40964.366702.606107@gromit.timing.com> Date: Fri, 24 Aug 2012 09:38:44 -0600 From: John Hein To: hackers@freebsd.org In-Reply-To: <20535.40709.486888.887048@gromit.timing.com> References: <20535.39682.330250.337503@gromit.timing.com> <20535.40709.486888.887048@gromit.timing.com> X-Mailer: VM 8.2.0b-trunk-1408 under 23.4.1 (i386-portbld-freebsd7.4) Cc: Subject: Re: LD_PRELOADed code before or after exec - different behavior after 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 15:38:46 -0000 John Hein wrote at 09:34 -0600 on Aug 24, 2012: > John Hein wrote at 09:17 -0600 on Aug 24, 2012: > > > > head sl.cc pe.c > > ==> sl.cc <== > > #include > > #include > > class C > > { > > public: > > C(){ > > printf("C\n"); > > unsetenv("XXX"); > > } > > }; > > static C c; > > > > ==> pe.c <== > > #include > > #include > > int > > main() > > { > > char *p=getenv("XXX"); > > if (p != NULL) > > printf("XXX=%s\n",p); > > return 0; > > } > > > > > > % g++ -fpic -shared sl.cc -o sl.so > > % gcc pe.c -o pe > > > > 7.x & 8.x ... > > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' > > C > > XXX=1 > > I meant to write: > > 7.x & 8.x ... > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' > C > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe' > C > XXX=1 > > > 6.x & 4.x ... > > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' > > C > > and > 6.x & 4.x ... > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' > C > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe' > C Argh. Never mind. I was correct the first time. The shell's exec doesn't matter... 7.x & 8.x ... % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' C XXX=1 % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe' C XXX=1 6.x & 4.x ... % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' C % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so exec pe' C > > In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env > > var apparently in time to affect the exec'd process. In 8.x & 9.x, it > > seems the environment is set and passed to the exec'd process and the > > LD_PRELOADed code does not affect that despite its best efforts. > > > > It seems to me that 6.x behavior is more correct, but I'm seeking > > opinions before contemplating if / how to put together a fix. > > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 24 16:23:52 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 682EC1065670 for ; Fri, 24 Aug 2012 16:23:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A72A38FC14 for ; Fri, 24 Aug 2012 16:23:50 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7OGNoFS095292; Fri, 24 Aug 2012 19:23:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q7OGNcx2024683; Fri, 24 Aug 2012 19:23:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7OGNc1D024682; Fri, 24 Aug 2012 19:23:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Aug 2012 19:23:38 +0300 From: Konstantin Belousov To: John Hein Message-ID: <20120824162338.GV33100@deviant.kiev.zoral.com.ua> References: <20535.39682.330250.337503@gromit.timing.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g++0NlQhRgFs6nMu" Content-Disposition: inline In-Reply-To: <20535.39682.330250.337503@gromit.timing.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: hackers@freebsd.org Subject: Re: LD_PRELOADed code before or after exec - different behavior after 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:23:52 -0000 --g++0NlQhRgFs6nMu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 24, 2012 at 09:17:22AM -0600, John Hein wrote: >=20 > head sl.cc pe.c > =3D=3D> sl.cc <=3D=3D > #include > #include > class C > { > public: > C(){ > printf("C\n"); > unsetenv("XXX"); > } > }; > static C c; >=20 > =3D=3D> pe.c <=3D=3D > #include > #include > int > main() > { > char *p=3Dgetenv("XXX"); > if (p !=3D NULL) > printf("XXX=3D%s\n",p); > return 0; > } >=20 >=20 > % g++ -fpic -shared sl.cc -o sl.so > % gcc pe.c -o pe >=20 > 7.x & 8.x ... > % sh -c 'XXX=3D1 LD_PRELOAD=3D$(pwd)/sl.so pe' > C > XXX=3D1 >=20 > 6.x & 4.x ... > % sh -c 'XXX=3D1 LD_PRELOAD=3D$(pwd)/sl.so pe' > C >=20 >=20 > In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env > var apparently in time to affect the exec'd process. In 8.x & 9.x, it > seems the environment is set and passed to the exec'd process and the > LD_PRELOADed code does not affect that despite its best efforts. >=20 > It seems to me that 6.x behavior is more correct, but I'm seeking > opinions before contemplating if / how to put together a fix. >=20 I suppose that this is a fallback from the POSIXification of putenv(). The libc image of the environment block is now referenced through the environ var. Since csu always reinitialize the environ, effect of the changes made by preloaded dso is cleared. At the end of the message is the patch for HEAD which seems to fix the issue. It is not applicable to stable/9 or 8. You could try to change lib/csu//crt1.c to replace unconditional environ =3D env; assignment with if (environ =3D=3D NULL) environ =3D env; =2E Unfortunately, because csu is linked to the binary, you have to relink the binary after applying the patch and rebuilding the world. In other words, old binaries cannot be fixed. Committing this requires secteam@ review, AFAIR. diff --git a/lib/csu/amd64/crt1.c b/lib/csu/amd64/crt1.c index f33aad6..3740e73 100644 --- a/lib/csu/amd64/crt1.c +++ b/lib/csu/amd64/crt1.c @@ -61,9 +61,7 @@ _start(char **ap, void (*cleanup)(void)) argc =3D *(long *)(void *)ap; argv =3D ap + 1; env =3D ap + 2 + argc; - environ =3D env; - if (argc > 0 && argv[0] !=3D NULL) - handle_progname(argv[0]); + handle_argv(argc, argv, env); =20 if (&_DYNAMIC !=3D NULL) atexit(cleanup); diff --git a/lib/csu/arm/crt1.c b/lib/csu/arm/crt1.c index 127c28d..e3529b8 100644 --- a/lib/csu/arm/crt1.c +++ b/lib/csu/arm/crt1.c @@ -98,10 +98,7 @@ __start(int argc, char **argv, char **env, struct ps_str= ings *ps_strings, const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void)) { =20 - environ =3D env; - - if (argc > 0 && argv[0] !=3D NULL) - handle_progname(argv[0]); + handle_argv(argc, argv, env); =20 if (ps_strings !=3D (struct ps_strings *)0) __ps_strings =3D ps_strings; diff --git a/lib/csu/common/ignore_init.c b/lib/csu/common/ignore_init.c index e3d2441..89b3734 100644 --- a/lib/csu/common/ignore_init.c +++ b/lib/csu/common/ignore_init.c @@ -87,14 +87,18 @@ handle_static_init(int argc, char **argv, char **env) } =20 static inline void -handle_progname(const char *v) +handle_argv(int argc, char *argv[], char **env) { const char *s; =20 - __progname =3D v; - for (s =3D __progname; *s !=3D '\0'; s++) { - if (*s =3D=3D '/') - __progname =3D s + 1; + if (environ =3D=3D NULL) + environ =3D env; + if (argc > 0 && argv[0] !=3D NULL) { + __progname =3D argv[0]; + for (s =3D __progname; *s !=3D '\0'; s++) { + if (*s =3D=3D '/') + __progname =3D s + 1; + } } } =20 diff --git a/lib/csu/i386-elf/crt1_c.c b/lib/csu/i386-elf/crt1_c.c index 3249069..65de04c 100644 --- a/lib/csu/i386-elf/crt1_c.c +++ b/lib/csu/i386-elf/crt1_c.c @@ -61,10 +61,7 @@ _start1(fptr cleanup, int argc, char *argv[]) char **env; =20 env =3D argv + argc + 1; - environ =3D env; - if (argc > 0 && argv[0] !=3D NULL) - handle_progname(argv[0]); - + handle_argv(argc, argv, env); if (&_DYNAMIC !=3D NULL) atexit(cleanup); else diff --git a/lib/csu/mips/crt1.c b/lib/csu/mips/crt1.c index 1968f06..95348b7 100644 --- a/lib/csu/mips/crt1.c +++ b/lib/csu/mips/crt1.c @@ -71,9 +71,7 @@ __start(char **ap, argc =3D * (long *) ap; argv =3D ap + 1; env =3D ap + 2 + argc; - environ =3D env; - if (argc > 0 && argv[0] !=3D NULL) - handle_progname(argv[0]); + handle_argv(argc, argv, env); =20 if (&_DYNAMIC !=3D NULL) atexit(cleanup); diff --git a/lib/csu/powerpc/crt1.c b/lib/csu/powerpc/crt1.c index c3be90d..d1a3ea0 100644 --- a/lib/csu/powerpc/crt1.c +++ b/lib/csu/powerpc/crt1.c @@ -81,10 +81,8 @@ _start(int argc, char **argv, char **env, struct ps_strings *ps_strings) { =20 - environ =3D env; =20 - if (argc > 0 && argv[0] !=3D NULL) - handle_progname(argv[0]); + handle_argv(argc, argv, env); =20 if (ps_strings !=3D (struct ps_strings *)0) __ps_strings =3D ps_strings; diff --git a/lib/csu/powerpc64/crt1.c b/lib/csu/powerpc64/crt1.c index a7c3581..35c5a6e 100644 --- a/lib/csu/powerpc64/crt1.c +++ b/lib/csu/powerpc64/crt1.c @@ -81,10 +81,7 @@ _start(int argc, char **argv, char **env, struct ps_strings *ps_strings) { =20 - environ =3D env; - - if (argc > 0 && argv[0] !=3D NULL) - handle_progname(argv[0]); + handle_argv(argc, argv, env); =20 if (ps_strings !=3D (struct ps_strings *)0) __ps_strings =3D ps_strings; diff --git a/lib/csu/sparc64/crt1.c b/lib/csu/sparc64/crt1.c index 3b3ecc2..e11ae39 100644 --- a/lib/csu/sparc64/crt1.c +++ b/lib/csu/sparc64/crt1.c @@ -85,9 +85,7 @@ _start(char **ap, void (*cleanup)(void), struct Struct_Ob= j_Entry *obj __unused, argc =3D *(long *)(void *)ap; argv =3D ap + 1; env =3D ap + 2 + argc; - environ =3D env; - if (argc > 0 && argv[0] !=3D NULL) - handle_progname(argv[0]); + handle_argv(argc, argv, env); =20 if (&_DYNAMIC !=3D NULL) atexit(cleanup); --g++0NlQhRgFs6nMu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlA3qokACgkQC3+MBN1Mb4jvugCg8+h+yBeBn1WMoX+ROt3xMnrj mw4AoJKR5l7q1Po2kYbjZTlKycHKd7Pn =XOqT -----END PGP SIGNATURE----- --g++0NlQhRgFs6nMu-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 24 17:25:52 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1941F106564A; Fri, 24 Aug 2012 17:25:52 +0000 (UTC) (envelope-from jhein@symmetricom.com) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 885408FC16; Fri, 24 Aug 2012 17:25:46 +0000 (UTC) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q7OHPiAk014470; Fri, 24 Aug 2012 11:25:44 -0600 (MDT) (envelope-from jhein@symmetricom.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.5/8.14.5) with ESMTP id q7OHP7aJ045088; Fri, 24 Aug 2012 11:25:07 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.5/8.14.5/Submit) id q7OHP7GG045087; Fri, 24 Aug 2012 11:25:07 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20535.47346.913434.799005@gromit.timing.com> Date: Fri, 24 Aug 2012 11:25:06 -0600 From: John Hein To: Konstantin Belousov In-Reply-To: <20120824162338.GV33100@deviant.kiev.zoral.com.ua> References: <20535.39682.330250.337503@gromit.timing.com> <20120824162338.GV33100@deviant.kiev.zoral.com.ua> X-Mailer: VM 8.2.0b-trunk-1408 under 23.4.1 (i386-portbld-freebsd7.4) Cc: hackers@freebsd.org, secteam@freebsd.org Subject: Re: LD_PRELOADed code before or after exec - different behavior after 6.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:25:52 -0000 Answers inline... Konstantin Belousov wrote at 19:23 +0300 on Aug 24, 2012: > On Fri, Aug 24, 2012 at 09:17:22AM -0600, John Hein wrote: > > > > head sl.cc pe.c > > ==> sl.cc <== > > #include > > #include > > class C > > { > > public: > > C(){ > > printf("C\n"); > > unsetenv("XXX"); > > } > > }; > > static C c; > > > > ==> pe.c <== > > #include > > #include > > int > > main() > > { > > char *p=getenv("XXX"); > > if (p != NULL) > > printf("XXX=%s\n",p); > > return 0; > > } > > > > > > % g++ -fpic -shared sl.cc -o sl.so > > % gcc pe.c -o pe > > > > 7.x & 8.x ... > > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' > > C > > XXX=1 > > > > 6.x & 4.x ... > > % sh -c 'XXX=1 LD_PRELOAD=$(pwd)/sl.so pe' > > C > > > > > > In 6.x and earlier (fedora 16, too), the unsetenv clears the XXX env > > var apparently in time to affect the exec'd process. In 8.x & 9.x, it > > seems the environment is set and passed to the exec'd process and the > > LD_PRELOADed code does not affect that despite its best efforts. > > > > It seems to me that 6.x behavior is more correct, but I'm seeking > > opinions before contemplating if / how to put together a fix. > > > I suppose that this is a fallback from the POSIXification of putenv(). > The libc image of the environment block is now referenced through > the environ var. Since csu always reinitialize the environ, effect > of the changes made by preloaded dso is cleared. > > At the end of the message is the patch for HEAD which seems to fix the > issue. It is not applicable to stable/9 or 8. You could try to change > lib/csu//crt1.c to replace unconditional > environ = env; > assignment with > if (environ == NULL) > environ = env; > . Thanks. This fixes my reported problem - tested on 8.x. > Unfortunately, because csu is linked to the binary, you have to relink > the binary after applying the patch and rebuilding the world. In other > words, old binaries cannot be fixed. > > Committing this requires secteam@ review, AFAIR. Indeed this could be a sec issue if someone relies on preloaded code clearing something in the environment. secteam CC'd > diff --git a/lib/csu/amd64/crt1.c b/lib/csu/amd64/crt1.c > index f33aad6..3740e73 100644 > --- a/lib/csu/amd64/crt1.c > +++ b/lib/csu/amd64/crt1.c > @@ -61,9 +61,7 @@ _start(char **ap, void (*cleanup)(void)) > argc = *(long *)(void *)ap; > argv = ap + 1; > env = ap + 2 + argc; > - environ = env; > - if (argc > 0 && argv[0] != NULL) > - handle_progname(argv[0]); > + handle_argv(argc, argv, env); > > if (&_DYNAMIC != NULL) > atexit(cleanup); > diff --git a/lib/csu/arm/crt1.c b/lib/csu/arm/crt1.c > index 127c28d..e3529b8 100644 > --- a/lib/csu/arm/crt1.c > +++ b/lib/csu/arm/crt1.c > @@ -98,10 +98,7 @@ __start(int argc, char **argv, char **env, struct ps_strings *ps_strings, > const struct Struct_Obj_Entry *obj __unused, void (*cleanup)(void)) > { > > - environ = env; > - > - if (argc > 0 && argv[0] != NULL) > - handle_progname(argv[0]); > + handle_argv(argc, argv, env); > > if (ps_strings != (struct ps_strings *)0) > __ps_strings = ps_strings; > diff --git a/lib/csu/common/ignore_init.c b/lib/csu/common/ignore_init.c > index e3d2441..89b3734 100644 > --- a/lib/csu/common/ignore_init.c > +++ b/lib/csu/common/ignore_init.c > @@ -87,14 +87,18 @@ handle_static_init(int argc, char **argv, char **env) > } > > static inline void > -handle_progname(const char *v) > +handle_argv(int argc, char *argv[], char **env) > { > const char *s; > > - __progname = v; > - for (s = __progname; *s != '\0'; s++) { > - if (*s == '/') > - __progname = s + 1; > + if (environ == NULL) > + environ = env; > + if (argc > 0 && argv[0] != NULL) { > + __progname = argv[0]; > + for (s = __progname; *s != '\0'; s++) { > + if (*s == '/') > + __progname = s + 1; > + } > } > } > > diff --git a/lib/csu/i386-elf/crt1_c.c b/lib/csu/i386-elf/crt1_c.c > index 3249069..65de04c 100644 > --- a/lib/csu/i386-elf/crt1_c.c > +++ b/lib/csu/i386-elf/crt1_c.c > @@ -61,10 +61,7 @@ _start1(fptr cleanup, int argc, char *argv[]) > char **env; > > env = argv + argc + 1; > - environ = env; > - if (argc > 0 && argv[0] != NULL) > - handle_progname(argv[0]); > - > + handle_argv(argc, argv, env); > if (&_DYNAMIC != NULL) > atexit(cleanup); > else > diff --git a/lib/csu/mips/crt1.c b/lib/csu/mips/crt1.c > index 1968f06..95348b7 100644 > --- a/lib/csu/mips/crt1.c > +++ b/lib/csu/mips/crt1.c > @@ -71,9 +71,7 @@ __start(char **ap, > argc = * (long *) ap; > argv = ap + 1; > env = ap + 2 + argc; > - environ = env; > - if (argc > 0 && argv[0] != NULL) > - handle_progname(argv[0]); > + handle_argv(argc, argv, env); > > if (&_DYNAMIC != NULL) > atexit(cleanup); > diff --git a/lib/csu/powerpc/crt1.c b/lib/csu/powerpc/crt1.c > index c3be90d..d1a3ea0 100644 > --- a/lib/csu/powerpc/crt1.c > +++ b/lib/csu/powerpc/crt1.c > @@ -81,10 +81,8 @@ _start(int argc, char **argv, char **env, > struct ps_strings *ps_strings) > { > > - environ = env; > > - if (argc > 0 && argv[0] != NULL) > - handle_progname(argv[0]); > + handle_argv(argc, argv, env); > > if (ps_strings != (struct ps_strings *)0) > __ps_strings = ps_strings; > diff --git a/lib/csu/powerpc64/crt1.c b/lib/csu/powerpc64/crt1.c > index a7c3581..35c5a6e 100644 > --- a/lib/csu/powerpc64/crt1.c > +++ b/lib/csu/powerpc64/crt1.c > @@ -81,10 +81,7 @@ _start(int argc, char **argv, char **env, > struct ps_strings *ps_strings) > { > > - environ = env; > - > - if (argc > 0 && argv[0] != NULL) > - handle_progname(argv[0]); > + handle_argv(argc, argv, env); > > if (ps_strings != (struct ps_strings *)0) > __ps_strings = ps_strings; > diff --git a/lib/csu/sparc64/crt1.c b/lib/csu/sparc64/crt1.c > index 3b3ecc2..e11ae39 100644 > --- a/lib/csu/sparc64/crt1.c > +++ b/lib/csu/sparc64/crt1.c > @@ -85,9 +85,7 @@ _start(char **ap, void (*cleanup)(void), struct Struct_Obj_Entry *obj __unused, > argc = *(long *)(void *)ap; > argv = ap + 1; > env = ap + 2 + argc; > - environ = env; > - if (argc > 0 && argv[0] != NULL) > - handle_progname(argv[0]); > + handle_argv(argc, argv, env); > > if (&_DYNAMIC != NULL) > atexit(cleanup); > [DELETED ATTACHMENT , application/pgp-signature] From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 24 22:16:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7670C106566C for ; Fri, 24 Aug 2012 22:16:58 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id ECF428FC0A for ; Fri, 24 Aug 2012 22:16:57 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id EB9C0358C5D for ; Sat, 25 Aug 2012 00:16:55 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id C40F62847B; Sat, 25 Aug 2012 00:16:55 +0200 (CEST) Date: Sat, 25 Aug 2012 00:16:55 +0200 From: Jilles Tjoelker To: freebsd-hackers@freebsd.org Message-ID: <20120824221655.GA76607@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [patch] libc: Do not export .cerror X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 22:16:58 -0000 For some reason, libc exports the symbol .cerror (HIDENAME(cerror)), albeit in the FBSDprivate_1.0 version. It looks like there is no reason for this since it is not used from other libraries. Given that it cannot be accessed from C and its strange calling convention, it is rather unlikely that other things rely on it. Perhaps it is from a time when symbols could not be hidden. Not exporting .cerror causes it to be jumped to directly instead of via the PLT. The below patch is for i386 only and also takes advantage of .cerror's new status by not saving and loading %ebx before jumping to it. (Therefore, .cerror now saves and loads %ebx itself.) Where there was a conditional jump to a jump to .cerror, the conditional jump has been changed to jump to .cerror directly (many modern CPUs don't do static prediction and in any case it is not much of a benefit anyway). The patch decreases the size of libc.so.7 by a few kilobytes. Similar changes could be made to other architectures, and there may be more symbols that are exported but need not be. Index: lib/libc/i386/Symbol.map =================================================================== --- lib/libc/i386/Symbol.map (revision 239195) +++ lib/libc/i386/Symbol.map (working copy) @@ -63,7 +63,6 @@ __sys_vfork; _vfork; _end; - .cerror; _brk; .curbrk; .minbrk; Index: lib/libc/i386/SYS.h =================================================================== --- lib/libc/i386/SYS.h (revision 239195) +++ lib/libc/i386/SYS.h (working copy) @@ -36,21 +36,21 @@ #include #include -#define SYSCALL(x) 2: PIC_PROLOGUE; jmp PIC_PLT(HIDENAME(cerror)); \ - ENTRY(__CONCAT(__sys_,x)); \ +#define SYSCALL(x) ENTRY(__CONCAT(__sys_,x)); \ .weak CNAME(x); \ .set CNAME(x),CNAME(__CONCAT(__sys_,x)); \ .weak CNAME(__CONCAT(_,x)); \ .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ - mov __CONCAT($SYS_,x),%eax; KERNCALL; jb 2b + mov __CONCAT($SYS_,x),%eax; KERNCALL; \ + jb HIDENAME(cerror) #define RSYSCALL(x) SYSCALL(x); ret; END(__CONCAT(__sys_,x)) -#define PSEUDO(x) 2: PIC_PROLOGUE; jmp PIC_PLT(HIDENAME(cerror)); \ - ENTRY(__CONCAT(__sys_,x)); \ +#define PSEUDO(x) ENTRY(__CONCAT(__sys_,x)); \ .weak CNAME(__CONCAT(_,x)); \ .set CNAME(__CONCAT(_,x)),CNAME(__CONCAT(__sys_,x)); \ - mov __CONCAT($SYS_,x),%eax; KERNCALL; jb 2b; ret; \ + mov __CONCAT($SYS_,x),%eax; KERNCALL; \ + jb HIDENAME(cerror); ret; \ END(__CONCAT(__sys_,x)) /* gas messes up offset -- although we don't currently need it, do for BCS */ Index: lib/libc/i386/gen/rfork_thread.S =================================================================== --- lib/libc/i386/gen/rfork_thread.S (revision 239195) +++ lib/libc/i386/gen/rfork_thread.S (working copy) @@ -113,8 +113,7 @@ popl %esi movl %ebp, %esp popl %ebp - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) + jmp HIDENAME(cerror) END(rfork_thread) .section .note.GNU-stack,"",%progbits Index: lib/libc/i386/sys/brk.S =================================================================== --- lib/libc/i386/sys/brk.S (revision 239195) +++ lib/libc/i386/sys/brk.S (working copy) @@ -58,14 +58,11 @@ ok: mov $SYS_break,%eax KERNCALL - jb err + jb HIDENAME(cerror) movl 4(%esp),%eax movl %eax,(%edx) movl $0,%eax ret -err: - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) #else @@ -77,13 +74,11 @@ ok: mov $SYS_break,%eax KERNCALL - jb err + jb HIDENAME(cerror) movl 4(%esp),%eax movl %eax,HIDENAME(curbrk) movl $0,%eax ret -err: - jmp HIDENAME(cerror) #endif END(brk) Index: lib/libc/i386/sys/getcontext.S =================================================================== --- lib/libc/i386/sys/getcontext.S (revision 239195) +++ lib/libc/i386/sys/getcontext.S (working copy) @@ -42,12 +42,9 @@ movl (%esp),%ecx /* save getcontext return address */ mov $SYS_getcontext,%eax KERNCALL - jb 1f + jb HIDENAME(cerror) addl $4,%esp /* remove stale (setcontext) return address */ jmp *%ecx /* restore return address */ -1: - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) END(__sys_getcontext) .section .note.GNU-stack,"",%progbits Index: lib/libc/i386/sys/cerror.S =================================================================== --- lib/libc/i386/sys/cerror.S (revision 239195) +++ lib/libc/i386/sys/cerror.S (working copy) @@ -48,13 +48,14 @@ .globl CNAME(__error) .type CNAME(__error),@function HIDENAME(cerror): +#ifdef PIC + PIC_PROLOGUE pushl %eax -#ifdef PIC - /* The caller must execute the PIC prologue before jumping to cerror. */ call PIC_PLT(CNAME(__error)) popl %ecx PIC_EPILOGUE #else + pushl %eax call CNAME(__error) popl %ecx #endif Index: lib/libc/i386/sys/sbrk.S =================================================================== --- lib/libc/i386/sys/sbrk.S (revision 239195) +++ lib/libc/i386/sys/sbrk.S (working copy) @@ -59,7 +59,7 @@ addl %eax,4(%esp) mov $SYS_break,%eax KERNCALL - jb err + jb HIDENAME(cerror) PIC_PROLOGUE movl PIC_GOT(HIDENAME(curbrk)),%edx movl (%edx),%eax @@ -67,9 +67,6 @@ PIC_EPILOGUE back: ret -err: - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) #else /* !PIC */ @@ -80,13 +77,11 @@ addl %eax,4(%esp) mov $SYS_break,%eax KERNCALL - jb err + jb HIDENAME(cerror) movl HIDENAME(curbrk),%eax addl %ecx,HIDENAME(curbrk) back: ret -err: - jmp HIDENAME(cerror) #endif /* PIC */ END(sbrk) Index: lib/libc/i386/sys/Ovfork.S =================================================================== --- lib/libc/i386/sys/Ovfork.S (revision 239195) +++ lib/libc/i386/sys/Ovfork.S (working copy) @@ -50,8 +50,7 @@ jmp *%ecx 1: pushl %ecx - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) + jmp HIDENAME(cerror) END(__sys_vfork) .section .note.GNU-stack,"",%progbits Index: lib/libc/i386/sys/ptrace.S =================================================================== --- lib/libc/i386/sys/ptrace.S (revision 239195) +++ lib/libc/i386/sys/ptrace.S (working copy) @@ -50,11 +50,8 @@ #endif mov $SYS_ptrace,%eax KERNCALL - jb err + jb HIDENAME(cerror) ret -err: - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) END(ptrace) .section .note.GNU-stack,"",%progbits Index: lib/libc/i386/sys/exect.S =================================================================== --- lib/libc/i386/sys/exect.S (revision 239195) +++ lib/libc/i386/sys/exect.S (working copy) @@ -47,8 +47,7 @@ pushl %edx popf KERNCALL - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) /* exect(file, argv, env); */ + jmp HIDENAME(cerror) /* exect(file, argv, env); */ END(exect) .section .note.GNU-stack,"",%progbits Index: lib/libc/i386/sys/syscall.S =================================================================== --- lib/libc/i386/sys/syscall.S (revision 239195) +++ lib/libc/i386/sys/syscall.S (working copy) @@ -45,11 +45,8 @@ KERNCALL push %ecx /* need to push a word to keep stack frame intact upon return; the word must be the return address. */ - jb 1f + jb HIDENAME(cerror) ret -1: - PIC_PROLOGUE - jmp PIC_PLT(HIDENAME(cerror)) END(syscall) .section .note.GNU-stack,"",%progbits -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 25 02:54:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADCCF1065670 for ; Sat, 25 Aug 2012 02:54:40 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 634108FC08 for ; Sat, 25 Aug 2012 02:54:40 +0000 (UTC) Received: from laptop3.herveybayaustralia.com.au (unknown [192.168.0.147]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id ACB865C29 for ; Sat, 25 Aug 2012 13:10:05 +1000 (EST) Message-ID: <50383E6E.1090304@herveybayaustralia.com.au> Date: Sat, 25 Aug 2012 12:54:38 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120728 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: webdav locking issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 02:54:40 -0000 I did try without success to ask some aspect of this on the questions list, but I'm farther along with this anyway. I have an apache22 server setup with webdav for a subversion server. That is working well (I think, anyway), and I'm able access it from a Winblows XP vm I use for various testing and so forth. I'm still trying to resolve some issues with Windows7, but it appears to work in the apache logs. Apache/webdav is setup with ssl and digest auth - no access unless auth'd. Locking appears to be working as well according to logs and cadaver. libreoffice won't build with java, and doesn't appear to like direct webdav access- certificate issues. But that dog won't hunt anyway due to the minimal user friendliness (if that is actually a term). Even with locking disabled the issue remains. wdfs is what is intended to use for general access (I'm open to suggestion though), and I have tried non-threaded operation, locking modes, no locking, and foreground operation. Without locking, the office's complain about io errors. Using the foreground operation of wdfs and the logs, I can see wdfs lock the file and retrieve it and attempt to lock it again. This errors badly obviously, and wdfs tells office's to come back with read only options. Quite frankly I need a little help on where to go from here. I'm trying to figure out what I'm missing exactly. ATM my best guess would be an issue with wdfs, but there isn't much on the google about it. Any thoughts? From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 25 19:21:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E08F106566C; Sat, 25 Aug 2012 19:21:49 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 762F68FC0A; Sat, 25 Aug 2012 19:21:49 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q7PJLh7g075910; Sat, 25 Aug 2012 12:21:43 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <503925C7.7080202@rawbw.com> Date: Sat, 25 Aug 2012 12:21:43 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120802 Thunderbird/14.0 MIME-Version: 1.0 To: attilio@freebsd.org References: <501871FD.601@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: How to diagnose system freezes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 19:21:49 -0000 On 07/31/2012 17:20, Attilio Rao wrote: > Start by adding SW_WATCHDOG to your machine with a reasonably low timeout. > Also, can you use a serial console? If yes you may consider going with > a serial break. The difference with the GENERIC is mainly the addition of these lines, which make it debug image and add SW_WATCHDOG, etc. (also add dtrace) options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF makeoptions WITH_CTF=1 makeoptions DEBUG="-g" options SW_WATCHDOG options DIAGNOSTIC options DDB # Support DDB. options GDB # Support remote GDB Npw, with this config, system doesn't hang indefinitely. Instead, it hangs for ~1 minute and then reboots. It doesn't drop into debugger and doesn't leave anything in messages. I didn't yet try 4BSD scheduler as Doug Barton suggested. Anything else I can try? One thing of importance here is that there is an older graphics card 9400 GT on this system and current nvidia-driver-295.71 has an issue with 9400 GT: it makes graphics to malfunction (unpainted windows, long delays switching to terminal mode) or freezes Xorg (but not OS). So I run the older nvidia-driver-285.05.09 which appears to work. That's why I think that nvidia driver is probably to blame for these periodic OS freezes. Also the latest driver version must be, obviously, working for most people because (I think) they mostly have newer than mine nvidia cards. So maybe I should also just get the newer nvidia card and shut up, not sure. Yuri From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 25 20:12:12 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD3FC106566C for ; Sat, 25 Aug 2012 20:12:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 29F1C8FC0C for ; Sat, 25 Aug 2012 20:12:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA24987; Sat, 25 Aug 2012 23:11:55 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1T5Mi2-0008ol-Mo; Sat, 25 Aug 2012 23:11:54 +0300 Message-ID: <50393188.6030304@FreeBSD.org> Date: Sat, 25 Aug 2012 23:11:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Yuri References: <501871FD.601@rawbw.com> <503925C7.7080202@rawbw.com> In-Reply-To: <503925C7.7080202@rawbw.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: How to diagnose system freezes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 20:12:13 -0000 on 25/08/2012 22:21 Yuri said the following: > On 07/31/2012 17:20, Attilio Rao wrote: >> Start by adding SW_WATCHDOG to your machine with a reasonably low timeout. >> Also, can you use a serial console? If yes you may consider going with >> a serial break. > > The difference with the GENERIC is mainly the addition of these lines, which > make it debug image and add SW_WATCHDOG, etc. (also add dtrace) > options KDTRACE_FRAME # Ensure frames are compiled in > options KDTRACE_HOOKS # Kernel DTrace hooks > options DDB_CTF > makeoptions WITH_CTF=1 > makeoptions DEBUG="-g" > options SW_WATCHDOG > options DIAGNOSTIC > options DDB # Support DDB. > options GDB # Support remote GDB > > Npw, with this config, system doesn't hang indefinitely. Instead, it hangs for > ~1 minute and then reboots. It doesn't drop into debugger and doesn't leave > anything in messages. > > I didn't yet try 4BSD scheduler as Doug Barton suggested. > > Anything else I can try? options KDB options KDB_TRACE options KDB_UNATTENDED > One thing of importance here is that there is an older graphics card 9400 GT on > this system and current nvidia-driver-295.71 has an issue with 9400 GT: it makes > graphics to malfunction (unpainted windows, long delays switching to terminal > mode) or freezes Xorg (but not OS). So I run the older nvidia-driver-285.05.09 > which appears to work. > That's why I think that nvidia driver is probably to blame for these periodic OS > freezes. Also the latest driver version must be, obviously, working for most > people because (I think) they mostly have newer than mine nvidia cards. So maybe > I should also just get the newer nvidia card and shut up, not sure. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 25 20:48:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC32F106568C; Sat, 25 Aug 2012 20:48:04 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id BA3108FC1D; Sat, 25 Aug 2012 20:48:04 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q7PKm3En090009; Sat, 25 Aug 2012 13:48:03 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <50393A03.3010803@rawbw.com> Date: Sat, 25 Aug 2012 13:48:03 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120802 Thunderbird/14.0 MIME-Version: 1.0 To: Andriy Gapon References: <501871FD.601@rawbw.com> <503925C7.7080202@rawbw.com> <50393188.6030304@FreeBSD.org> In-Reply-To: <50393188.6030304@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: How to diagnose system freezes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 20:48:05 -0000 On 08/25/2012 13:11, Andriy Gapon wrote: > options KDB > options KDB_TRACE > options KDB_UNATTENDED KDB and KDB_TRACE are on by default in 9.1 that I am running. Yuri