From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 12 00:11: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 1D1E5106564A; Sun, 12 Aug 2012 00:11:41 +0000 (UTC) (envelope-from listlog2011@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 D6B2F8FC08; Sun, 12 Aug 2012 00:11:40 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so5286746pbb.13 for ; Sat, 11 Aug 2012 17:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZP6GyUQZ8/4FvYMm8kWBFXORneiuwU2sLDfA/lWP5L8=; b=p8ciIF+E7+vngEcPrUruDj9zZ3gD18Z92okLC8ujKV0OlLTa1XyV09ClGYCd0qM/Hl p0F/ABA5NtrZyjh3VBWBLf27bFhQ+Z1UPIBFLG9iulKOwnT6fMjceLNYrWYQeqLrNZGi h8Fx/s/hEd5/xL/sKcAQQU44qYsfxStOxxa8U3K/gEpWR0mAoJlW+V7U7zRPIEwy2NFb vQdXN1w73d9YkLgE9/WifKYnhISV9yC/2c07rgaiDqiUXYAIl0UMB2ohO+U1jg4IgRhM +f5NRUuNnnh446/UlpMxrs6D6mN543hIS6sVlBw+fJLwwsDEFWD3FhQfCd+lAiNUgO5q gCDA== Received: by 10.66.73.202 with SMTP id n10mr8501410pav.80.1344730299451; Sat, 11 Aug 2012 17:11:39 -0700 (PDT) Received: from xp5k.my.domain ([220.184.76.3]) by mx.google.com with ESMTPS id nr2sm2232899pbc.48.2012.08.11.17.11.36 (version=SSLv3 cipher=OTHER); Sat, 11 Aug 2012 17:11:38 -0700 (PDT) Message-ID: <5026F4B1.5030000@gmail.com> Date: Sun, 12 Aug 2012 08:11:29 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <20120809110850.GA2425@deviant.kiev.zoral.com.ua> <20120810101302.GF2425@deviant.kiev.zoral.com.ua> In-Reply-To: <20120810101302.GF2425@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Aug 2012 01:39:58 +0000 Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, Jilles Tjoelker 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, 12 Aug 2012 00:11:41 -0000 On 2012/08/10 18:13, Konstantin Belousov wrote: > On Thu, Aug 09, 2012 at 02:08:50PM +0300, Konstantin Belousov wrote: >> Third alternative, which seems to be even better, is to restore >> single-threading of the parent for vfork(). single-threading is slow for large threaded process, don't know if it is necessary for vfork(), POSIX says nothing about threaded process. > I mean this patch. > > > diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c > index 6cb95cd..e59ee21 100644 > --- a/sys/kern/kern_fork.c > +++ b/sys/kern/kern_fork.c > @@ -756,7 +756,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > struct thread *td2; > struct vmspace *vm2; > vm_ooffset_t mem_charged; > - int error; > + int error, single_threaded; > static int curfail; > static struct timeval lastfail; > #ifdef PROCDESC > @@ -815,6 +815,19 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > } > #endif > > + if (((p1->p_flag & (P_HADTHREADS | P_SYSTEM)) == P_HADTHREADS) && > + (flags & RFPPWAIT) != 0) { > + PROC_LOCK(p1); > + if (thread_single(SINGLE_BOUNDARY)) { > + PROC_UNLOCK(p1); > + error = ERESTART; > + goto fail2; > + } > + PROC_UNLOCK(p1); > + single_threaded = 1; > + } else > + single_threaded = 0; > + > mem_charged = 0; > vm2 = NULL; > if (pages == 0) > @@ -945,6 +958,12 @@ fail1: > if (vm2 != NULL) > vmspace_free(vm2); > uma_zfree(proc_zone, newproc); > + if (single_threaded) { > + PROC_LOCK(p1); > + thread_single_end(); > + PROC_UNLOCK(p1); > + } > +fail2: > #ifdef PROCDESC > if (((flags & RFPROCDESC) != 0) && (fp_procdesc != NULL)) { > fdclose(td->td_proc->p_fd, fp_procdesc, *procdescp, td); > diff --git a/tools/test/pthread_vfork/pthread_vfork_test.c b/tools/test/pthread_vfork/pthread_vfork_test.c > index e004727..88956c2 100644 > --- a/tools/test/pthread_vfork/pthread_vfork_test.c > +++ b/tools/test/pthread_vfork/pthread_vfork_test.c > @@ -29,6 +29,8 @@ > #include > __FBSDID("$FreeBSD$"); > > +#include > +#include > #include > #include > #include > @@ -39,10 +41,11 @@ __FBSDID("$FreeBSD$"); > > #define NUM_THREADS 100 > > -void * > -vfork_test(void *threadid) > +static void * > +vfork_test(void *threadid __unused) > { > - pid_t pid; > + pid_t pid, wpid; > + int status; > > for (;;) { > pid = vfork(); > @@ -50,10 +53,20 @@ vfork_test(void *threadid) > _exit(0); > else if (pid == -1) > err(1, "Failed to vfork"); > + else { > + wpid = waitpid(pid, &status, 0); > + if (wpid == -1) > + err(1, "waitpid"); > + } > } > return (NULL); > } > > +static void > +sighandler(int signo __unused) > +{ > +} > + > /* > * This program invokes multiple threads and each thread calls > * vfork() system call. > @@ -63,19 +76,24 @@ main(void) > { > pthread_t threads[NUM_THREADS]; > struct sigaction reapchildren; > + sigset_t sigchld_mask; > int rc, t; > > memset(&reapchildren, 0, sizeof(reapchildren)); > - reapchildren.sa_handler = SIG_IGN; > - > - /* Automatically reap zombies. */ > + reapchildren.sa_handler = sighandler; > if (sigaction(SIGCHLD, &reapchildren, NULL) == -1) > err(1, "Could not sigaction(SIGCHLD)"); > > + sigemptyset(&sigchld_mask); > + sigaddset(&sigchld_mask, SIGCHLD); > + if (sigprocmask(SIG_BLOCK, &sigchld_mask, NULL) == -1) > + err(1, "sigprocmask"); > + > for (t = 0; t < NUM_THREADS; t++) { > rc = pthread_create(&threads[t], NULL, vfork_test, (void *)t); > if (rc) > errc(1, rc, "pthread_create"); > } > + pause(); > return (0); > } From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 12 09:44:50 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 1C75D106566C for ; Sun, 12 Aug 2012 09:44:50 +0000 (UTC) (envelope-from kuku@kukulies.org) Received: from kukulies.org (mail.kukulies.org [78.47.239.221]) by mx1.freebsd.org (Postfix) with ESMTP id C7F098FC14 for ; Sun, 12 Aug 2012 09:44:48 +0000 (UTC) Received: by kukulies.org (Postfix, from userid 5001) id 36BFE1AD860; Sun, 12 Aug 2012 11:44:42 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on kukulies.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED autolearn=ham version=3.3.2 Received: from [192.168.2.103] (p508F5D56.dip.t-dialin.net [80.143.93.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kukulies.org (Postfix) with ESMTPSA id 56D631AD85F; Sun, 12 Aug 2012 11:44:41 +0200 (CEST) Message-ID: <50277B06.2080305@kukulies.org> Date: Sun, 12 Aug 2012 11:44:38 +0200 From: "Christoph P.U. Kukulies" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bob Bishop References: <50251F03.4050400@kukulies.org> <1668355C-7597-4878-9D0B-164B051E1CA7@gid.co.uk> In-Reply-To: <1668355C-7597-4878-9D0B-164B051E1CA7@gid.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: strange things happening with ping - am I hacked? 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, 12 Aug 2012 09:44:50 -0000 Am 10.08.2012 17:28, schrieb Bob Bishop: > Hi, > > On 10 Aug 2012, at 15:47, Christoph P.U. Kukulies wrote: > >> I have some machines in a companys' network that are interconnected >> with a piece of coaxial cable (ethernet 10base2). This trunk goes through a >> switch that acts also as a media converter and connects to the Internet router. >> >> For a while now I'm having trouble with this 10base2 trunk > It might just be packets getting corrupted, just a few replies get back with address field corruption. > Thanks. I will exchange the switch/mediaconverter next. -- Christoph From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 08:24: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 6EAC5106564A for ; Mon, 13 Aug 2012 08:24:51 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EE4DA8FC0A for ; Mon, 13 Aug 2012 08:24:50 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1322432bkc.13 for ; Mon, 13 Aug 2012 01:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zGrPBB67N3YaaU8zFFxt/D6J28VEeja8gyrryJ3n6oE=; b=OlhjAO+GdL7QIc5B9ynlpvv34VeTsPHKfqKdw5za/xAJNTLtBD5mL68ZLkxtxF7gSM R1LLncoUVw6ZH3NB99OfhRF00Dmi4zhQnoU2xXsj+cUjTcLCTaKYap71AP9gApkTqeOp hPZ9J0OiaN/nV7ZYR8b0wG579EhUwZRhLMBsAIozU1CT0Tb+VY8HYjyYIpw/e5/hPN3Y 4LjDHw+NS2ssicFRhbho7OZYvanvjRG/T35fGD24jKAW8lr4rVq/rdQmiCmaB0quQJsv H3qUMZojRhzUimYwWbX4vVjLdufZNx3XvswB4+1Mknl4uHcfNdkeeW9N/fhJlSUr/Se3 uR4g== Received: by 10.204.157.7 with SMTP id z7mr3895345bkw.14.1344846289753; Mon, 13 Aug 2012 01:24:49 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id n17sm2262232bks.6.2012.08.13.01.24.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Aug 2012 01:24:48 -0700 (PDT) Message-ID: <5028B9C4.60000@gmail.com> Date: Mon, 13 Aug 2012 12:54:36 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: How to know __FreeBSD_version for a symbol 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, 13 Aug 2012 08:24:51 -0000 Hi hackers In the process of back porting drivers to older freebsd versions, We sometimes need to add suitable '#if __FreeBSD_version >= xxxxx ... else ... ' directives to the source to use an alternate function or exclude certain statements, defines, etc. What is the best (quick/reliable) way to know in which __FreeBSD_version a symbol (function, struct member, macro, ...) has been first introduced? From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 11:50:30 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 6F26E1065672; Mon, 13 Aug 2012 11:50:30 +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 838FF8FC0C; Mon, 13 Aug 2012 11:50:29 +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 q7DBoYsl086109; Mon, 13 Aug 2012 14:50:34 +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 q7DBoL1Z005567; Mon, 13 Aug 2012 14:50:21 +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 q7DBoLkm005566; Mon, 13 Aug 2012 14:50:21 +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: Mon, 13 Aug 2012 14:50:21 +0300 From: Konstantin Belousov To: David Xu Message-ID: <20120813115021.GE2352@deviant.kiev.zoral.com.ua> References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <20120809110850.GA2425@deviant.kiev.zoral.com.ua> <20120810101302.GF2425@deviant.kiev.zoral.com.ua> <5026F4B1.5030000@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="idY8LE8SD6/8DnRI" Content-Disposition: inline In-Reply-To: <5026F4B1.5030000@gmail.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: freebsd-hackers@freebsd.org, davidxu@freebsd.org, Jilles Tjoelker 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: Mon, 13 Aug 2012 11:50:30 -0000 --idY8LE8SD6/8DnRI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 12, 2012 at 08:11:29AM +0800, David Xu wrote: > On 2012/08/10 18:13, Konstantin Belousov wrote: > >On Thu, Aug 09, 2012 at 02:08:50PM +0300, Konstantin Belousov wrote: > >>Third alternative, which seems to be even better, is to restore > >>single-threading of the parent for vfork(). > single-threading is slow for large threaded process, don't know if it > is necessary for vfork(), POSIX says nothing about threaded process. I agree that with both of your statements. But, being fast but allowing silent process corruption is not good behaviour. Either we need to actually support vfork() for threaded processes, or disable it with some error code. I prefer to support it. I believe that vfork() should be wrapped by libthr in the same way as fork() is wrapped. Not sure should we call atfork handlers, for now I decided not to call, since the handlers assume separate address spaces for parent/child. But we could only call parent handler in child, however weird this sounds. The real complication with wrapping is the fact that we cannot return from wrapper in child without destroying parent state. So I tried to prototype the code to handle the wrapping in the same frame, thus neccessity of using asm. Below is WIP, only for amd64 ATM. 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..07d813d --- /dev/null +++ b/lib/libthr/arch/amd64/amd64/vfork.S @@ -0,0 +1,74 @@ +/*- + * 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. + */ + +#if defined(SYSLIBC_SCCS) && !defined(lint) + .asciz "@(#)Ovfork.s 5.1 (Berkeley) 4/23/90" +#endif /* SYSLIBC_SCCS and not lint */ +#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 _thr_vfork_post + popq %rsi + popq %rsi + xorl %eax,%eax +1: + jmp *%rsi +2: + pushq %rsi + pushq %rax + call _thr_vfork_post + call PIC_PLT(CNAME(__error)) + popq %rdx + movq %rdx,(%rax) + movq $-1,%rax + movq $-1,%rdx + retq +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..30f3de2 100644 --- a/lib/libthr/thread/thr_private.h +++ b/lib/libthr/thread/thr_private.h @@ -777,6 +777,8 @@ 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(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 +835,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_vfork.c b/lib/libthr/thread/thr_vfork.c new file mode 100644 index 0000000..bed7db5 --- /dev/null +++ b/lib/libthr/thread/thr_vfork.c @@ -0,0 +1,112 @@ +/* + * 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_rdlock(&_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(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); +} diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 6cb95cd..8735c25 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; @@ -756,7 +752,7 @@ fork1(struct thread *td, int flags, int pages, struct p= roc **procp, struct thread *td2; struct vmspace *vm2; vm_ooffset_t mem_charged; - int error; + int error, single_threaded; static int curfail; static struct timeval lastfail; #ifdef PROCDESC @@ -815,6 +811,19 @@ fork1(struct thread *td, int flags, int pages, struct = proc **procp, } #endif =20 + if (((p1->p_flag & (P_HADTHREADS | P_SYSTEM)) =3D=3D P_HADTHREADS) && + (flags & RFPPWAIT) !=3D 0) { + PROC_LOCK(p1); + if (thread_single(SINGLE_BOUNDARY)) { + PROC_UNLOCK(p1); + error =3D ERESTART; + goto fail2; + } + PROC_UNLOCK(p1); + single_threaded =3D 1; + } else + single_threaded =3D 0; + mem_charged =3D 0; vm2 =3D NULL; if (pages =3D=3D 0) @@ -945,6 +954,12 @@ fail1: if (vm2 !=3D NULL) vmspace_free(vm2); uma_zfree(proc_zone, newproc); + if (single_threaded) { + PROC_LOCK(p1); + thread_single_end(); + PROC_UNLOCK(p1); + } +fail2: #ifdef PROCDESC if (((flags & RFPROCDESC) !=3D 0) && (fp_procdesc !=3D NULL)) { fdclose(td->td_proc->p_fd, fp_procdesc, *procdescp, td); --idY8LE8SD6/8DnRI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAo6f0ACgkQC3+MBN1Mb4jgmACgyP388z/lJaYP1qBUqT3O14+Q JuwAoNF6duwiBrmMBwAPXD+fu6sCH36l =Kcl3 -----END PGP SIGNATURE----- --idY8LE8SD6/8DnRI-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 11:27: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 714681065674; Mon, 13 Aug 2012 11:27:08 +0000 (UTC) (envelope-from listlog2011@gmail.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 10DC28FC15; Mon, 13 Aug 2012 11:27:07 +0000 (UTC) Received: by yhfs35 with SMTP id s35so3611621yhf.13 for ; Mon, 13 Aug 2012 04:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JtR9gHBpCdITrneVrsU6M1Tmmzsn0TRTUeMJTiya8K4=; b=fbGMxV8J1TJB/8+rVbr+/1DOS/VyMlTH0eNopZ5133JBBd2ps/Xhmawe5L50KuH1+l atY6oaeC5BNWVdrU3zfIFrcMX/5uOe48I12ZVVg2OOzO8I0kw7mHYfd+um9ZFBZNDNsi 55ouKuRTq88rQShm0CxjzYBtXeTNb4k23xS2gkRZd93Qej5Vbs8fNxKRfQX5lH5Ambeu /ZT/8P6ITe3iU1XRL8FgI1mQKFHHElhFIvoO+knOyVft39YNi7PNcKnxw5BZGLyWFgYS 7l0dfEp85ZYZcm5pbtBytTdQW+LKlhWqBMyqFfeUnnMcxCuaI5upKGmDHByvzM9BGurf Q7KQ== Received: by 10.66.86.201 with SMTP id r9mr14631471paz.16.1344857227184; Mon, 13 Aug 2012 04:27:07 -0700 (PDT) Received: from xp5k.my.domain ([115.192.135.161]) by mx.google.com with ESMTPS id ro7sm5238899pbc.8.2012.08.13.04.27.03 (version=SSLv3 cipher=OTHER); Mon, 13 Aug 2012 04:27:06 -0700 (PDT) Message-ID: <5028E485.3040506@gmail.com> Date: Mon, 13 Aug 2012 19:27:01 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jilles Tjoelker References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <50246EE4.9090409@freebsd.org> <20120811131048.GA29572@stack.nl> In-Reply-To: <20120811131048.GA29572@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Aug 2012 11:53:29 +0000 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, David Xu 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: Mon, 13 Aug 2012 11:27:08 -0000 On 2012/08/11 21:10, Jilles Tjoelker wrote: > On Fri, Aug 10, 2012 at 10:16:04AM +0800, David Xu wrote: >> On 2012/08/09 18:56, Jilles Tjoelker wrote: >>> On Mon, Aug 06, 2012 at 11:25:35AM +0300, Konstantin Belousov wrote: >>>> On Sun, Aug 05, 2012 at 11:54:32PM +0200, Jilles Tjoelker wrote: >>>>> On Mon, Jul 30, 2012 at 01:53:03PM +0300, Konstantin Belousov wrote: >>>>>> On Mon, Jul 30, 2012 at 12:24:08PM +0200, Jilles Tjoelker wrote: >>>>>>> People sometimes use system() from large address spaces where it would >>>>>>> improve performance greatly to use vfork() instead of fork(). >>>>>>> A simple approach is to change fork() to vfork(), although I have not >>>>>>> tried this. It seems safe enough to use sigaction and sigprocmask system >>>>>>> calls in the vforked process. >>>>>>> Alternatively, we can have posix_spawn() do the vfork() with signal >>>>>>> changes. This avoids possible whining from compilers and static >>>>>>> analyzers about using vfork() in system.c. However, I do not like the >>>>>>> tricky code for signals and that it adds lines of code. >>>>>>> This is lightly tested. >>>>>> It is interesting to note that for some time our vfork(2) no longer >>>>>> stops the whole forked process (parent), only the forking thread is >>>>>> waiting for the child exit or exec. I am not sure is this point >>>>>> important for system(3), but determined code can notice the difference >>>>>> from the fork->vfork switch. >>>>> Neither fork nor vfork call thread_single(SINGLE_BOUNDARY), so this is >>>>> not a difference. >>>> It is the difference, because vforked child shares parent address space. >>>>> Thread singling may be noticeable from a failing execve() (but only in >>>>> the process doing execve()) and in the rare case of rfork() without >>>>> RFPROC. >>>> No, other running threads in parent affect vforked child till exec or exit. >>>> In fact, I would classify this as bug, but not a serious one. >>> There are some ugly ways this parallel execution is depended on. If the >>> vforked child calls sigaction() while another thread is also in >>> sigaction() for that signal, the vforked child needs to wait for the >>> other thread to release the lock. >>> This uses a per-process lock to synchronize threads in different >>> processes, which may not work properly. >>> If the vforked child is killed (such as by SIGKILL) while holding the >>> lock, the parent is not killed but its _thr_sigact is damaged. >>> These problems could be avoided in libthr by skipping the lock in >>> _sigaction() if a signal action is being set to SIG_DFL or SIG_IGN and >>> the old action is not queried. In those cases, _thr_sigact is not >>> touched so no lock is required. This change also helps applications, >>> provided they call sigaction() and not signal(). >>> Alternatively, posix_spawn() and system() could use the sigaction system >>> call directly, bypassing libthr (if present). However, this will not >>> help applications that call vfork() and sigaction() themselves (such as >>> a shell that wants to implement ...& using vfork()). >>> posix_spawn() likely still needs some adjustment so that having it reset >>> all signals (sigfillset()) to the default action will not cause it to >>> [EINVAL] because libthr does not allow changing SIGTHR's disposition. >>> Index: lib/libthr/thread/thr_sig.c >>> =================================================================== >>> --- lib/libthr/thread/thr_sig.c (revision 238970) >>> +++ lib/libthr/thread/thr_sig.c (working copy) >>> @@ -519,8 +519,16 @@ >>> return (-1); >>> } >>> >>> - if (act) >>> + if (act) { >>> newact = *act; >>> + /* >>> + * Short-circuit cases where we do not touch _thr_sigact. >>> + * This allows performing these safely in a vforked child. >>> + */ >>> + if ((newact.sa_handler == SIG_DFL || >>> + newact.sa_handler == SIG_IGN)&& oact == NULL) >>> + return (__sys_sigaction(sig,&newact, NULL)); >>> + } >>> >>> __sys_sigprocmask(SIG_SETMASK,&_thr_maskset,&oldset); >>> _thr_rwl_wrlock(&_thr_sigact[sig-1].lock); >>> >> Your patch is better than nothing, I don't object. >> The problem is visble to you, but there is also invisible user - rtld. >> If a symbol is never used in parent process, but now it is used >> in a vforked child, the rtld will be involved, if the child >> is killed, the rtld's data structure may be in inconsistent state, >> such as locking or link list etcs... >> I think this problem might be a non-fixable problem. > Hmm. Rtld cannot be fixed like libthr because its data structures are > inherently in userland. > > Perhaps signal handling should be different for a vforked child, like > the default action of a signal sent to a thread affects the entire > process and not just the thread. This cannot be implemented in the > calling code because resolving execve() itself also needs rtld (ugly > hacks like performing an execve() call that is guaranteed to fail > aside). > > The rtld problem can be avoided specifically by linking with '-z now'. > This might be acceptable for sh and csh; most applications can use > posix_spawn() which would have to become a system call. > Or the libc's posix_spawn() should use each system call directly, it should not call a function which is exported from libc globally, otherwise a PLT resolving will cause rtld locking to be acquired, if it dies, the parent is locked. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 14:14:41 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 96303106564A for ; Mon, 13 Aug 2012 14:14:41 +0000 (UTC) (envelope-from mdf356@gmail.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 4FCE58FC0A for ; Mon, 13 Aug 2012 14:14:41 +0000 (UTC) Received: by ghrr13 with SMTP id r13so3644310ghr.13 for ; Mon, 13 Aug 2012 07:14:40 -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=q+XCAk5ATgkt/z8LVoF2xJUmu4FdbtCUMfdYvg7pzLs=; b=CTNSFXtRnk6x797EOi5cGEaiS6ugmMlU4ED0ftChI9O7IzJARxqmNuYwfOTM4Cg2sD YZGnVwIeTQlHnmRNM4oOonXdm8PuxxEHtFEheW5ZY1YnEtJq8/apH7VjxZi+KOl1HlTP urhFKxdkq3vRp0gCMYU3rhkqjx5+JHhO81MGS4vRws0axky75V4DQ9o46U70b7qb4cwo n8y1IIHLGsniwKboBVoP3G9t8C2YV4m3afrzPyqL6l43IGvPugrJIHPZKp9Nvm2Re0Ph 4y28i5Nlp0cA/8hVixcc1KMSRa4lOsnO8HOKa2LiAlPK4dQfNOCP7gZd7Q02FYPeOPJ6 ywkw== MIME-Version: 1.0 Received: by 10.66.77.40 with SMTP id p8mr17833750paw.78.1344867280419; Mon, 13 Aug 2012 07:14:40 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.62.73 with HTTP; Mon, 13 Aug 2012 07:14:40 -0700 (PDT) In-Reply-To: <5028B9C4.60000@gmail.com> References: <5028B9C4.60000@gmail.com> Date: Mon, 13 Aug 2012 07:14:40 -0700 X-Google-Sender-Auth: BLucKDYhWZNu-UGglcatJhEoODQ Message-ID: From: mdf@FreeBSD.org To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: How to know __FreeBSD_version for a symbol 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, 13 Aug 2012 14:14:41 -0000 On Mon, Aug 13, 2012 at 1:24 AM, Hooman Fazaeli wrote: > Hi hackers > > In the process of back porting drivers to older freebsd versions, > We sometimes need to add suitable '#if __FreeBSD_version >= xxxxx ... else > ... ' > directives to the source to use an alternate function or exclude certain > statements, defines, etc. > > What is the best (quick/reliable) way to know in which __FreeBSD_version > a symbol (function, struct member, macro, ...) has been first introduced? As far as I know it's a slightly painful look over SVN logs. First, find the SVN revision that introduced or changed the relevant symbol. Then, look at the SVN history of sys/sys/param.h for changes to __FreeBSD_version symbol. The one that's from the same or later SVN revision as the symbol change is the value you'll need. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 17:47:14 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 8B33D106567D for ; Mon, 13 Aug 2012 17:47:14 +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 627398FC08 for ; Mon, 13 Aug 2012 17:47:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AA159B98F; Mon, 13 Aug 2012 13:47:13 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org, resit.sahin@inforcept.com Date: Mon, 13 Aug 2012 10:54:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <5023CB54.4090701@inforcept.com> In-Reply-To: <5023CB54.4090701@inforcept.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208131054.03792.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 Aug 2012 13:47:13 -0400 (EDT) Cc: Subject: Re: NUMA support in FreeBSD 9.0 / 9.1 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, 13 Aug 2012 17:47:14 -0000 On Thursday, August 09, 2012 10:38:12 am Resit Sahin wrote: > Hello, > > Does FreeBSD 9.0 or 9.1 "fully" support NUMA Architectures? It is said > that FreeBSD 9.0 has an initial NUMA support but is this initial support > enough for getting major performance gains? It can give gains if you are careful to pin your threads to packages. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 17: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 8978C1065686; Mon, 13 Aug 2012 17:47:15 +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 4C6458FC12; Mon, 13 Aug 2012 17:47:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B1F07B9A4; Mon, 13 Aug 2012 13:47:14 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 13 Aug 2012 10:55:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208131055.49794.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 Aug 2012 13:47:14 -0400 (EDT) Cc: David Duchscher , hackers@freebsd.org Subject: Re: Disabling ethernet link on an Intel nic? 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, 13 Aug 2012 17:47:15 -0000 On Saturday, August 11, 2012 9:35:14 am David Duchscher wrote: > Greetings, > > I have a need to turn off the link of an ethernet port on a Intel nic. The issue is not a big deal but one we would like to solve. we have no way of signaling an upstream router that a path is down but via turning off the link of the ethernet port. This would only be used when something goes wrong. The hope is that we could automate some problems and handle other situations remotely avoiding having to visit the system in person. > > Any thoughts? We can modify the system so if it means modifying the driver or some other code, I am willing to try. Just need a little direction. Hmm, does 'ifconfig foo down' not do this? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 17:47:15 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 8978C1065686; Mon, 13 Aug 2012 17:47:15 +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 4C6458FC12; Mon, 13 Aug 2012 17:47:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B1F07B9A4; Mon, 13 Aug 2012 13:47:14 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 13 Aug 2012 10:55:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208131055.49794.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 Aug 2012 13:47:14 -0400 (EDT) Cc: David Duchscher , hackers@freebsd.org Subject: Re: Disabling ethernet link on an Intel nic? 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, 13 Aug 2012 17:47:15 -0000 On Saturday, August 11, 2012 9:35:14 am David Duchscher wrote: > Greetings, > > I have a need to turn off the link of an ethernet port on a Intel nic. The issue is not a big deal but one we would like to solve. we have no way of signaling an upstream router that a path is down but via turning off the link of the ethernet port. This would only be used when something goes wrong. The hope is that we could automate some problems and handle other situations remotely avoiding having to visit the system in person. > > Any thoughts? We can modify the system so if it means modifying the driver or some other code, I am willing to try. Just need a little direction. Hmm, does 'ifconfig foo down' not do this? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 20:47:03 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 60F61106564A; Mon, 13 Aug 2012 20:47:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.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 06C418FC15; Mon, 13 Aug 2012 20:47:02 +0000 (UTC) Received: by ghrr13 with SMTP id r13so4217368ghr.13 for ; Mon, 13 Aug 2012 13:47:02 -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 :content-transfer-encoding; bh=tDidtfkjjIdH38UjNl+SQ2iFRg2J8XATW0PRtpJYTK4=; b=nCbvHv63a9ERrNOv1aFUzzS9qteBSu/jOO0FYkT1GrVKRrlRzRH+CMAibMKKkZY+7r uKTGzNMFAYNYBNWRsoh4rTjdlpfTtT+7dOZhNl0fjC0H3kzpWYarSS6B74ZJ0Y0vZiRU OoAz31hxs9j/ASgwEVSaDcw1LqOaFdfjy+M3FhepzZhynet+g9qa8BDEuEmXHBJDZjSO FMgveNMZAwMI9gjvg75zSRrnQEz0i4ms3dMzCg6YHUfgVUdqvSe42charoiQ/TAoEo8r Zp/a/151CBPBsnYO4OqyXs0EQrdPeR6WnWnTV7libG23kZG4nOhqPU875jkjbVOjPdGB X9sg== MIME-Version: 1.0 Received: by 10.68.222.103 with SMTP id ql7mr34529246pbc.48.1344890821778; Mon, 13 Aug 2012 13:47:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Mon, 13 Aug 2012 13:47:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Aug 2012 13:47:01 -0700 X-Google-Sender-Auth: cmDvJRYFgLTH9vY-43m-8hnLYnw Message-ID: From: Adrian Chadd To: David Duchscher Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Marius Strobl , hackers@freebsd.org Subject: Re: Disabling ethernet link on an Intel nic? 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, 13 Aug 2012 20:47:03 -0000 Hi, On 11 August 2012 06:35, David Duchscher wrote: > Greetings, > > I have a need to turn off the link of an ethernet port on a Intel nic. T= he issue is not a big deal but one we would like to solve. we have no way = of signaling an upstream router that a path is down but via turning off the= link of the ethernet port. This would only be used when something goes wr= ong. The hope is that we could automate some problems and handle other situ= ations remotely avoiding having to visit the system in person. > > Any thoughts? We can modify the system so if it means modifying the driv= er or some other code, I am willing to try. Just need a little direction. Marius talked about doing this. Maybe it's time we added it as a device option, so people can have the PHY disabled when the NIC is brought down? Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 13 22:33: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 F0CAF1065674; Mon, 13 Aug 2012 22:33:34 +0000 (UTC) (envelope-from dplassche@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 5A42D8FC0C; Mon, 13 Aug 2012 22:33:34 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so3105940wib.13 for ; Mon, 13 Aug 2012 15:33:31 -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=z5hJdtPG1JWaB2BqxqxTms6TACtMAPZKh+Bg3hLVDuI=; b=AEfED/5EP09ib2XVCZAvsOa/AF/L093hThItRUDK8zf5FsMRdfJpJEnmsGZvulLYVp m85S2CBZVWDWPbJPEGWwHe4z7yjIKGQguwlwEhjwOXHPw08K1yZ9CgQ2NwF9IV2QreiO erJeYRUbRhWFj2gXHZ4M8uk9JL2vAysbBlMxh34kYOoajxg9RvARGS5qsJYo6I04JoAh zM2Bn7u5JLRwUvbac1r7L/IKjiJXret4STf5IW6/+WAxK2XOC0083zAn1BvUNvBPbz6E 56MZrSH8WEDcLl91Vn7kYffivIm+Y3+AZhNmDZLb4lzwebkWhuHoYwPD0Kq7a/Hn80B7 kuHQ== MIME-Version: 1.0 Received: by 10.216.220.89 with SMTP id n67mr7824666wep.73.1344897211568; Mon, 13 Aug 2012 15:33:31 -0700 (PDT) Received: by 10.223.158.7 with HTTP; Mon, 13 Aug 2012 15:33:31 -0700 (PDT) In-Reply-To: <20120811184522.GK2425@deviant.kiev.zoral.com.ua> References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> Date: Mon, 13 Aug 2012 18:33:31 -0400 Message-ID: From: Dan Plassche To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 13 Aug 2012 22:43:36 +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, 13 Aug 2012 22:33:35 -0000 Konstantin, My apologies for any confusion. Your patch solved the problem on 8.2. Static and dynamic a.out binaries from 1.1.5.1 are working normally in a chroot environment now. On Sat, Aug 11, 2012 at 2:45 PM, Konstantin Belousov wrote: > Why did you stripped the public list from the Cc: ? I must have clicked on reply instead of reply all by accident. I sent a copy to the list about 10 minutes after replying to you, when I realized the mistake. > You should have mentioned that it is only _some_ binaries which are > affected, since I was not able to reproduce your issue at all with > /bin/sh or /bin/ls in chroot. It took me a while to realize that you > specifically shown the trace for basename. Sorry, I was focusing on the loader problem and left out the root binaries because they were traditionally static. Thanks for your help, Dan From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 00:41: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 3FFDF1065672; Tue, 14 Aug 2012 00:41:00 +0000 (UTC) (envelope-from listlog2011@gmail.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 CD7698FC16; Tue, 14 Aug 2012 00:40:59 +0000 (UTC) Received: by yhfs35 with SMTP id s35so4697606yhf.13 for ; Mon, 13 Aug 2012 17:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Tfg4x9S1VhZZG/BaTbYZ8mh8Gnr67m/yUu/l7GepsZo=; b=y1XlGEFWtWaJVldM7bQCqZEZCgEEivIwcKBi19Q0yBI8LbGUYoJw2EfZau+Vp2KsWk O7bwUtJfJ0sMLdkmve/faPZh0cCN7I+hB8z3dSlC/48dbMYnJay1pO9l249gl9ok9qjw 5axZ6DR75ATu/tYpbJ0s3wAuo2R94CzMbkoIISR8FflnEwFKBWYHGjaHUhCdrXnCoILF fi+jvxMJ7jXwlH8yjPGGNX3fgOHDAhp2Wo84Akc5qfrafYphpqYVMuwFp7PnBXBdaoAA i4TRMTtAk0DkLvZwOZTeBGnTrezJONTCubiV5hR1Z0FRzMUMMOPNn/1cSX/fQ5zFa/Gw j7kA== Received: by 10.68.223.164 with SMTP id qv4mr35260310pbc.20.1344904858743; Mon, 13 Aug 2012 17:40:58 -0700 (PDT) Received: from xp5k.my.domain ([115.192.131.203]) by mx.google.com with ESMTPS id vh7sm308913pbc.22.2012.08.13.17.40.55 (version=SSLv3 cipher=OTHER); Mon, 13 Aug 2012 17:40:58 -0700 (PDT) Message-ID: <50299E95.80401@gmail.com> Date: Tue, 14 Aug 2012 08:40:53 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <20120809110850.GA2425@deviant.kiev.zoral.com.ua> <20120810101302.GF2425@deviant.kiev.zoral.com.ua> <5026F4B1.5030000@gmail.com> <20120813115021.GE2352@deviant.kiev.zoral.com.ua> In-Reply-To: <20120813115021.GE2352@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, Jilles Tjoelker Subject: Re: system() using vfork() or posix_spawn() and libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 00:41:00 -0000 On 2012/08/13 19:50, Konstantin Belousov wrote: > On Sun, Aug 12, 2012 at 08:11:29AM +0800, David Xu wrote: >> On 2012/08/10 18:13, Konstantin Belousov wrote: >>> On Thu, Aug 09, 2012 at 02:08:50PM +0300, Konstantin Belousov wrote: >>>> Third alternative, which seems to be even better, is to restore >>>> single-threading of the parent for vfork(). >> single-threading is slow for large threaded process, don't know if it >> is necessary for vfork(), POSIX says nothing about threaded process. > I agree that with both of your statements. But, being fast but allowing > silent process corruption is not good behaviour. Either we need to > actually support vfork() for threaded processes, or disable it with some > error code. > > I prefer to support it. I believe that vfork() should be wrapped by > libthr in the same way as fork() is wrapped. Not sure should we call > atfork handlers, for now I decided not to call, since the handlers > assume separate address spaces for parent/child. But we could only call > parent handler in child, however weird this sounds. > > The real complication with wrapping is the fact that we cannot return > from wrapper in child without destroying parent state. So I tried to > prototype the code to handle the wrapping in the same frame, thus > neccessity of using asm. > > Below is WIP, only for amd64 ATM. > > diff --git a/lib/libthr/arch/amd64/Makefile.inc b/lib/libthr/arch/amd64/Makefile.inc > index e6d99ec..476d26a 100644 > --- a/lib/libthr/arch/amd64/Makefile.inc > +++ b/lib/libthr/arch/amd64/Makefile.inc > @@ -1,3 +1,4 @@ > #$FreeBSD$ > > -SRCS+= pthread_md.c _umtx_op_err.S > +CFLAGS+=-I${.CURDIR}/../libc/${MACHINE_CPUARCH} > +SRCS+= pthread_md.c _umtx_op_err.S vfork.S > diff --git a/lib/libthr/arch/amd64/amd64/vfork.S b/lib/libthr/arch/amd64/amd64/vfork.S > new file mode 100644 > index 0000000..07d813d > --- /dev/null > +++ b/lib/libthr/arch/amd64/amd64/vfork.S > @@ -0,0 +1,74 @@ > +/*- > + * 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 PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS 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. > + */ > + > +#if defined(SYSLIBC_SCCS) && !defined(lint) > + .asciz "@(#)Ovfork.s 5.1 (Berkeley) 4/23/90" > +#endif /* SYSLIBC_SCCS and not lint */ > +#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 _thr_vfork_post > + popq %rsi > + popq %rsi > + xorl %eax,%eax > +1: > + jmp *%rsi > +2: > + pushq %rsi > + pushq %rax > + call _thr_vfork_post > + call PIC_PLT(CNAME(__error)) > + popq %rdx > + movq %rdx,(%rax) > + movq $-1,%rax > + movq $-1,%rdx > + retq > +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+= \ > 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_private.h > index ba272fe..30f3de2 100644 > --- a/lib/libthr/thread/thr_private.h > +++ b/lib/libthr/thread/thr_private.h > @@ -777,6 +777,8 @@ 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(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 +835,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 > > static inline int > diff --git a/lib/libthr/thread/thr_vfork.c b/lib/libthr/thread/thr_vfork.c > new file mode 100644 > index 0000000..bed7db5 > --- /dev/null > +++ b/lib/libthr/thread/thr_vfork.c > @@ -0,0 +1,112 @@ > +/* > + * 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 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. > + * > + * $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 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. > + */ > + > +#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 = _get_curthread(); > + _thr_rwl_rdlock(&_thr_atfork_lock); > + cancelsave = curthread->no_cancel; > + curthread->no_cancel = 1; > + _thr_signal_block(curthread); > + _thr_signal_prefork(); > + if (_thr_isthreaded() != 0) { > + was_threaded = 1; > + _malloc_prefork(); > + _rtld_atfork_pre(rtld_locks); > + } else > + was_threaded = 0; > +} > + > +void > +_thr_vfork_post(void) > +{ > + struct pthread *curthread; > + > + _thr_signal_postfork(); > + if (was_threaded) { > + _rtld_atfork_post(rtld_locks); > + _malloc_postfork(); > + } > + curthread = _get_curthread(); > + _thr_signal_unblock(curthread); > + curthread->no_cancel = cancelsave; > + _thr_rwlock_unlock(&_thr_atfork_lock); > + if (curthread->cancel_async) > + _thr_testcancel(curthread); > +} > diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c > index 6cb95cd..8735c25 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; > > -#ifdef XEN > - flags = RFFDG | RFPROC; /* validate that this is still an issue */ > -#else > flags = RFFDG | RFPROC | RFPPWAIT | RFMEM; > -#endif > error = fork1(td, flags, 0, &p2, NULL, 0); > if (error == 0) { > td->td_retval[0] = p2->p_pid; > @@ -756,7 +752,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > struct thread *td2; > struct vmspace *vm2; > vm_ooffset_t mem_charged; > - int error; > + int error, single_threaded; > static int curfail; > static struct timeval lastfail; > #ifdef PROCDESC > @@ -815,6 +811,19 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > } > #endif > > + if (((p1->p_flag & (P_HADTHREADS | P_SYSTEM)) == P_HADTHREADS) && > + (flags & RFPPWAIT) != 0) { > + PROC_LOCK(p1); > + if (thread_single(SINGLE_BOUNDARY)) { > + PROC_UNLOCK(p1); > + error = ERESTART; > + goto fail2; > + } > + PROC_UNLOCK(p1); > + single_threaded = 1; > + } else > + single_threaded = 0; > + > mem_charged = 0; > vm2 = NULL; > if (pages == 0) > @@ -945,6 +954,12 @@ fail1: > if (vm2 != NULL) > vmspace_free(vm2); > uma_zfree(proc_zone, newproc); > + if (single_threaded) { > + PROC_LOCK(p1); > + thread_single_end(); > + PROC_UNLOCK(p1); > + } > +fail2: > #ifdef PROCDESC > if (((flags & RFPROCDESC) != 0) && (fp_procdesc != NULL)) { > fdclose(td->td_proc->p_fd, fp_procdesc, *procdescp, td); Single threading might be too excessive, the whole point of vfork is it is faster, if it is slow, I will use fork() instead. And another question is do you think child won't want to talk with another thread in parent process ? It is unlikely you can use locking in vfork wrapper, this becauses a vfork child can call vfork again, if child process dies after it acquired thread libraries' locks, it will cause lock leaks. Also, if a child process needs to enter RTLD to resolve a PLT, the rtld_bind rwlock will be acquired, if the child process dies after it acquired read lock, it also causes lock leak. I think Jilles patch is good enough to make posix_spawn and system() work, it seems Solaris also only allows SIG_IGN or SIG_DFL to be use in vfork child, same as Jilles' patch. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 01:31:41 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 2D13D106564A for ; Tue, 14 Aug 2012 01:31:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id CE90B8FC0A for ; Tue, 14 Aug 2012 01:31:40 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q7E1SpHo061469 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 18:28:52 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5029A9CE.8070307@freebsd.org> Date: Mon, 13 Aug 2012 18:28:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Dan Plassche References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , 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: Tue, 14 Aug 2012 01:31:41 -0000 On 8/13/12 3:33 PM, Dan Plassche wrote: > Konstantin, > > My apologies for any confusion. Your patch solved the problem on > 8.2. Static and dynamic a.out binaries from 1.1.5.1 are working > normally in a chroot environment now. you will also have to change PID_MAX (spelling?) to be 60000 I have considered making this a tunable.. If you don't then the shell in the 1.1.5.1 environment will not be able to handle when a child get s a pid of > 16 bits and it will not be able to wait on it. so it will suspend for ever. teh result is that you can not complete a "make world". last time I tried a "make world" completed in about 1 minute and a kernel (1.1.5.1 GENERIC) compiled in way less than a minute. that was in 7.x days. I'd like to see results under 9.2 on a modern machine. Julian > > On Sat, Aug 11, 2012 at 2:45 PM, Konstantin Belousov > wrote: > >> Why did you stripped the public list from the Cc: ? > I must have clicked on reply instead of reply all by accident. I > sent a copy to the list about 10 minutes after replying to you, > when I realized the mistake. > >> You should have mentioned that it is only _some_ binaries which are >> affected, since I was not able to reproduce your issue at all with >> /bin/sh or /bin/ls in chroot. It took me a while to realize that you >> specifically shown the trace for basename. > Sorry, I was focusing on the loader problem and left out the root > binaries because they were traditionally static. > > > Thanks for your help, > > Dan > _______________________________________________ > 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 14 04:42:14 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 E36781065677 for ; Tue, 14 Aug 2012 04:42:13 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB3CE8FC1B; Tue, 14 Aug 2012 04:42:13 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7E4gBov057251; Tue, 14 Aug 2012 04:42:12 GMT (envelope-from davidxu@freebsd.org) Message-ID: <5029D727.2090105@freebsd.org> Date: Tue, 14 Aug 2012 12:42:15 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Jilles Tjoelker References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> In-Reply-To: <20120809105648.GA79814@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@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: Tue, 14 Aug 2012 04:42:14 -0000 On 2012/08/09 18:56, Jilles Tjoelker wrote: > On Mon, Aug 06, 2012 at 11:25:35AM +0300, Konstantin Belousov wrote: >> On Sun, Aug 05, 2012 at 11:54:32PM +0200, Jilles Tjoelker wrote: >>> On Mon, Jul 30, 2012 at 01:53:03PM +0300, Konstantin Belousov wrote: >>>> On Mon, Jul 30, 2012 at 12:24:08PM +0200, Jilles Tjoelker wrote: >>>>> People sometimes use system() from large address spaces where it would >>>>> improve performance greatly to use vfork() instead of fork(). > >>>>> A simple approach is to change fork() to vfork(), although I have not >>>>> tried this. It seems safe enough to use sigaction and sigprocmask system >>>>> calls in the vforked process. > >>>>> Alternatively, we can have posix_spawn() do the vfork() with signal >>>>> changes. This avoids possible whining from compilers and static >>>>> analyzers about using vfork() in system.c. However, I do not like the >>>>> tricky code for signals and that it adds lines of code. > >>>>> This is lightly tested. > >>>> It is interesting to note that for some time our vfork(2) no longer >>>> stops the whole forked process (parent), only the forking thread is >>>> waiting for the child exit or exec. I am not sure is this point >>>> important for system(3), but determined code can notice the difference >>>> from the fork->vfork switch. > >>> Neither fork nor vfork call thread_single(SINGLE_BOUNDARY), so this is >>> not a difference. >> It is the difference, because vforked child shares parent address space. > >>> Thread singling may be noticeable from a failing execve() (but only in >>> the process doing execve()) and in the rare case of rfork() without >>> RFPROC. > >> No, other running threads in parent affect vforked child till exec or exit. >> In fact, I would classify this as bug, but not a serious one. > > There are some ugly ways this parallel execution is depended on. If the > vforked child calls sigaction() while another thread is also in > sigaction() for that signal, the vforked child needs to wait for the > other thread to release the lock. > > This uses a per-process lock to synchronize threads in different > processes, which may not work properly. > > If the vforked child is killed (such as by SIGKILL) while holding the > lock, the parent is not killed but its _thr_sigact is damaged. > > These problems could be avoided in libthr by skipping the lock in > _sigaction() if a signal action is being set to SIG_DFL or SIG_IGN and > the old action is not queried. In those cases, _thr_sigact is not > touched so no lock is required. This change also helps applications, > provided they call sigaction() and not signal(). > > Alternatively, posix_spawn() and system() could use the sigaction system > call directly, bypassing libthr (if present). However, this will not > help applications that call vfork() and sigaction() themselves (such as > a shell that wants to implement ...& using vfork()). > > posix_spawn() likely still needs some adjustment so that having it reset > all signals (sigfillset()) to the default action will not cause it to > [EINVAL] because libthr does not allow changing SIGTHR's disposition. > > Index: lib/libthr/thread/thr_sig.c > =================================================================== > --- lib/libthr/thread/thr_sig.c (revision 238970) > +++ lib/libthr/thread/thr_sig.c (working copy) > @@ -519,8 +519,16 @@ > return (-1); > } > > - if (act) > + if (act) { > newact = *act; > + /* > + * Short-circuit cases where we do not touch _thr_sigact. > + * This allows performing these safely in a vforked child. > + */ > + if ((newact.sa_handler == SIG_DFL || > + newact.sa_handler == SIG_IGN)&& oact == NULL) > + return (__sys_sigaction(sig,&newact, NULL)); > + } > > __sys_sigprocmask(SIG_SETMASK,&_thr_maskset,&oldset); > _thr_rwl_wrlock(&_thr_sigact[sig-1].lock); > I simply duplicated idea from OpenSolaris, here is my patch which has similar feature as your patch, and it also tries to prevent vforked child from corrupting parent's data: http://people.freebsd.org/~davidxu/patch/libthr-vfork.diff From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 08:18:45 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 4BFC0106564A; Tue, 14 Aug 2012 08:18:45 +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 B8B3C8FC08; Tue, 14 Aug 2012 08:18:44 +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 q7E8IgJ7000532; Tue, 14 Aug 2012 11:18: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 q7E8IU26014215; Tue, 14 Aug 2012 11:18: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 q7E8IUun014214; Tue, 14 Aug 2012 11:18: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, 14 Aug 2012 11:18:30 +0300 From: Konstantin Belousov To: David Xu Message-ID: <20120814081830.GA5883@deviant.kiev.zoral.com.ua> References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <5029D727.2090105@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, Jilles Tjoelker 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: Tue, 14 Aug 2012 08:18:45 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 14, 2012 at 12:42:15PM +0800, David Xu wrote: > I simply duplicated idea from OpenSolaris, here is my patch > which has similar feature as your patch, and it also tries to > prevent vforked child from corrupting parent's data: > http://people.freebsd.org/~davidxu/patch/libthr-vfork.diff You shall not return from vfork() frame in the child. Otherwise, the same frame is appears to be destroyed in parent, and parent dies. More often on !x86, but right combination of events on x86 is deadly too. If pid or curthread local variables are spilled into stack save area, then child will override them, and e.g. parent could see pid == 0, returning it to caller. This was the reason why I went to asm wrapper for vfork. Also, it seems that in mt process, malloc and rtld are still broken, or am I missing something ? --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAqCdUACgkQC3+MBN1Mb4hL3gCdFjUzOQrAjCo5i3Fk8SWi6ikS NE0AoJRfTnfkfAf2Rl8IJM2kGXtw6WVB =0wd3 -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 09:17: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 071051065672 for ; Tue, 14 Aug 2012 09:17:18 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C78938FC16; Tue, 14 Aug 2012 09:17:17 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7E9GrcI003464; Tue, 14 Aug 2012 09:17:06 GMT (envelope-from davidxu@freebsd.org) Message-ID: <502A1788.9090702@freebsd.org> Date: Tue, 14 Aug 2012 17:16:56 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Konstantin Belousov References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> In-Reply-To: <20120814081830.GA5883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker 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: Tue, 14 Aug 2012 09:17:18 -0000 On 2012/08/14 16:18, Konstantin Belousov wrote: > On Tue, Aug 14, 2012 at 12:42:15PM +0800, David Xu wrote: >> I simply duplicated idea from OpenSolaris, here is my patch >> which has similar feature as your patch, and it also tries to >> prevent vforked child from corrupting parent's data: >> http://people.freebsd.org/~davidxu/patch/libthr-vfork.diff > You shall not return from vfork() frame in the child. Otherwise, the > same frame is appears to be destroyed in parent, and parent dies. More > often on !x86, but right combination of events on x86 is deadly too. > If pid or curthread local variables are spilled into stack save area, > then child will override them, and e.g. parent could see pid == 0, > returning it to caller. > > This was the reason why I went to asm wrapper for vfork. > OK. > Also, it seems that in mt process, malloc and rtld are still broken, > or am I missing something ? I will not call it as broken, malloc and rtld are working properly. vfork is not a normal function, for MT process, fork() is even very special too. POSIX says a lot about multi-threaded: http://pubs.opengroup.org/onlinepubs/000095399/functions/fork.html I quoted some POSIX document here: > A process shall be created with a single thread. If a multi-threaded > process calls fork(), the new process shall contain a replica of the > calling thread and its entire address space, possibly including the > states of mutexes and other resources. Consequently, to avoid errors, > the child process may only execute async-signal-safe operations until > such time as one of the exec functions is called. [THR] Fork > handlers may be established by means of the pthread_atfork() function > in order to maintain application invariants across fork() calls. This means child process should only do very simple things, and quickly call execv(). For mt process, fork() is already a very complicated problem, one of problems I still remembered is that when fork() is called in signal handler, should the thread library execute pthread_atfork handler ? if it should do, but none of lock is async-signal safe, though our internal rwlock allows to be used in signal handler, but it is not supported by POSIX. Also are those atfork handler prepared to be executed in signal handler ? it is undefined. POSIX had opened a door here. Above is one of complicated problem, the vfork is even more restrictive than fork(). If it is possible, I would avoid such a complicated problem which vfork() would cause. Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 09:41: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 AB8541065673; Tue, 14 Aug 2012 09:41:32 +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 41DBC8FC0A; Tue, 14 Aug 2012 09:41:31 +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 q7E9fNQv007344; Tue, 14 Aug 2012 12:41:24 +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 q7E9fBTb014612; Tue, 14 Aug 2012 12:41:11 +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 q7E9fB7R014611; Tue, 14 Aug 2012 12:41:11 +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, 14 Aug 2012 12:41:11 +0300 From: Konstantin Belousov To: David Xu Message-ID: <20120814094111.GB5883@deviant.kiev.zoral.com.ua> References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <502A1788.9090702@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, Jilles Tjoelker 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: Tue, 14 Aug 2012 09:41:32 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 14, 2012 at 05:16:56PM +0800, David Xu wrote: > On 2012/08/14 16:18, Konstantin Belousov wrote: > >On Tue, Aug 14, 2012 at 12:42:15PM +0800, David Xu wrote: > >>I simply duplicated idea from OpenSolaris, here is my patch > >>which has similar feature as your patch, and it also tries to > >>prevent vforked child from corrupting parent's data: > >>http://people.freebsd.org/~davidxu/patch/libthr-vfork.diff > >You shall not return from vfork() frame in the child. Otherwise, the > >same frame is appears to be destroyed in parent, and parent dies. More > >often on !x86, but right combination of events on x86 is deadly too. > >If pid or curthread local variables are spilled into stack save area, > >then child will override them, and e.g. parent could see pid =3D=3D 0, > >returning it to caller. > > > >This was the reason why I went to asm wrapper for vfork. > > > OK. >=20 > >Also, it seems that in mt process, malloc and rtld are still broken, > >or am I missing something ? >=20 > I will not call it as broken, malloc and rtld are working properly. > vfork is not a normal function, for MT process, fork() is even > very special too. >=20 > POSIX says a lot about multi-threaded: > http://pubs.opengroup.org/onlinepubs/000095399/functions/fork.html >=20 > I quoted some POSIX document here: > > A process shall be created with a single thread. If a multi-threaded > > process calls fork(), the new process shall contain a replica of the > > calling thread and its entire address space, possibly including the > > states of mutexes and other resources. Consequently, to avoid errors, > > the child process may only execute async-signal-safe operations until > > such time as one of the exec functions is called. [THR] Fork > > handlers may be established by means of the pthread_atfork() function > > in order to maintain application invariants across fork() calls. >=20 > This means child process should only do very simple things, and > quickly call execv(). Sure. But to call execv*, the child may need a working rtld, so we fixed it. User code routinely called malloc() or even created threads in the child, so we fixed that too. Otherwise, we have nothing to answer for the demands, and 'other' OSes do support such usage. It is beyond POSIX, but this does not matter, since the feature is expected to be available by application writers. >=20 > For mt process, fork() is already a very complicated problem, > one of problems I still remembered is that when fork() is called in > signal handler, should the thread library execute pthread_atfork > handler ? if it should do, but none of lock is async-signal safe, > though our internal rwlock allows to be used in signal handler, > but it is not supported by POSIX. > Also are those atfork handler prepared to be executed in signal > handler ? it is undefined. POSIX had opened a door here. POSIX authors were aware of this problem. In the rationale for SUSv4, they wrote "While the fork() function is async-signal-safe, there is no way for an implementation to determine whether the fork handlers established by pthread_atfork() are async-signal-safe. The fork handlers may attempt to execute portions of the implementation that are not async-signal-safe, such as those that are protected by mutexes, leading to a deadlock condition. It is therefore undefined for the fork handlers to execute functions that are not async-signal-safe when fork() is called from a signal handler." IMO, since fork() is specified to be async-signal safe, and since fork() is specified to call atfork() handlers, SUSv4 requires, without any misinterpreations, that atfork calling machinery must be async-signal safe. The only possibility for undefined behaviour is the application code registering non-async safe handlers. > Above is one of complicated problem, the vfork is even more > restrictive than fork(). > If it is possible, I would avoid such a complicated problem > which vfork() would cause. I fully agree that the issues caused by vfork() in multithreaded code are complicated, but ignoring them lowers the quality of our implementation. Fixing vfork in multithreaded process is not trivial, but it is possible. My patch aims at working rtld and malloc in child. As I said earlier, we might even try to call parent atfork handlers in chil= d. Sure, if child dies at wrong time, then rtld and malloc locks and data structures can be left in unusable state for parent, but currently we do not work even if child is relatively well-behaving. --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAqHTcACgkQC3+MBN1Mb4ix/ACgqnHxIwPf7ZTFqsBD6jPYZlHi ktoAoPA4CHeoPEG2LmoAvQ0f9A4Mya2A =gy3l -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 06:16:54 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 068AF106566C for ; Tue, 14 Aug 2012 06:16:54 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 60BD48FC0A for ; Tue, 14 Aug 2012 06:16:53 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q7E6Gnh8010270; Tue, 14 Aug 2012 13:16:50 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5029ED51.9000600@rdtc.ru> Date: Tue, 14 Aug 2012 13:16:49 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: David Duchscher References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 14 Aug 2012 11:18:40 +0000 Cc: hackers@freebsd.org Subject: Re: Disabling ethernet link on an Intel nic? 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, 14 Aug 2012 06:16:54 -0000 11.08.2012 20:35, David Duchscher ÐÉÛÅÔ: > Greetings, > > I have a need to turn off the link of an ethernet port on a Intel nic. The issue is not a big deal but one we would like to solve. we have no way of signaling an upstream router that a path is down but via turning off the link of the ethernet port. This would only be used when something goes wrong. The hope is that we could automate some problems and handle other situations remotely avoiding having to visit the system in person. > > Any thoughts? We can modify the system so if it means modifying the driver or some other code, I am willing to try. Just need a little direction. > > Thanks for your time, I made such patch a couple of years ago and run it in production with copper-based em(4) and igb(4) NICs. The patch introduces new sysctls like dev.em.X.down_disables_link and dev.igb.X.down.disables_link with default zero values. Setting sysctl dev.em.0.down_disables_link=1 makes "ifconfig em0 down" bring link down. http://www.grosbein.net/freebsd/patches/em_sysctl-8.3.diff.gz http://www.grosbein.net/freebsd/patches/igb_sysctl-8.3.diff.gz From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 13:07:17 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 A2A47106564A; Tue, 14 Aug 2012 13:07:17 +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 051CA8FC1C; Tue, 14 Aug 2012 13:07:16 +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 q7ED7DlX036777; Tue, 14 Aug 2012 16:07:13 +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 q7ED71fU016435; Tue, 14 Aug 2012 16:07:01 +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 q7ED7132016434; Tue, 14 Aug 2012 16:07:01 +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, 14 Aug 2012 16:07:00 +0300 From: Konstantin Belousov To: Julian Elischer Message-ID: <20120814130700.GD5883@deviant.kiev.zoral.com.ua> References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> <5029A9CE.8070307@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/unnNtmY43mpUSKx" Content-Disposition: inline In-Reply-To: <5029A9CE.8070307@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, Dan Plassche 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: Tue, 14 Aug 2012 13:07:17 -0000 --/unnNtmY43mpUSKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote: > On 8/13/12 3:33 PM, Dan Plassche wrote: > >Konstantin, > > > >My apologies for any confusion. Your patch solved the problem on > >8.2. Static and dynamic a.out binaries from 1.1.5.1 are working > >normally in a chroot environment now. >=20 > you will also have to change PID_MAX (spelling?) to be 60000 > I have considered making this a tunable.. > If you don't then the shell in the 1.1.5.1 environment will not be=20 > able to handle when a child > get s a pid of > 16 bits and it will not be able to wait on it. so it=20 > will suspend for ever. > teh result is that you can not complete a "make world". >=20 > last time I tried a "make world" completed in about 1 minute and a kernel > (1.1.5.1 GENERIC) compiled in way less than a minute. that was in 7.x=20 > days. >=20 > I'd like to see results under 9.2 on a modern machine. I committed today a batch of changes that allowed me to run most of the binaries from 1.1.5.1 CD on real amd64 machine. Below is the pid_max tunable patch. I first thought that it cannot be made a writeable sysctl, but then realized that there is nothing wrong with having existing process pid be greater then pid_max, as far as it is less then PID_MAX. diff --git a/sys/compat/linprocfs/linprocfs.c b/sys/compat/linprocfs/linpro= cfs.c index 3adbe96..03db81a 100644 --- a/sys/compat/linprocfs/linprocfs.c +++ b/sys/compat/linprocfs/linprocfs.c @@ -1230,7 +1230,7 @@ static int linprocfs_dopid_max(PFS_FILL_ARGS) { =20 - sbuf_printf(sb, "%i\n", PID_MAX); + sbuf_printf(sb, "%i\n", pid_max); return (0); } =20 diff --git a/sys/compat/svr4/svr4_misc.c b/sys/compat/svr4/svr4_misc.c index 8456e10..dd4a24f 100644 --- a/sys/compat/svr4/svr4_misc.c +++ b/sys/compat/svr4/svr4_misc.c @@ -824,7 +824,7 @@ svr4_sys_sysconfig(td, uap) *retval =3D 1; /* XXX */ break; case SVR4_CONFIG_MAXPID: - *retval =3D PID_MAX; + *retval =3D pid_max; break; case SVR4_CONFIG_STACK_PROT: *retval =3D PROT_READ|PROT_WRITE|PROT_EXEC; diff --git a/sys/fs/pseudofs/pseudofs_vnops.c b/sys/fs/pseudofs/pseudofs_vn= ops.c index 9f97cd3..9600e9a 100644 --- a/sys/fs/pseudofs/pseudofs_vnops.c +++ b/sys/fs/pseudofs/pseudofs_vnops.c @@ -531,7 +531,7 @@ pfs_lookup(struct vop_cachedlookup_args *va) if ((pn =3D pdn) !=3D NULL) { pid =3D 0; for (pid =3D 0, i =3D 0; i < namelen && isdigit(pname[i]); ++i) - if ((pid =3D pid * 10 + pname[i] - '0') > PID_MAX) + if ((pid =3D pid * 10 + pname[i] - '0') > pid_max) break; if (i =3D=3D cnp->cn_namelen) { pfs_unlock(pd); diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c index ba905e0..3174a34 100644 --- a/sys/kern/init_main.c +++ b/sys/kern/init_main.c @@ -476,6 +476,7 @@ proc0_init(void *dummy __unused) knlist_init_mtx(&p->p_klist, &p->p_mtx); STAILQ_INIT(&p->p_ktr); p->p_nice =3D NZERO; + /* pid_max cannot be greater then PID_MAX */ td->td_tid =3D PID_MAX + 1; LIST_INSERT_HEAD(TIDHASH(td->td_tid), td, td_hash); td->td_state =3D TDS_RUNNING; diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 6cb95cd..69abb23 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -209,8 +209,8 @@ sysctl_kern_randompid(SYSCTL_HANDLER_ARGS) pid =3D randompid; error =3D sysctl_handle_int(oidp, &pid, 0, req); if (error =3D=3D 0 && req->newptr !=3D NULL) { - if (pid < 0 || pid > PID_MAX - 100) /* out of range */ - pid =3D PID_MAX - 100; + if (pid < 0 || pid > pid_max - 100) /* out of range */ + pid =3D pid_max - 100; else if (pid < 2) /* NOP */ pid =3D 0; else if (pid < 100) /* Make it reasonable */ @@ -259,8 +259,8 @@ retry: * restart somewhat above 0, as the low-numbered procs * tend to include daemons that don't exit. */ - if (trypid >=3D PID_MAX) { - trypid =3D trypid % PID_MAX; + if (trypid >=3D pid_max) { + trypid =3D trypid % pid_max; if (trypid < 100) trypid +=3D 100; pidchecked =3D 0; @@ -268,7 +268,7 @@ retry: if (trypid >=3D pidchecked) { int doingzomb =3D 0; =20 - pidchecked =3D PID_MAX; + pidchecked =3D pid_max; /* * Scan the active and zombie procs to check whether this pid * is in use. Remember the lowest pid that's greater diff --git a/sys/kern/kern_mib.c b/sys/kern/kern_mib.c index 75b3af9..dfc8695 100644 --- a/sys/kern/kern_mib.c +++ b/sys/kern/kern_mib.c @@ -499,6 +499,30 @@ SYSCTL_INT(_debug_sizeof, OID_AUTO, vnode, CTLFLAG_RD, SYSCTL_INT(_debug_sizeof, OID_AUTO, proc, CTLFLAG_RD, 0, sizeof(struct proc), "sizeof(struct proc)"); =20 +static int +sysctl_kern_pid_max(SYSCTL_HANDLER_ARGS) +{ + int error, pm; + + pm =3D pid_max; + error =3D sysctl_handle_int(oidp, &pm, 0, req); + if (error || !req->newptr) + return (error); + /* Permit update only if the new securelevel exceeds the old. */ + sx_xlock(&proctree_lock); + sx_xlock(&allproc_lock); + if (pm > PID_MAX) + error =3D EINVAL; + else + pid_max =3D pm; + sx_xunlock(&allproc_lock); + sx_xunlock(&proctree_lock); + return (error); +} +SYSCTL_PROC(_kern, OID_AUTO, pid_max, CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_T= UN | + CTLFLAG_MPSAFE, 0, 0, sysctl_kern_pid_max, "I", + "Maximum allowed pid"); + #include #include SYSCTL_INT(_debug_sizeof, OID_AUTO, bio, CTLFLAG_RD, diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c index 69a416e..d21763c 100644 --- a/sys/kern/kern_thread.c +++ b/sys/kern/kern_thread.c @@ -269,7 +269,11 @@ threadinit(void) { =20 mtx_init(&tid_lock, "TID lock", NULL, MTX_DEF); - /* leave one number for thread0 */ + + /* + * pid_max cannot be greater then PID_MAX. + * leave one number for thread0. + */ tid_unrhdr =3D new_unrhdr(PID_MAX + 2, INT_MAX, &tid_lock); =20 thread_zone =3D uma_zcreate("THREAD", sched_sizeof_thread(), diff --git a/sys/kern/subr_param.c b/sys/kern/subr_param.c index 8c13336..1c6b867 100644 --- a/sys/kern/subr_param.c +++ b/sys/kern/subr_param.c @@ -41,12 +41,13 @@ __FBSDID("$FreeBSD$"); #include "opt_msgbuf.h" #include "opt_maxusers.h" =20 -#include #include #include #include -#include +#include #include +#include +#include =20 #include #include @@ -92,6 +93,7 @@ int ncallout; /* maximum # of timer events */ int nbuf; int ngroups_max; /* max # groups per process */ int nswbuf; +pid_t pid_max =3D PID_MAX; long maxswzone; /* max swmeta KVA storage */ long maxbcache; /* max buffer cache KVA storage */ long maxpipekva; /* Limit on pipe KVA */ @@ -250,6 +252,13 @@ init_param1(void) TUNABLE_INT_FETCH("kern.ngroups", &ngroups_max); if (ngroups_max < NGROUPS_MAX) ngroups_max =3D NGROUPS_MAX; + + /* + * Only allow to lower the maximal pid. + */ + TUNABLE_INT_FETCH("kern.pid_max", &pid_max); + if (pid_max > PID_MAX) + pid_max =3D PID_MAX; } =20 /* diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c index 3883fe4..39e2a58 100644 --- a/sys/kern/sys_process.c +++ b/sys/kern/sys_process.c @@ -673,7 +673,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) p =3D td->td_proc; PROC_LOCK(p); } else { - if (pid <=3D PID_MAX) { + if (pid <=3D pid_max) { if ((p =3D pfind(pid)) =3D=3D NULL) { if (proctree_locked) sx_xunlock(&proctree_lock); diff --git a/sys/nlm/nlm_advlock.c b/sys/nlm/nlm_advlock.c index 416cd1d..0c53be1 100644 --- a/sys/nlm/nlm_advlock.c +++ b/sys/nlm/nlm_advlock.c @@ -98,6 +98,7 @@ nlm_client_init(void *dummy) int i; =20 mtx_init(&nlm_svid_lock, "NLM svid lock", NULL, MTX_DEF); + /* pid_max cannot be greater then PID_MAX */ nlm_svid_allocator =3D new_unrhdr(PID_MAX + 2, INT_MAX, &nlm_svid_lock); for (i =3D 0; i < NLM_SVID_HASH_SIZE; i++) LIST_INIT(&nlm_file_svids[i]); diff --git a/sys/sys/proc.h b/sys/sys/proc.h index 06df632..4c4aa2f 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -696,11 +696,12 @@ MALLOC_DECLARE(M_SUBPROC); #define FIRST_THREAD_IN_PROC(p) TAILQ_FIRST(&(p)->p_threads) =20 /* - * We use process IDs <=3D PID_MAX; PID_MAX + 1 must also fit in a pid_t, - * as it is used to represent "no process group". + * We use process IDs <=3D pid_max <=3D 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 NO_PID 100000 +extern pid_t pid_max; =20 #define SESS_LEADER(p) ((p)->p_session->s_leader =3D=3D (p)) =20 --/unnNtmY43mpUSKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAqTXQACgkQC3+MBN1Mb4jyawCg1eYRwUtO8pL/8ebpRVsFamsB FCsAoIq1cgz0KNM/dpZHrjtlYwZHHcsS =IfFX -----END PGP SIGNATURE----- --/unnNtmY43mpUSKx-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 15:15: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 4B2CA106564A; Tue, 14 Aug 2012 15:15:21 +0000 (UTC) (envelope-from listlog2011@gmail.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 DC66E8FC12; Tue, 14 Aug 2012 15:15:20 +0000 (UTC) Received: by yhfs35 with SMTP id s35so693474yhf.13 for ; Tue, 14 Aug 2012 08:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qUfi/qeFMCv+7HQSCNGX57aB8TbgaWgAJpRPkmvwgQg=; b=E58xjdA3G8y7DEQL7YR4ZihDlC01+mJlu1FVy0iR7GAhS8p0FFrWijls+WSnXL8xe5 nYcTuUdbsc9z4kUGbvC+6JKiee3SuyvHSJ7BpbtdwONcphcoYK3/EHsldALfbCoZSd69 rSxC1XaxXGgi/KNEagnhccvmq80eCuRq59jxFuUBL8C5KIflndILAwmDsViFsRvDQh/t MCaFnm8A+oyQ3OAaCo4b4JL7+Yzxoim0cBUhJkvh32uwB8CjvGHG3sCotRP+WUnP4f08 QwSw4va0XtGOntK7r3996mXkw2ntYBJLy4dXdz/JsSb0C1Q/lM/C9yQMK7+NSg8wCPv9 OTJw== Received: by 10.66.78.195 with SMTP id d3mr21472239pax.17.1344957313735; Tue, 14 Aug 2012 08:15:13 -0700 (PDT) Received: from xp5k.my.domain ([220.184.79.100]) by mx.google.com with ESMTPS id nd2sm847139pbc.7.2012.08.14.08.15.09 (version=SSLv3 cipher=OTHER); Tue, 14 Aug 2012 08:15:12 -0700 (PDT) Message-ID: <502A6B7A.6070504@gmail.com> Date: Tue, 14 Aug 2012 23:15:06 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> In-Reply-To: <20120814094111.GB5883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, David Xu , Jilles Tjoelker Subject: Re: system() using vfork() or posix_spawn() and libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 15:15:21 -0000 On 2012/08/14 17:41, Konstantin Belousov wrote: > On Tue, Aug 14, 2012 at 05:16:56PM +0800, David Xu wrote: >> On 2012/08/14 16:18, Konstantin Belousov wrote: >>> On Tue, Aug 14, 2012 at 12:42:15PM +0800, David Xu wrote: >>>> I simply duplicated idea from OpenSolaris, here is my patch >>>> which has similar feature as your patch, and it also tries to >>>> prevent vforked child from corrupting parent's data: >>>> http://people.freebsd.org/~davidxu/patch/libthr-vfork.diff >>> You shall not return from vfork() frame in the child. Otherwise, the >>> same frame is appears to be destroyed in parent, and parent dies. More >>> often on !x86, but right combination of events on x86 is deadly too. >>> If pid or curthread local variables are spilled into stack save area, >>> then child will override them, and e.g. parent could see pid == 0, >>> returning it to caller. >>> >>> This was the reason why I went to asm wrapper for vfork. >>> >> OK. >> >>> Also, it seems that in mt process, malloc and rtld are still broken, >>> or am I missing something ? >> I will not call it as broken, malloc and rtld are working properly. >> vfork is not a normal function, for MT process, fork() is even >> very special too. >> >> POSIX says a lot about multi-threaded: >> http://pubs.opengroup.org/onlinepubs/000095399/functions/fork.html >> >> I quoted some POSIX document here: >>> A process shall be created with a single thread. If a multi-threaded >>> process calls fork(), the new process shall contain a replica of the >>> calling thread and its entire address space, possibly including the >>> states of mutexes and other resources. Consequently, to avoid errors, >>> the child process may only execute async-signal-safe operations until >>> such time as one of the exec functions is called. [THR] Fork >>> handlers may be established by means of the pthread_atfork() function >>> in order to maintain application invariants across fork() calls. >> This means child process should only do very simple things, and >> quickly call execv(). > Sure. > > But to call execv*, the child may need a working rtld, so we fixed it. > User code routinely called malloc() or even created threads in the child, > so we fixed that too. Otherwise, we have nothing to answer for the demands, > and 'other' OSes do support such usage. It is beyond POSIX, but this does > not matter, since the feature is expected to be available by application > writers. > >> For mt process, fork() is already a very complicated problem, >> one of problems I still remembered is that when fork() is called in >> signal handler, should the thread library execute pthread_atfork >> handler ? if it should do, but none of lock is async-signal safe, >> though our internal rwlock allows to be used in signal handler, >> but it is not supported by POSIX. >> Also are those atfork handler prepared to be executed in signal >> handler ? it is undefined. POSIX had opened a door here. > POSIX authors were aware of this problem. > In the rationale for SUSv4, they wrote > > "While the fork() function is async-signal-safe, there is no way for an > implementation to determine whether the fork handlers established by > pthread_atfork() are async-signal-safe. The fork handlers may attempt to > execute portions of the implementation that are not async-signal-safe, > such as those that are protected by mutexes, leading to a deadlock > condition. It is therefore undefined for the fork handlers to execute > functions that are not async-signal-safe when fork() is called from a > signal handler." > > IMO, since fork() is specified to be async-signal safe, and since fork() > is specified to call atfork() handlers, SUSv4 requires, without any > misinterpreations, that atfork calling machinery must be async-signal > safe. The only possibility for undefined behaviour is the application > code registering non-async safe handlers. But in real word, pthread atfork handlers are not async-signal safe, they mostly do mutex locking and unlocking to keep consistent state, mutex is not async-signal safe. The malloc prefork and postfork handlers happen to work because I have some hacking code in library for malloc locks. Otherwise, you even can not use fork() in signal handler. >> Above is one of complicated problem, the vfork is even more >> restrictive than fork(). >> If it is possible, I would avoid such a complicated problem >> which vfork() would cause. > I fully agree that the issues caused by vfork() in multithreaded code > are complicated, but ignoring them lowers the quality of our implementation. > Fixing vfork in multithreaded process is not trivial, but it is possible. > > My patch aims at working rtld and malloc in child. > As I said earlier, we might even try to call parent atfork handlers in child. > > Sure, if child dies at wrong time, then rtld and malloc locks and data > structures can be left in unusable state for parent, but currently we > do not work even if child is relatively well-behaving. You are requiring the thread library to implement such a mutex and other locks, that after vfork(), the mutex and other lock types must still work across processes, the PTHREAD_PROCESS_PRIVATE type of mutex and other locks now need to work in a PTHREAD_PROCESS_SHARE mode. Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 21:09:13 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 8E47E106564A; Tue, 14 Aug 2012 21:09:13 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 21DD58FC0C; Tue, 14 Aug 2012 21:09:13 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 821B51DD45A; Tue, 14 Aug 2012 23:09:11 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 67F842847B; Tue, 14 Aug 2012 23:09:11 +0200 (CEST) Date: Tue, 14 Aug 2012 23:09:11 +0200 From: Jilles Tjoelker To: davidxu@freebsd.org Message-ID: <20120814210911.GA90640@stack.nl> References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <502A6B7A.6070504@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-hackers@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: Tue, 14 Aug 2012 21:09:13 -0000 On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: > But in real word, pthread atfork handlers are not async-signal safe, > they mostly do mutex locking and unlocking to keep consistent state, > mutex is not async-signal safe. > The malloc prefork and postfork handlers happen to work because I have > some hacking code in library for malloc locks. Otherwise, you even > can not use fork() in signal handler. This problem was also reported to the Austin Group at http://austingroupbugs.net/view.php?id=62 Atfork handlers are inherently async-signal-unsafe. An interpretation was issued suggesting to remove fork() from the list of async-signal-safe functions and add a new async-signal-safe function _Fork() which does not call the atfork handlers. This change will however not be in POSIX.1-2008 TC1 but only in the next issue (SUSv5). A slightly earlier report http://austingroupbugs.net/view.php?id=18 just requested the _Fork() function because an existing application deadlocked when calling fork() from a signal handler. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 21:46:02 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 39387106566C; Tue, 14 Aug 2012 21:46:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.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 C33CB8FC14; Tue, 14 Aug 2012 21:46:01 +0000 (UTC) Received: by yhfs35 with SMTP id s35so1262011yhf.13 for ; Tue, 14 Aug 2012 14:46:01 -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=Y3GxitN5bwJ98QZhj0UY7xY/FLgZ3EMSF6eh0nBnhuA=; b=Ep2R2ygGPfs1auyGQSora9UKacd6cJQ6aDjP+EuT/1QxTpRxoF8VtrNgNMXLMQCsTm B+TPAXYibvNzHkfa2L85oge+TnAi3ETlvsCJDUNNsgQMD0wkJb7MSzzX6Ax2LUceg3in u7Unc77fX1Vq0VXclJvuC9Uf6H3D2uMJHV6CV0kU0umIUtDdCdxlIwYvH1bjLUxHzS9k HF1JWZZltBO69iUCWRoiIPv2WFrgZAwXOD0Zqcfvrk+msnB36DuvJuZX2QOsJH9CIDRh /mdXdbXTEaAmYmYjSGnBYINe9gbMrJ5g7+sBl2gLGR4wqXvWg7Y/r5sc9Ew57ZhfYxUD TZ8w== MIME-Version: 1.0 Received: by 10.68.236.102 with SMTP id ut6mr38473930pbc.113.1344980761071; Tue, 14 Aug 2012 14:46:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Tue, 14 Aug 2012 14:46:01 -0700 (PDT) In-Reply-To: <20120814130700.GD5883@deviant.kiev.zoral.com.ua> References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> <5029A9CE.8070307@freebsd.org> <20120814130700.GD5883@deviant.kiev.zoral.com.ua> Date: Tue, 14 Aug 2012 14:46:01 -0700 X-Google-Sender-Auth: ABtaA0cL3OMtQCGuz924DL1WF9A Message-ID: From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Dan Plassche 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: Tue, 14 Aug 2012 21:46:02 -0000 Could you do something dirty that lets you reserve PIDs between 0 .. 65534 and then mark a jail as having PIDs only in that space? That way you could run FreeBSD 1.x and 2.x (?) jails with this particular flag set and all processes inside it would use that. (Then handle PID_MAX right for "no process group".) Dirty, but maybe? Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 23:40: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 D191A106566B; Tue, 14 Aug 2012 23:40:10 +0000 (UTC) (envelope-from listlog2011@gmail.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 62CA08FC16; Tue, 14 Aug 2012 23:40:10 +0000 (UTC) Received: by yenl7 with SMTP id l7so1402800yen.13 for ; Tue, 14 Aug 2012 16:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+RUmvvGZnxklPJ1iFxEW8hhgSAYQkzctTQ77Y+TjEAM=; b=nS7MestaD3K7zITlHhogWpO0NKkiT8l7O/UqN3pNeUWewuvtM1m2M8X9qHc6w4vFML P4N9wJoUJToJcJptN5ZqfLdQ88KpMJ4nLVYNU8W10iiqc5oBw2nDbyRY1tQJTiiqWwl+ KEMYEivwwfkZFVwxkV5NjQAmFCpwupRbQlppJOZiNosn+OWe+R16uzInJagcrcN07q/Q p6UxKQvO/iHUwRduw1dtZvZVa+/7lrwmSBveCVrZK/2zsHgj6qKff56RtfmtRXcz2fJo 3anneSKqhc6P0PE60FvGRp9c4jr3drbWy11gF0LMsaXtswq5r8DoQ7Clw6J0+3UA5Yiq ki8Q== Received: by 10.66.90.67 with SMTP id bu3mr22805453pab.26.1344987608813; Tue, 14 Aug 2012 16:40:08 -0700 (PDT) Received: from xp5k.my.domain ([115.192.128.117]) by mx.google.com with ESMTPS id st6sm34907pbc.58.2012.08.14.16.40.06 (version=SSLv3 cipher=OTHER); Tue, 14 Aug 2012 16:40:07 -0700 (PDT) Message-ID: <502AE1D4.4060308@gmail.com> Date: Wed, 15 Aug 2012 07:40:04 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jilles Tjoelker References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com> <20120814210911.GA90640@stack.nl> In-Reply-To: <20120814210911.GA90640@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , 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 Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 23:40:11 -0000 On 2012/08/15 05:09, Jilles Tjoelker wrote: > On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: >> But in real word, pthread atfork handlers are not async-signal safe, >> they mostly do mutex locking and unlocking to keep consistent state, >> mutex is not async-signal safe. >> The malloc prefork and postfork handlers happen to work because I have >> some hacking code in library for malloc locks. Otherwise, you even >> can not use fork() in signal handler. > This problem was also reported to the Austin Group at > http://austingroupbugs.net/view.php?id=62 > > Atfork handlers are inherently async-signal-unsafe. > > An interpretation was issued suggesting to remove fork() from the list > of async-signal-safe functions and add a new async-signal-safe function > _Fork() which does not call the atfork handlers. > > This change will however not be in POSIX.1-2008 TC1 but only in the next > issue (SUSv5). > > A slightly earlier report http://austingroupbugs.net/view.php?id=18 just > requested the _Fork() function because an existing application > deadlocked when calling fork() from a signal handler. > Thanks, although SUSv5 will have _Fork(), but application will not catch up. One solution for this problem is thread library does not execute atfork handler when fork() is called from signal handler, but it requires some work to be done in thread library's signal wrapper, for example, set a flag that the thread is executing signal handler, but siglongjmp can mess the flag, so I have to tweak sigsetjmp and siglongjmp to save/restore the flag, I have such a patch: it fetches target stack pointer stored in jmpbuf, and compare it with top most stack pointer when a first signal was delivered to the thread, if the target stack pointer is larger than the top most stack pointer, the flag is cleared. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 08:33:48 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 02112106566C for ; Wed, 15 Aug 2012 08:33:48 +0000 (UTC) (envelope-from dgre090@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 ADD598FC12 for ; Wed, 15 Aug 2012 08:33:47 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1664741vbm.13 for ; Wed, 15 Aug 2012 01:33:46 -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=9+95uJ/TERfLWFfCawdo9S28dzZuGaM/MkSWpM9XeoY=; b=s1Ss/2apCMkSsgCBtIdhlBXhBM/ihSd2lBivDX0ZqoZD2Q5/NxJfzAOYYItx0YdLZ/ 2ueP3bqbt8xHJJq9XeZ0Spl0y+vQefr/jiXzFmCiSWFa+gA1qEg3rgvwoj5iFOS8y6NS DW4CDlZRP9PnAjC/hVloRsQo92MR92h76eE89xF99mBwCnK/KK11BZRZY1zYHE0JY0by XrOewrmi4VUk+17O4t5ZbYFygP2oY8qFWnbkJ+wI6ThlyWMmTDSwImMNUMQd8cNZCEfo l3k6gKout6SdlcDaSIMyON6X0ieXmsftJaaIgwzmidRKvahaGULYtzRm5X8LMo2u8o5z Voeg== MIME-Version: 1.0 Received: by 10.220.149.130 with SMTP id t2mr12414065vcv.8.1345019626753; Wed, 15 Aug 2012 01:33:46 -0700 (PDT) Received: by 10.58.132.143 with HTTP; Wed, 15 Aug 2012 01:33:46 -0700 (PDT) Date: Wed, 15 Aug 2012 10:33:46 +0200 Message-ID: From: Daniel Grech To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unsigned Integer Encoding 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, 15 Aug 2012 08:33:48 -0000 Hi, I have what is probably a really elementary question but I can't seem to figure it out. In the following snippet of code, why is it that a and b do not have the same value in the end ? : #define uint32_t unsigned int #define uint16_t unsigned short #define uint8_t unsigned char #define uint64_t unsigned long long int main () { uint32_t a = 0x01020304; /* This prints 01020304 */ printf ("a = %0X \n",a); uint32_t * b; uint8_t bytes [] = {0x01,0x02,0x03,0x04}; b = (uint32_t *) bytes; /* This prints 04030201 */ printf ("b= %0X \n", *b); return 1; } Im asking this as I am currently encoding a protocol in which i receive data as a sequence of bytes. Casting for example 4 bytes from this stream leaves me with the situation in variable b, while the situation I am looking to accomplish is the one in A (i.e. the bytes are not encoded in reverse form). Thanks in advance for your help. Regards, Daniel From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 08:34:45 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 1DBC810657C9 for ; Wed, 15 Aug 2012 08:34:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id BC33B8FC17 for ; Wed, 15 Aug 2012 08:34:44 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1T1YwR-000Gfo-O4 for freebsd-hackers@freebsd.org; Wed, 15 Aug 2012 11:27:03 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2012 11:27:03 +0300 From: Daniel Braniss Message-ID: Subject: GPT boot from 2nd. disk fails 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, 15 Aug 2012 08:34:45 -0000 hi, this host has to disks: sa0> gpart show => 34 976773101 ada0 GPT (465G) 34 128 1 freebsd-boot (64k) 162 4194304 2 freebsd-ufs (2.0G) 4194466 33554432 3 freebsd-swap (16G) 37748898 939024237 4 freebsd-zfs (447G) => 34 976773101 ada1 GPT (465G) 34 128 1 freebsd-boot (64k) 162 4194304 2 freebsd-ufs [bootme] (2.0G) 4194466 8388608 3 freebsd-swap (4.0G) 12583074 964190061 4 freebsd-zfs (459G) but no amount of magic will cause boot from the second disk, it will always boot from the first disk. any insights? danny From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 08:46:29 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 EE8C81065673 for ; Wed, 15 Aug 2012 08:46:29 +0000 (UTC) (envelope-from yanegomi@gmail.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 A7C858FC1A for ; Wed, 15 Aug 2012 08:46:29 +0000 (UTC) Received: by yenl7 with SMTP id l7so1830633yen.13 for ; Wed, 15 Aug 2012 01:46:29 -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=BxAr1QWFpB1W20ggUl5WzULGPdzcrZBQyHD9TCwd8O4=; b=aj4k2FBYFv1yzOYmKzz54Rbpak23ZUnGKn4AGse61JYUaVvhQlqGthwLvo8TeaekW0 NmLB3ZljXIfk8x3oUc6+ll9qkFfa3x2ZwIYFT5A/D+sC0hcTRcqZgvSsf1uf9jSEXMyy ZgNKt5pxF9DDeLRPz85fYLrHdxBizJqO7gQUptPsMcTHZsnk0kUM1mP8i7RIqy1wLMl2 NZ5g1kBQyGBsHcCbmnzvoCjoq9riLgVDbGi76ETn3VJ4y0oTdYTB0XXyTFW/fAowH8jo 7ID+ny+f0fodgdgL8Lontoc+pmBtVU8twyWCZx/368NYVa2wk8/VmeIzJNzKUQbGZNl0 Hg3w== MIME-Version: 1.0 Received: by 10.42.114.16 with SMTP id e16mr16803370icq.57.1345020388795; Wed, 15 Aug 2012 01:46:28 -0700 (PDT) Received: by 10.64.176.200 with HTTP; Wed, 15 Aug 2012 01:46:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Aug 2012 01:46:28 -0700 Message-ID: From: Garrett Cooper To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: GPT boot from 2nd. disk fails 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, 15 Aug 2012 08:46:30 -0000 On Wed, Aug 15, 2012 at 1:27 AM, Daniel Braniss wrote: > hi, > this host has to disks: > sa0> gpart show > => 34 976773101 ada0 GPT (465G) > 34 128 1 freebsd-boot (64k) > 162 4194304 2 freebsd-ufs (2.0G) > 4194466 33554432 3 freebsd-swap (16G) > 37748898 939024237 4 freebsd-zfs (447G) > > => 34 976773101 ada1 GPT (465G) > 34 128 1 freebsd-boot (64k) > 162 4194304 2 freebsd-ufs [bootme] (2.0G) > 4194466 8388608 3 freebsd-swap (4.0G) > 12583074 964190061 4 freebsd-zfs (459G) > > but no amount of magic will cause boot from the second disk, it will always > boot from the first disk. > > any insights? Use boot0cfg -s 5 (untested with GPT disks)? HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 08:48:01 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 ADAD4106567E for ; Wed, 15 Aug 2012 08:48:01 +0000 (UTC) (envelope-from vhaisman@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 295888FC08 for ; Wed, 15 Aug 2012 08:48:00 +0000 (UTC) Received: by bkcje9 with SMTP id je9so499928bkc.13 for ; Wed, 15 Aug 2012 01:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=+SFQeTvb1qficjmaQN9VFlKu9Xy/3AgCVFL/efq/RPw=; b=Q5GrAQd6L4HCSfvwtJ5BlHnlH/gYimz6Zgy/giWjgZrO6bHXOphrEEjF4IPiWkZjLy 5zE1ppo1zeV0iNx+xl/Mf9WEQcGE1zEYMYLv2S4q9n+X9E04OLij6DZ4olIySsfAVh0n rR9KxBm9dj9ECFLyWpUrcH3S9M9OouOWsMU2StaMtqaE5syXe1OnH/qfyVwfGc//MgsB V0RdEiy3VB/lH0WKFGkJGvZ0JesvG78VdP+bo/utSIefOih3fPXvXEi4ezgyheUxlxy0 AdWcT99t4x48FCxnNFF6rsE2+wgwbJoWjQGGJh/PrFfEZalJYrR27E+4w/bBK3FYb60Y dGdw== Received: by 10.204.130.211 with SMTP id u19mr7326339bks.24.1345020479659; Wed, 15 Aug 2012 01:47:59 -0700 (PDT) Received: from [10.0.0.1] (242.91.broadband5.iol.cz. [88.100.91.242]) by mx.google.com with ESMTPS id t23sm380630bks.4.2012.08.15.01.47.57 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 01:47:58 -0700 (PDT) Message-ID: <502B623B.2070606@gmail.com> Date: Wed, 15 Aug 2012 10:47:55 +0200 From: =?ISO-8859-1?Q?V=E1clav_Zeman?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig73BEA7D173F9960B8AA395F1" Subject: Re: Unsigned Integer Encoding 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, 15 Aug 2012 08:48:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig73BEA7D173F9960B8AA395F1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/15/2012 10:33 AM, Daniel Grech wrote: > Hi, > > I have what is probably a really elementary question but I can't seem t= o > figure it out. In the following snippet of code, why is it that a and b= do > not have the same value in the end ? : > > #define uint32_t unsigned int > #define uint16_t unsigned short > #define uint8_t unsigned char > #define uint64_t unsigned long long > > int main () > { > uint32_t a =3D 0x01020304; > > /* This prints 01020304 */ > printf ("a =3D %0X \n",a); > > uint32_t * b; > > uint8_t bytes [] =3D {0x01,0x02,0x03,0x04}; > > b =3D (uint32_t *) bytes; You cannot do this cast. The bytes array does not have to be sufficiently aligned and you will get SIGBUS errors on strict alignment platforms. Use memcpy() to copy from the bytes array to b instead, that is the only portable way to do this. > > /* This prints 04030201 */ This is correct for LE platforms. The least significant byte (1) is first in the array. You need to know which order of bytes does the protocol use for transport (LE or BE) and then have the implementation either swap or not swap the bytes appropriately. > printf ("b=3D %0X \n", *b); > return 1; > } > > Im asking this as I am currently encoding a protocol in which i receive= > data as a sequence of bytes. Casting for example 4 bytes from this stre= am > leaves me with the situation in variable b, while the situation I am > looking to accomplish is the one in A (i.e. the bytes are not encoded i= n > reverse form). > > Thanks in advance for your help. --=20 VZ --------------enig73BEA7D173F9960B8AA395F1 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.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlArYjsACgkQ6OWUyaYNY6MRzgD7BdmGsUzPIYKZKFZ/QofJsLdn L9f4HG0GC8fH9eL2U74A/2ONwGMLRWtpQs93ftDtO91x6nZoq5SPzfbxtknEUmIN =QQ7b -----END PGP SIGNATURE----- --------------enig73BEA7D173F9960B8AA395F1-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 08:51:21 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 7CD2A106566C for ; Wed, 15 Aug 2012 08:51:21 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 0C01E8FC1B for ; Wed, 15 Aug 2012 08:51:20 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7F8pGi0014046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 18:51:17 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7F8pB8P046790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2012 18:51:11 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7F8pBvi046789; Wed, 15 Aug 2012 18:51:11 +1000 (EST) (envelope-from peter) Date: Wed, 15 Aug 2012 18:51:11 +1000 From: Peter Jeremy To: Daniel Grech Message-ID: <20120815085111.GA38845@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: Unsigned Integer Encoding 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, 15 Aug 2012 08:51:21 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-15 10:33:46 +0200, Daniel Grech wrote: >Hi, > >I have what is probably a really elementary question but I can't seem to >figure it out. In the following snippet of code, why is it that a and b do >not have the same value in the end ? : See http://en.wikipedia.org/wiki/Endian >Im asking this as I am currently encoding a protocol in which i receive >data as a sequence of bytes. Casting for example 4 bytes from this stream >leaves me with the situation in variable b, while the situation I am >looking to accomplish is the one in A (i.e. the bytes are not encoded in >reverse form). I suggest you look at xdr(3) and rpcgen(1) --=20 Peter Jeremy --wac7ysb48OaltWcw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlArYv8ACgkQ/opHv/APuIfSJwCgwkK8lQlomZ5u2E/IHZH7Wx3l vzgAnjVYVgdBMKwdeUXP7WX5TP3x6xqR =TQhf -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 10:29:20 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 E08A71065673 for ; Wed, 15 Aug 2012 10:29:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 925A98FC08 for ; Wed, 15 Aug 2012 10:29:20 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q7FATCvB069232 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 15 Aug 2012 03:29:13 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <502B79F3.2020703@freebsd.org> Date: Wed, 15 Aug 2012 03:29:07 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Konstantin Belousov References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> <5029A9CE.8070307@freebsd.org> <20120814130700.GD5883@deviant.kiev.zoral.com.ua> In-Reply-To: <20120814130700.GD5883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Dan Plassche Subject: Re: [maybe spam] 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: Wed, 15 Aug 2012 10:29:21 -0000 On 8/14/12 6:07 AM, Konstantin Belousov wrote: > On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote: >> On 8/13/12 3:33 PM, Dan Plassche wrote: >>> Konstantin, >>> >>> My apologies for any confusion. Your patch solved the problem on >>> 8.2. Static and dynamic a.out binaries from 1.1.5.1 are working >>> normally in a chroot environment now. >> you will also have to change PID_MAX (spelling?) to be 60000 >> I have considered making this a tunable.. >> If you don't then the shell in the 1.1.5.1 environment will not be >> able to handle when a child >> get s a pid of > 16 bits and it will not be able to wait on it. so it >> will suspend for ever. >> teh result is that you can not complete a "make world". >> >> last time I tried a "make world" completed in about 1 minute and a kernel >> (1.1.5.1 GENERIC) compiled in way less than a minute. that was in 7.x >> days. >> >> I'd like to see results under 9.2 on a modern machine. > I committed today a batch of changes that allowed me to run most of > the binaries from 1.1.5.1 CD on real amd64 machine. > > Below is the pid_max tunable patch. I first thought that it cannot be > made a writeable sysctl, but then realized that there is nothing wrong > with having existing process pid be greater then pid_max, as far as it > is less then PID_MAX. > cool.. One thing that may be doing is to have pid_max either inherrited from a parent or jail or somehow influenced by the exec handler.. or (I know adrian suggested this too.) for example if you have an ancestor that is an old a.out image then maybe the system could do the right thing. it wouldn't be able to handle it's OWN pid maybe, but it could handle children. hmm maybe that isn't such a good idea... From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 10:55:44 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 CDCE7106566B for ; Wed, 15 Aug 2012 10:55:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7EDC88FC08 for ; Wed, 15 Aug 2012 10:55:44 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q7FAtgN8069311 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 15 Aug 2012 03:55:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <502B8029.1010205@freebsd.org> Date: Wed, 15 Aug 2012 03:55:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Konstantin Belousov References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> <5029A9CE.8070307@freebsd.org> <20120814130700.GD5883@deviant.kiev.zoral.com.ua> <502B79F3.2020703@freebsd.org> In-Reply-To: <502B79F3.2020703@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Dan Plassche Subject: Re: [maybe spam] 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: Wed, 15 Aug 2012 10:55:44 -0000 On 8/15/12 3:29 AM, Julian Elischer wrote: > On 8/14/12 6:07 AM, Konstantin Belousov wrote: >> On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote: >>> On 8/13/12 3:33 PM, Dan Plassche wrote: >>>> Konstantin, >>>> >>>> My apologies for any confusion. Your patch solved the problem on >>>> 8.2. Static and dynamic a.out binaries from 1.1.5.1 are working >>>> normally in a chroot environment now. >>> you will also have to change PID_MAX (spelling?) to be 60000 >>> I have considered making this a tunable.. >>> If you don't then the shell in the 1.1.5.1 environment will not be >>> able to handle when a child >>> get s a pid of > 16 bits and it will not be able to wait on it. so it >>> will suspend for ever. >>> teh result is that you can not complete a "make world". >>> >>> last time I tried a "make world" completed in about 1 minute and a >>> kernel >>> (1.1.5.1 GENERIC) compiled in way less than a minute. that was in 7.x >>> days. >>> >>> I'd like to see results under 9.2 on a modern machine. >> I committed today a batch of changes that allowed me to run most of >> the binaries from 1.1.5.1 CD on real amd64 machine. >> >> Below is the pid_max tunable patch. I first thought that it cannot be >> made a writeable sysctl, but then realized that there is nothing wrong >> with having existing process pid be greater then pid_max, as far as it >> is less then PID_MAX. >> > cool.. > One thing that may be doing is to have pid_max either inherrited > from a parent or jail or somehow > influenced by the exec handler.. or (I know adrian suggested this > too.) > > for example if you have an ancestor that is an old a.out image then > maybe the system could do the right thing. > it wouldn't be able to handle it's OWN pid maybe, but it could > handle children. > hmm maybe that isn't such a good idea... so kib: so when you have it all working, time a make world for us! From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 13:34:53 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 E010B106566B for ; Wed, 15 Aug 2012 13:34:53 +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 48EC88FC08 for ; Wed, 15 Aug 2012 13:34:52 +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 q7FDYj13058305; Wed, 15 Aug 2012 15:34:45 +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 q7FDYiBl058302; Wed, 15 Aug 2012 15:34:44 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 15 Aug 2012 15:34:44 +0200 (CEST) From: Wojciech Puchar To: Daniel Grech In-Reply-To: Message-ID: References: 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, 15 Aug 2012 15:34:45 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: Unsigned Integer Encoding 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, 15 Aug 2012 13:34:54 -0000 > /* This prints 04030201 */ > printf ("b= %0X \n", *b); > all is OK, you did this probably on x86 CPU which is little endian. on powerpc it would be 01020304 as it is big endian. to write endian independent code: man htonl all these are macros actually. "network order" is big endian. so eg htonl would reverse order on x86, and ddo nothing on powerpc. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 15:52: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 023D61065677 for ; Wed, 15 Aug 2012 15:52:26 +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 CB0F38FC17 for ; Wed, 15 Aug 2012 15:52:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 22B05B99A; Wed, 15 Aug 2012 11:52:25 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 15 Aug 2012 11:16:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208151116.21461.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 15 Aug 2012 11:52:25 -0400 (EDT) Cc: Garrett Cooper Subject: Re: GPT boot from 2nd. disk fails 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, 15 Aug 2012 15:52:26 -0000 On Wednesday, August 15, 2012 4:46:28 am Garrett Cooper wrote: > On Wed, Aug 15, 2012 at 1:27 AM, Daniel Braniss wrote: > > hi, > > this host has to disks: > > sa0> gpart show > > => 34 976773101 ada0 GPT (465G) > > 34 128 1 freebsd-boot (64k) > > 162 4194304 2 freebsd-ufs (2.0G) > > 4194466 33554432 3 freebsd-swap (16G) > > 37748898 939024237 4 freebsd-zfs (447G) > > > > => 34 976773101 ada1 GPT (465G) > > 34 128 1 freebsd-boot (64k) > > 162 4194304 2 freebsd-ufs [bootme] (2.0G) > > 4194466 8388608 3 freebsd-swap (4.0G) > > 12583074 964190061 4 freebsd-zfs (459G) > > > > but no amount of magic will cause boot from the second disk, it will always > > boot from the first disk. > > > > any insights? > > Use boot0cfg -s 5 (untested with GPT disks)? Will not work with GPT disks. They use /boot/pmbr to boot, not /boot/boot0. If you can get your BIOS to explicitly boot ada1 from the start via a BIOS setting, that should work. Another option would be to break into gptboot's prompt (similar to breaking into boot2) aud typing in 'ad1p2:/boot/loader' or some such. If that works you should even be able to write that to /boot.config on ada0p2's filesystem. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 16:09: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 955471065675; Wed, 15 Aug 2012 16:09: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 2A3EC8FC0A; Wed, 15 Aug 2012 16:09: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 q7FG9i17005513; Wed, 15 Aug 2012 19:09:44 +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 q7FG9VvR025368; Wed, 15 Aug 2012 19:09:31 +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 q7FG9VDW025367; Wed, 15 Aug 2012 19:09:31 +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: Wed, 15 Aug 2012 19:09:31 +0300 From: Konstantin Belousov To: Julian Elischer Message-ID: <20120815160931.GJ5883@deviant.kiev.zoral.com.ua> References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> <5029A9CE.8070307@freebsd.org> <20120814130700.GD5883@deviant.kiev.zoral.com.ua> <502B79F3.2020703@freebsd.org> <502B8029.1010205@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5me2qT3T17SWzdxI" Content-Disposition: inline In-Reply-To: <502B8029.1010205@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, Dan Plassche Subject: Re: [maybe spam] 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: Wed, 15 Aug 2012 16:09:35 -0000 --5me2qT3T17SWzdxI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 15, 2012 at 03:55:37AM -0700, Julian Elischer wrote: > On 8/15/12 3:29 AM, Julian Elischer wrote: > >On 8/14/12 6:07 AM, Konstantin Belousov wrote: > >>On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote: > >>>On 8/13/12 3:33 PM, Dan Plassche wrote: > >>>>Konstantin, > >>>> > >>>>My apologies for any confusion. Your patch solved the problem on > >>>>8.2. Static and dynamic a.out binaries from 1.1.5.1 are working > >>>>normally in a chroot environment now. > >>>you will also have to change PID_MAX (spelling?) to be 60000 > >>>I have considered making this a tunable.. > >>>If you don't then the shell in the 1.1.5.1 environment will not be > >>>able to handle when a child > >>>get s a pid of > 16 bits and it will not be able to wait on it. so it > >>>will suspend for ever. > >>>teh result is that you can not complete a "make world". > >>> > >>>last time I tried a "make world" completed in about 1 minute and a=20 > >>>kernel > >>>(1.1.5.1 GENERIC) compiled in way less than a minute. that was in 7.x > >>>days. > >>> > >>>I'd like to see results under 9.2 on a modern machine. > >>I committed today a batch of changes that allowed me to run most of > >>the binaries from 1.1.5.1 CD on real amd64 machine. > >> > >>Below is the pid_max tunable patch. I first thought that it cannot be > >>made a writeable sysctl, but then realized that there is nothing wrong > >>with having existing process pid be greater then pid_max, as far as it > >>is less then PID_MAX. > >> > >cool.. > >One thing that may be doing is to have pid_max either inherrited=20 > >from a parent or jail or somehow > >influenced by the exec handler.. or (I know adrian suggested this=20 > >too.) > > > >for example if you have an ancestor that is an old a.out image then=20 > >maybe the system could do the right thing. > >it wouldn't be able to handle it's OWN pid maybe, but it could=20 > >handle children. > >hmm maybe that isn't such a good idea... >=20 > so kib: so when you have it all working, time a make world for us! >=20 It seems that on single-threaded build done on Core i7 2600K with 8GB RAM, I get around 17 seconds for make world. This is with amd64 kernel @r239301 on SU+J UFS. 'Seems' because I cannot restart build, it dies whining about unaccessible obj. I noted that it created some obj/ directories in bin/cat etc. I have no much time now to look into this recreational stuff. >=20 --5me2qT3T17SWzdxI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlArybsACgkQC3+MBN1Mb4jaqwCdGDBhUCRorIc7IUSuBvyEZ+WI uOEAoOkl8fVgrzjEDDlIcD54FfHNWirV =ait9 -----END PGP SIGNATURE----- --5me2qT3T17SWzdxI-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 17:46:14 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 7FAA9106566B; Wed, 15 Aug 2012 17:46:14 +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 E59448FC12; Wed, 15 Aug 2012 17:46:12 +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 q7FHkLOp012204; Wed, 15 Aug 2012 20:46:21 +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 q7FHk9Xl025996; Wed, 15 Aug 2012 20:46:09 +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 q7FHk9bE025995; Wed, 15 Aug 2012 20:46:09 +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: Wed, 15 Aug 2012 20:46:09 +0300 From: Konstantin Belousov To: davidxu@freebsd.org Message-ID: <20120815174609.GM5883@deviant.kiev.zoral.com.ua> References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kunpHVz1op/+13PW" Content-Disposition: inline In-Reply-To: <502A6B7A.6070504@gmail.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: freebsd-hackers@freebsd.org, Jilles Tjoelker 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: Wed, 15 Aug 2012 17:46:14 -0000 --kunpHVz1op/+13PW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: > You are requiring the thread library to implement such a mutex > and other locks, that after vfork(), the mutex and other lock types must > still work across processes, the PTHREAD_PROCESS_PRIVATE type of > mutex and other locks now need to work in a PTHREAD_PROCESS_SHARE > mode. In fact, yes. In my patch I achieve this by single-threading the parent, which means that existing _PRIVATE mutexes are enough. --kunpHVz1op/+13PW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAr4GAACgkQC3+MBN1Mb4jQYwCcCuTNRr3jfB0bPouzvpWU8MC8 lF8AoMKuyTX8zUBZW3c6ty6fW1KaxwHA =yypn -----END PGP SIGNATURE----- --kunpHVz1op/+13PW-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 17:49:47 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 5536B106566C; Wed, 15 Aug 2012 17:49:47 +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 D66A08FC0A; Wed, 15 Aug 2012 17:49:46 +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 q7FHntlf012322; Wed, 15 Aug 2012 20:49:55 +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 q7FHngB0026017; Wed, 15 Aug 2012 20:49:42 +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 q7FHng7c026016; Wed, 15 Aug 2012 20:49:42 +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: Wed, 15 Aug 2012 20:49:42 +0300 From: Konstantin Belousov To: davidxu@freebsd.org Message-ID: <20120815174942.GN5883@deviant.kiev.zoral.com.ua> References: <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com> <20120814210911.GA90640@stack.nl> <502AE1D4.4060308@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cs5saTBZh7UZl2eX" Content-Disposition: inline In-Reply-To: <502AE1D4.4060308@gmail.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: freebsd-hackers@freebsd.org, Jilles Tjoelker 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: Wed, 15 Aug 2012 17:49:47 -0000 --cs5saTBZh7UZl2eX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 15, 2012 at 07:40:04AM +0800, David Xu wrote: > On 2012/08/15 05:09, Jilles Tjoelker wrote: > >On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: > >>But in real word, pthread atfork handlers are not async-signal safe, > >>they mostly do mutex locking and unlocking to keep consistent state, > >>mutex is not async-signal safe. > >>The malloc prefork and postfork handlers happen to work because I have > >>some hacking code in library for malloc locks. Otherwise, you even > >>can not use fork() in signal handler. > >This problem was also reported to the Austin Group at > >http://austingroupbugs.net/view.php?id=3D62 > > > >Atfork handlers are inherently async-signal-unsafe. > > > >An interpretation was issued suggesting to remove fork() from the list > >of async-signal-safe functions and add a new async-signal-safe function > >_Fork() which does not call the atfork handlers. > > > >This change will however not be in POSIX.1-2008 TC1 but only in the next > >issue (SUSv5). > > > >A slightly earlier report http://austingroupbugs.net/view.php?id=3D18 ju= st > >requested the _Fork() function because an existing application > >deadlocked when calling fork() from a signal handler. > > >=20 > Thanks, although SUSv5 will have _Fork(), but application will not catch = up. >=20 > One solution for this problem is thread library does not execute > atfork handler when fork() is called from signal handler, but it > requires some work to be done in thread library's signal wrapper, > for example, set a flag that the thread is executing signal handler, > but siglongjmp can mess the flag, so I have to tweak sigsetjmp and > siglongjmp to save/restore the flag, I have such a patch: it fetches > target stack pointer stored in jmpbuf, and compare it with top most > stack pointer when a first signal was delivered to the thread, if the > target stack pointer is larger than the top most stack pointer, the > flag is cleared. > I do not understand how this interacts with altstacks. Also, there are longjmp()s implemented outside the base, e.g. in the libunwind, which cannot be fixed this way. Also, there are language runtimes that relies heavily on the (synchronous) signals and which use their internal analogues of the stack unwinding, which again be broken by such approach. --cs5saTBZh7UZl2eX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAr4TYACgkQC3+MBN1Mb4hSMgCfdu6eu3supl2hoDArBYfsip62 cXYAniH1jGKsq2Xch31K6Ku1jY1qjzs2 =1k4c -----END PGP SIGNATURE----- --cs5saTBZh7UZl2eX-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 18:51: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 D3B64106566C; Wed, 15 Aug 2012 18:51: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 99F748FC0C; Wed, 15 Aug 2012 18:51:37 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so244381pbb.13 for ; Wed, 15 Aug 2012 11:51: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=AwIaKKBGe7BfyUjLe0efauJoRGd35WVmecz+eWMTvzo=; b=crJLsJcA/nZIfR/b6O2mto3dArLaTLwKAINj+M29WgP0GLT0fWmBnAcYTJz4hQXFw0 R4f34HpRkk4JenykL8roebhBu78RKkiV+qyskk3nJFPcjNoJuirVNAVKgkDIJYBTbhD+ DjNHNP1ZvjP0bHxW7gBL1C4T8e+gPqONCM4iUhIdjDsE90OWT/FUGFfL9tNpooH2BDYW XBRZnSBhAvhTs+jHwLKq4tjWyhXPsKW6ZVQCXpwh4jsRaA7CZ/+PqG1xzK9+6TZOKnZ7 r1NVxgI4QUJj+SojQmFskMmVhxvOK0M2+soUYyy8NT+qqBnDbOIZR5eZF3Aps/vkFsUL x/Aw== MIME-Version: 1.0 Received: by 10.68.238.74 with SMTP id vi10mr6899688pbc.48.1345056696896; Wed, 15 Aug 2012 11:51:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Wed, 15 Aug 2012 11:51:36 -0700 (PDT) In-Reply-To: <20120815160931.GJ5883@deviant.kiev.zoral.com.ua> References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> <5029A9CE.8070307@freebsd.org> <20120814130700.GD5883@deviant.kiev.zoral.com.ua> <502B79F3.2020703@freebsd.org> <502B8029.1010205@freebsd.org> <20120815160931.GJ5883@deviant.kiev.zoral.com.ua> Date: Wed, 15 Aug 2012 11:51:36 -0700 X-Google-Sender-Auth: yvSGqXarNaVa7U_q9I54M6dW2kI Message-ID: From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Dan Plassche Subject: Re: [maybe spam] 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: Wed, 15 Aug 2012 18:51:37 -0000 Holy. Crap. 17 seconds? Can we please go back to having it take this long? please? Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 19:30:14 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 5FA831065672 for ; Wed, 15 Aug 2012 19:30:14 +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 319948FC0A for ; Wed, 15 Aug 2012 19:30:13 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so297877pbb.13 for ; Wed, 15 Aug 2012 12:30:13 -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=wcas9Yr4AsO5VPrH2joJ8ZvHQCfyBPWGNm5KdFpSnXk=; b=Doz4EGzVJyApshHQZskEPYfZeG91QCqR9/Ub8lD5iXaTZY5KPMbHt8HQhE3eDAHQP4 u+lseEmMtj9nPT1wdGts3HhrbdaZmlvJRi3RjuT5yzIn+a1vEVskrHXMXkkjoVjB+a7u DGN2LTZ6b4NDVgW3dXrAzeKTuZNnJecWmXiLPKHZZIJTQm80Kw/8pWZoG4Jdw2Co+gtd qrDwc5smnmcqVriIyb1Hr9gzvPw8Hl46TnlYdg/Q0EKCS6ZA7nf+L9igKkhfyAFb65j/ /THIeJLoG6YRCD0oqRTNkppvRkHR7BGV9dEuBwi9ki5XHe7zdNuGYf0JlW1wIvmVHtYO k4EA== MIME-Version: 1.0 Received: by 10.68.238.74 with SMTP id vi10mr7140552pbc.48.1345059013432; Wed, 15 Aug 2012 12:30:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Wed, 15 Aug 2012 12:30:13 -0700 (PDT) In-Reply-To: <62153.1345056899@critter.freebsd.dk> References: <62153.1345056899@critter.freebsd.dk> Date: Wed, 15 Aug 2012 12:30:13 -0700 X-Google-Sender-Auth: hr1pUsfBJNXF-eF3UgVm5SA-8eE Message-ID: From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Dan Plassche Subject: Re: [maybe spam] 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: Wed, 15 Aug 2012 19:30:14 -0000 On 15 August 2012 11:54, Poul-Henning Kamp wrote: > In message > , Adrian Chadd writes: >>Holy. Crap. 17 seconds? >> >>Can we please go back to having it take this long? please? > > 386BSD was even better, and I have a machine that boots it in less > than 15 seconds from power-on... :-) Embedded systems stuff will love you if we could slim the build and binary/library size down by this much. Sheesh, compilers do a lot of work these days, don't they? Has anyone done a (recent) comparison of execution size/efficiency given the evolution of GCC? Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 19:55: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 E090D106566B for ; Wed, 15 Aug 2012 19:55:25 +0000 (UTC) (envelope-from PMahan@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id B28AC8FC0A for ; Wed, 15 Aug 2012 19:55:25 +0000 (UTC) X-ASG-Debug-ID: 1345059745-027ef7093817140001-P5m3U7 Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id XGbpKOXOH5ZyW8iy for ; Wed, 15 Aug 2012 12:42:25 -0700 (PDT) X-Barracuda-Envelope-From: PMahan@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Wed, 15 Aug 2012 12:42:25 -0700 From: Patrick Mahan X-Barracuda-Apparent-Source-IP: fe80::7042:d8c2:5973:c523 To: "freebsd-hackers@freebsd.org" Date: Wed, 15 Aug 2012 12:42:19 -0700 Thread-Topic: Help with building private .iso media X-ASG-Orig-Subj: Help with building private .iso media Thread-Index: Ac17HhTSwXt6I2ViRQqdpt4jL67+Cg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {BA3FBD50-6B83-4900-99D3-E2C0809C930C} x-cr-hashedpuzzle: FpY= UMg= AE4P CRA5 CT4m DoLs E4V3 FALq FBVI FNsH FqMQ FuJO HJi3 HNnY HrVB JOlH; 1; ZgByAGUAZQBiAHMAZAAtAGgAYQBjAGsAZQByAHMAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {BA3FBD50-6B83-4900-99D3-E2C0809C930C}; cABtAGEAaABhAG4AQABhAGQAYQByAGEAbgBlAHQALgBjAG8AbQA=; Wed, 15 Aug 2012 19:42:19 GMT; SABlAGwAcAAgAHcAaQB0AGgAIABiAHUAaQBsAGQAaQBuAGcAIABwAHIAaQB2AGEAdABlACAALgBpAHMAbwAgAG0AZQBkAGkAYQA= acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1345059745 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi Received-SPF: none (adaranet.com: pmahan@adaranet.com does not designate permitted sender hosts) X-Virus-Scanned: by bsmtpd at adaranet.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.97753 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: KERN-DEV Subject: Help with building private .iso media 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, 15 Aug 2012 19:55:26 -0000 All, Asking this here as I don't see a mailing list specifically devoted to buil= d/release issues and because I think it is a little beyond the standard -question gen= re. Our product here is based on FreeBSD (currently FreeBSD 9/STABLE) and it ha= s reached the stage where we need to create our own .iso/memstick media to handle ins= tallation of our appliances. So yesterday, after perusing release(7), I cranked up /usr/src/release/gene= rate-release.sh and capture the output to see how it was done. And I was successful in get= ting the .iso, memstick and FTP site created. So taking what I learned yesterday, I tried to apply it to our copy of the = FreeBSD source tree. Please note that we use the provided FreeBSD makefiles to build ever= ything we just make heavy use of MAKEOBJDIRPREFIX/OBJTREE/etc environment variables to con= trol where every- thing goes. So today, I tried to build the world package by doing the following at the = top of our FreeBSD source tree (after doing a buildworld) - cd /usr/home/pmahan/work/pm_ipr/ipr/src export MAKEOBJDIRPREFIX=3D/usr/home/pmahan/work/pm_ipr/ipr/amd64/obj sudo -E make TARGET_ARCH=3Damd64 TARGET=3Damd64 distrubteworld DIST=3D/us= r/home/pmahan/work/pm_ipr/ipr/amd64/dist It failed with the following: find //usr/home/pmahan/work/pm_ipr/ipr/amd64/dist/doc -empty -delete find: -delete: //usr/home/pmahan/work/pm_ipr/ipr/amd64/dist/doc: relative p= ath potentially not safe But when I check the logs for yesterday's successful run, I see - find //usr/obj/usr/src/release/dist/doc -empty -delete find //usr/obj/usr/src/release/dist/games -empty -delete find //usr/obj/usr/src/release/dist/lib32 -empty -delete sh /usr/src/release/scripts/mm-mtree.sh -m /usr/src/release/.. -F "TARGET_= ARCH=3Damd64 TARGET=3Damd64" -D "/usr/obj/usr/src/release/dist/base" I read find(1) description about '-delete' and did a quick test that seemed= to prove out that attempting to delete a fully qualified path seems to be a no-no. But = I don't understand why it did not fail yesterday. I suspect it is pilot error, but I am at a = loss to explain why. Any help, steers, slap downs appreciated Thanks, Patrick ---------------------------------------------------- Patrick Mahan Lead Technical Kernel Engineer Adara Networks Disclaimer: The opinions expressed here are solely the responsibility of th= e author and are not to be construed as an official opinion of Adara Networks. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 18:55: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 10647106566B; Wed, 15 Aug 2012 18:55:08 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BEF078FC16; Wed, 15 Aug 2012 18:55:07 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 70B123B761; Wed, 15 Aug 2012 18:55:00 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q7FIsxic062154; Wed, 15 Aug 2012 18:55:00 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 15 Aug 2012 11:51:36 MST." Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 15 Aug 2012 18:54:59 +0000 Message-ID: <62153.1345056899@critter.freebsd.dk> X-Mailman-Approved-At: Wed, 15 Aug 2012 20:14:13 +0000 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Dan Plassche Subject: Re: [maybe spam] 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: Wed, 15 Aug 2012 18:55:08 -0000 In message , Adrian Chadd writes: >Holy. Crap. 17 seconds? > >Can we please go back to having it take this long? please? 386BSD was even better, and I have a machine that boots it in less than 15 seconds from power-on... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 20:19:35 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 D15F31065672; Wed, 15 Aug 2012 20:19:35 +0000 (UTC) (envelope-from yanegomi@gmail.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 772268FC08; Wed, 15 Aug 2012 20:19:35 +0000 (UTC) Received: by yhfs35 with SMTP id s35so2708511yhf.13 for ; Wed, 15 Aug 2012 13:19:34 -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=LyONxe+wB/6Zgfxm0dVMrZA854JMl7eBSM1M/vX4sJU=; b=Ot8j2vBLeeJ/KSdYAHm14eCte1HMfvCO+AYypv8nSI0rEmY6fSpB/xNsaaGMQUhusV tk4uOOaAbLw/V/G1cZ5C9BB3mYQ90GAa/bANRhUlmnPpQueDvyJC/PnB9+oe4tuTOQ/H wYrT7/PighjfXbW4Lgh02QQ5E51k70QdsURLZE+BkGWMot+EiraHIyzCQ67h1NesOvKC zwVMZZ0yJmTpxG+GcwMctc5C3kqbyLGKw1ypuUDrZHkTWP8jroqa2cPjvIF3Bzau20De 2/frPnsEx6qqK8NkW+6c2cRyqtPHhgHgWw3EaMBy5H7SHxLsOzH32Rc6S4S5z1zTkcEw u4Kg== MIME-Version: 1.0 Received: by 10.50.171.100 with SMTP id at4mr12149336igc.47.1345061974528; Wed, 15 Aug 2012 13:19:34 -0700 (PDT) Received: by 10.64.176.200 with HTTP; Wed, 15 Aug 2012 13:19:33 -0700 (PDT) In-Reply-To: References: <62153.1345056899@critter.freebsd.dk> Date: Wed, 15 Aug 2012 13:19:33 -0700 Message-ID: From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Poul-Henning Kamp , Dan Plassche Subject: Re: [maybe spam] 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: Wed, 15 Aug 2012 20:19:35 -0000 On Wed, Aug 15, 2012 at 12:30 PM, Adrian Chadd wrote: > On 15 August 2012 11:54, Poul-Henning Kamp wrote: >> In message >> , Adrian Chadd writes: >>>Holy. Crap. 17 seconds? >>> >>>Can we please go back to having it take this long? please? >> >> 386BSD was even better, and I have a machine that boots it in less >> than 15 seconds from power-on... > > :-) > > Embedded systems stuff will love you if we could slim the build and > binary/library size down by this much. > > Sheesh, compilers do a lot of work these days, don't they? > > Has anyone done a (recent) comparison of execution size/efficiency > given the evolution of GCC? That and (obviously) the FreeBSD source tree has grown.. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 20:19: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 AEFB7106578D for ; Wed, 15 Aug 2012 20:19:49 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 862568FC0C for ; Wed, 15 Aug 2012 20:19:49 +0000 (UTC) Received: from centos62.localhost (bastis [10.3.0.2]) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id q7FKJgQY081799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Aug 2012 13:19:43 -0700 (PDT) (envelope-from mjacob@freebsd.org) Message-ID: <502C045E.7050003@freebsd.org> Date: Wed, 15 Aug 2012 13:19:42 -0700 From: Matthew Jacob Organization: FreeBSD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120717 Thunderbird/10.0.6 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <62153.1345056899@critter.freebsd.dk> In-Reply-To: <62153.1345056899@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.7 (ns1.feral.com [172.16.1.79]); Wed, 15 Aug 2012 13:19:43 -0700 (PDT) Subject: Re: [maybe spam] Re: FreeBSD 1.x Binaries Work Except under Chroot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 20:19:49 -0000 On 08/15/12 11:54, Poul-Henning Kamp wrote: > In message > , Adrian Chadd writes: >> Holy. Crap. 17 seconds? >> >> Can we please go back to having it take this long? please? > 386BSD was even better, and I have a machine that boots it in less > than 15 seconds from power-on... > A Sun 3-50 with a 15.7MHz 68020 and 4MB running diskless was about the same booting. And when you opened mailtool, you were reading the latest in less than a second. In exchange for having a graphic that can resize itself to be readable, supposedly, from a 4 line LED screen to a wall TV, you have mail user agents that will let you read mail in a couple of seconds, but only after 30 seconds of filling 100MB of memory with cached pages. Hmm. Progress! From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 21:32: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 9E8BC106566B; Wed, 15 Aug 2012 21:32:05 +0000 (UTC) (envelope-from dplassche@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 016168FC15; Wed, 15 Aug 2012 21:32:04 +0000 (UTC) Received: by weyx56 with SMTP id x56so1621186wey.13 for ; Wed, 15 Aug 2012 14:32:04 -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=rVB5uSE5OnkWpXiQ+CC5psLvrvY16fhE2OBVD7vPZng=; b=y1FJs3I4+AigHkUWhM49elONYjQVzSKiwLCjlKAZh3hRH3/cDJBBR0ZDAhgNvv5rOO ylPvqCouCcsV09PeDzHNRyM4cbRmGDhyutmlKmEeK9SM1gCg8HYUvDKZbuPdekGxrcNp 7Klr4qp6LKNT04BJjWonjEFpXLmFXDd/VBtCWN/qNJxdgESeM2FiNu8LilGWJu/0d/H1 /asYuYTcmmpUtrQjqF59PAOU36DPusPuVWInq5V4G8zKp+W7ahtZhmBCnX0SC5gl79bs tE6AESn+L+pGC/xlxGszSQcdo8uMaWmn9PrHHc14fCOiGNg9Mzy4Tc/XU6B4w2bfws1T QdTw== MIME-Version: 1.0 Received: by 10.216.29.10 with SMTP id h10mr10930232wea.126.1345066324087; Wed, 15 Aug 2012 14:32:04 -0700 (PDT) Received: by 10.223.158.7 with HTTP; Wed, 15 Aug 2012 14:32:03 -0700 (PDT) In-Reply-To: <5029A9CE.8070307@freebsd.org> References: <20120810170715.GI2425@deviant.kiev.zoral.com.ua> <20120811184522.GK2425@deviant.kiev.zoral.com.ua> <5029A9CE.8070307@freebsd.org> Date: Wed, 15 Aug 2012 17:32:03 -0400 Message-ID: From: Dan Plassche To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 15 Aug 2012 22:27:06 +0000 Cc: Konstantin Belousov , 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: Wed, 15 Aug 2012 21:32:05 -0000 On Mon, Aug 13, 2012 at 9:28 PM, Julian Elischer wrote: > you will also have to change PID_MAX (spelling?) to be 60000 > I have considered making this a tunable.. > If you don't then the shell in the 1.1.5.1 environment will not be able to > handle when a child > get s a pid of > 16 bits and it will not be able to wait on it. so it will > suspend for ever. > teh result is that you can not complete a "make world". The shell hangs as you described on "make world" when the PID hits 32768. Looks like this was the old limit and things changed around release 3. I went to recompile the kernel with "define PID_MAX 30000" in /usr/src/sys/sys/proc.h and got a new build error that I'm still trying to resolve: In file included from /usr/src/sys/sys/buf.h:258, from /usr/src/sys/i386/i386/genassym.c:47: /usr/src/sys/sys/proc.h:670: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PID_MAX' /usr/src/sys/sys/proc.h:769: warning data definition has no type or storage class /usr/src/sys/sys/proc.h:769: warning: type defaults to 'int' in declaration of 'pidhashtbl' *** Error code 1 Line 670 in proc.h is the define PID_MAX line. I have the feeling I may be missing something obvious here, but I haven't been able to sort out the problem. Dan From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 15 23:57: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 85299106566B; Wed, 15 Aug 2012 23:57:48 +0000 (UTC) (envelope-from listlog2011@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 482178FC08; Wed, 15 Aug 2012 23:57:47 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so643339pbb.13 for ; Wed, 15 Aug 2012 16:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xMSaRK81zGT+Sr8B9UNjBAZ3IJT08cA3n+PIizpJ3iQ=; b=E8A28oiQwyhuYWrKC8O/McU6PusUPQdK0Rqy6BOvX/o6xQe5lP49gLcl/+69Q6JpdU BdDjpZJIzmFM/4bMbc//xTU1gS36yx8cVkOV2WoSiir1FtkAH6LYhWyAlZuE5Okybdqt DctPE54T49iNH4WXaqCc7Yo3OraHgx5InlbaTO1/Puil2mAJtMHgMn01s/9nue0hsxKY B2EWAloIFeAj7tSB8miAj0bczaSlcy3hKlO0IYZ8QKND8iH4qFGkHHikCiSz47DCYHCE I0h0UXEFWtgkcQPAiSSEFe0Nd/FKTGchg1r6swqlY5Eo1F+/KlGXmY+xQlNit4p/WY3H vRSg== Received: by 10.68.132.194 with SMTP id ow2mr15325323pbb.36.1345075067088; Wed, 15 Aug 2012 16:57:47 -0700 (PDT) Received: from xp5k.my.domain ([115.192.132.92]) by mx.google.com with ESMTPS id rd7sm1349233pbc.70.2012.08.15.16.57.43 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 16:57:46 -0700 (PDT) Message-ID: <502C3775.8090401@gmail.com> Date: Thu, 16 Aug 2012 07:57:41 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com> <20120815174609.GM5883@deviant.kiev.zoral.com.ua> In-Reply-To: <20120815174609.GM5883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, Jilles Tjoelker Subject: Re: system() using vfork() or posix_spawn() and libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 23:57:48 -0000 On 2012/08/16 01:46, Konstantin Belousov wrote: > On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: >> You are requiring the thread library to implement such a mutex >> and other locks, that after vfork(), the mutex and other lock types must >> still work across processes, the PTHREAD_PROCESS_PRIVATE type of >> mutex and other locks now need to work in a PTHREAD_PROCESS_SHARE >> mode. > In fact, yes. In my patch I achieve this by single-threading the parent, I still think single-threading is execussive, vfork should be fast, and because parent thread is already waiting for child process, there is no problem to reuse the parent's stack in child process, it is compatible. > which means that existing _PRIVATE mutexes are enough. Well, you forget that if private mutex sleep-wakeup queue is in kernel, you only can see it in same process, otherwise it is a security problem. Now It works because it is me implementing umtx in such a way that it comparings two vmspace pointers in kernel umtx code, and treat two threads are in same process if they are same. But there are implementations do not work in this way, they simply look up lwpid in same process, and if not found, the mutex is broken. process-private and proecess-shared locks work in very different way, then your assumptions is false. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 00:07:03 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 DD21F106564A; Thu, 16 Aug 2012 00:07:03 +0000 (UTC) (envelope-from listlog2011@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 A08698FC08; Thu, 16 Aug 2012 00:07:03 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so654676pbb.13 for ; Wed, 15 Aug 2012 17:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pgKLO3AyRrEwqG/8FRVfzd+0zLzbQDgUydbOcb2Kaig=; b=wYwAE8GeV2iLMi/XtTmj76LnxmKN8KcolHQieSAAxI+rJzpVs8lZ5K7hR5L+Pt32U+ g0DP+w3K7Aqzx+A3k1ed0Um1dIrOcbBPm0fxjJOdXKnq35mQkBuTcewsSufxGqVsi1nM XUKX47vdeDC7/7EpznrabeP2I8X5AtBb/MUE8popXieUU3yBTOItumsdipMCQ+LvtkU1 93VFxcbWfnrp6zb96Jh7lyg/s4Pq6Y0HbytrP7LVxl6/hT4Ls1V7IhAOy4+OVFC2mbix 5PK76FzK7rk/oik//tSxefVGO8eQgdGHHg5x/adADmepNgER3tkA1SuuhQSGaNkBMzz+ rzRw== Received: by 10.68.213.97 with SMTP id nr1mr25469338pbc.105.1345075623103; Wed, 15 Aug 2012 17:07:03 -0700 (PDT) Received: from xp5k.my.domain ([115.192.132.92]) by mx.google.com with ESMTPS id pa6sm1373665pbc.47.2012.08.15.17.07.00 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 17:07:02 -0700 (PDT) Message-ID: <502C39A2.7010608@gmail.com> Date: Thu, 16 Aug 2012 08:06:58 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: davidxu@freebsd.org References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <20120814094111.GB5883@deviant.kiev.zoral.com.ua> <502A6B7A.6070504@gmail.com> <20120815174609.GM5883@deviant.kiev.zoral.com.ua> <502C3775.8090401@gmail.com> In-Reply-To: <502C3775.8090401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: system() using vfork() or posix_spawn() and libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 00:07:03 -0000 On 2012/08/16 07:57, David Xu wrote: > On 2012/08/16 01:46, Konstantin Belousov wrote: >> On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: >>> You are requiring the thread library to implement such a mutex >>> and other locks, that after vfork(), the mutex and other lock types >>> must >>> still work across processes, the PTHREAD_PROCESS_PRIVATE type of >>> mutex and other locks now need to work in a PTHREAD_PROCESS_SHARE >>> mode. >> In fact, yes. In my patch I achieve this by single-threading the parent, > I still think single-threading is execussive, vfork should be fast, and > because parent thread is already waiting for child process, there > is no problem to reuse the parent's stack in child process, it is > compatible. >> which means that existing _PRIVATE mutexes are enough. > > Well, you forget that if private mutex sleep-wakeup queue is in kernel, > you only can see it in same process, otherwise it is a security problem. > Now It works because it is me implementing umtx in such a way that it > comparings two vmspace pointers in kernel umtx code, and treat two > threads are in same process if they are same. But there are > implementations > do not work in this way, they simply look up lwpid in same process, > and if > not found, the mutex is broken. process-private and proecess-shared locks > work in very different way, then your assumptions is false. > I must say my implementation is a lucky, not is the intention. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 00:23:44 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 E4657106566B; Thu, 16 Aug 2012 00:23:44 +0000 (UTC) (envelope-from listlog2011@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 A78378FC15; Thu, 16 Aug 2012 00:23:44 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so675330pbb.13 for ; Wed, 15 Aug 2012 17:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Bb0uX69VN02yAN+dB2JbIWfko2eTiLqbMn5gY66evbE=; b=N1lyIYW2uO21Nz96WDwG3HPJgg7fJLlA6PzR1KZG0gd33ZqGI1Xybw4NT0rN/p+dfi drNEvxPeY/x80LTTrRK7+0NeTT1ENABfxPmHM2apGNt1EyJyrdazLGCXelM9rnC0k/LV 0QT06NSKYzXIbRfI6hGiFW+1WW1h1/Yuycir/SuvsnmEfVjZCDCeXpIGncmU9I+CFC9N 0Gb24aG/er233yfFdKKsxp2pe2/e+Dq4nI6QaPUI9OHCH0rQiqfY4aPJcJhb7IJXGDLN 74xFseh+NsNcfMuox0BYfqkYOdGr/A+lVcvTnz2UZrS8q282wgJEWMfQ1HKAQOeyyVpM oA3A== Received: by 10.68.220.201 with SMTP id py9mr16998785pbc.137.1345076624108; Wed, 15 Aug 2012 17:23:44 -0700 (PDT) Received: from xp5k.my.domain ([115.192.132.92]) by mx.google.com with ESMTPS id wf7sm1403009pbc.34.2012.08.15.17.23.41 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 17:23:43 -0700 (PDT) Message-ID: <502C3D8B.4060008@gmail.com> Date: Thu, 16 Aug 2012 08:23:39 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120808 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <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> In-Reply-To: <20120815174942.GN5883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org, Jilles Tjoelker Subject: Re: system() using vfork() or posix_spawn() and libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 00:23:45 -0000 On 2012/08/16 01:49, Konstantin Belousov wrote: > On Wed, Aug 15, 2012 at 07:40:04AM +0800, David Xu wrote: >> On 2012/08/15 05:09, Jilles Tjoelker wrote: >>> On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: >>>> But in real word, pthread atfork handlers are not async-signal safe, >>>> they mostly do mutex locking and unlocking to keep consistent state, >>>> mutex is not async-signal safe. >>>> The malloc prefork and postfork handlers happen to work because I have >>>> some hacking code in library for malloc locks. Otherwise, you even >>>> can not use fork() in signal handler. >>> This problem was also reported to the Austin Group at >>> http://austingroupbugs.net/view.php?id=62 >>> >>> Atfork handlers are inherently async-signal-unsafe. >>> >>> An interpretation was issued suggesting to remove fork() from the list >>> of async-signal-safe functions and add a new async-signal-safe function >>> _Fork() which does not call the atfork handlers. >>> >>> This change will however not be in POSIX.1-2008 TC1 but only in the next >>> issue (SUSv5). >>> >>> A slightly earlier report http://austingroupbugs.net/view.php?id=18 just >>> requested the _Fork() function because an existing application >>> deadlocked when calling fork() from a signal handler. >>> >> Thanks, although SUSv5 will have _Fork(), but application will not catch up. >> >> One solution for this problem is thread library does not execute >> atfork handler when fork() is called from signal handler, but it >> requires some work to be done in thread library's signal wrapper, >> for example, set a flag that the thread is executing signal handler, >> but siglongjmp can mess the flag, so I have to tweak sigsetjmp and >> siglongjmp to save/restore the flag, I have such a patch: it fetches >> target stack pointer stored in jmpbuf, and compare it with top most >> stack pointer when a first signal was delivered to the thread, if the >> target stack pointer is larger than the top most stack pointer, the >> flag is cleared. >> > I do not understand how this interacts with altstacks. > > Also, there are longjmp()s implemented outside the base, e.g. in the > libunwind, which cannot be fixed this way. > > Also, there are language runtimes that relies heavily on the (synchronous) > signals and which use their internal analogues of the stack unwinding, > which again be broken by such approach. My patch is very experimental. There are setcontext and getcontext which also can break it. Another solution would save a flag into jmpbuf or ucontext, and indicates the signal handler is executing. a setjmp or getcontext executed in normal context would not have such a flag, but if they executes in signal handler, the per-thread flag will be saved. but it requires lots of changes, and setcontext and getcontext are syscall, kernel does know such a userland flag, unless they are shared between kernel and userland. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 07:06: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 C7600106566B; Thu, 16 Aug 2012 07:06:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 6B62E8FC0C; Thu, 16 Aug 2012 07:06:49 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1T1uAI-0008mU-OK; Thu, 16 Aug 2012 10:06:47 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: John Baldwin In-reply-to: <201208151116.21461.jhb@freebsd.org> References: <201208151116.21461.jhb@freebsd.org> Comments: In-reply-to John Baldwin message dated "Wed, 15 Aug 2012 11:16:21 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Aug 2012 10:06:46 +0300 From: Daniel Braniss Message-ID: Cc: Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: GPT boot from 2nd. disk fails 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, 16 Aug 2012 07:06:49 -0000 > On Wednesday, August 15, 2012 4:46:28 am Garrett Cooper wrote: > > On Wed, Aug 15, 2012 at 1:27 AM, Daniel Braniss wrote: > > > hi, > > > this host has to disks: > > > sa0> gpart show > > > => 34 976773101 ada0 GPT (465G) > > > 34 128 1 freebsd-boot (64k) > > > 162 4194304 2 freebsd-ufs (2.0G) > > > 4194466 33554432 3 freebsd-swap (16G) > > > 37748898 939024237 4 freebsd-zfs (447G) > > > > > > => 34 976773101 ada1 GPT (465G) > > > 34 128 1 freebsd-boot (64k) > > > 162 4194304 2 freebsd-ufs [bootme] (2.0G) > > > 4194466 8388608 3 freebsd-swap (4.0G) > > > 12583074 964190061 4 freebsd-zfs (459G) > > > > > > but no amount of magic will cause boot from the second disk, it will > always > > > boot from the first disk. > > > > > > any insights? > > > > Use boot0cfg -s 5 (untested with GPT disks)? > > Will not work with GPT disks. They use /boot/pmbr to boot, not /boot/boot0. > > If you can get your BIOS to explicitly boot ada1 from the start via a BIOS > setting, that should work. Another option would be to break into gptboot's > prompt (similar to breaking into boot2) aud typing in 'ad1p2:/boot/loader' or > some such. If that works you should even be able to write that to > /boot.config on ada0p2's filesystem. sorry, as usual my questions are a bit terse :-), I want to switch between roots either at boot time (this is very tricky now, since breaking into boot2 needs very fast fingers) or before reboot. btw, it's 1:ad(0p2)/boot/loader also, since the disks are hot swap, i can switch between them, but I realy want to do it via software! the bootme trick did work, on a different host/setup and sometime ago. before GPT, when we had MBR, I could switch between slices/partitions either via the menu or via boot0cfg, so maybe I should go back to mbr. Cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 08:39:50 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 54A521065672 for ; Thu, 16 Aug 2012 08:39:50 +0000 (UTC) (envelope-from phk@freebsd.org) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 10D838FC0A for ; Thu, 16 Aug 2012 08:39:49 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B3C433B761; Thu, 16 Aug 2012 08:39:48 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q7G8dmmZ068637; Thu, 16 Aug 2012 08:39:48 GMT (envelope-from phk@freebsd.org) To: Lars Engels From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 16 Aug 2012 10:13:36 +0200." <20120816081336.GB27128@e-new.0x20.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 16 Aug 2012 08:39:48 +0000 Message-ID: <68636.1345106388@critter.freebsd.dk> Cc: freebsd-hackers@freebsd.org Subject: Re: [maybe spam] 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: Thu, 16 Aug 2012 08:39:50 -0000 In message <20120816081336.GB27128@e-new.0x20.net>, Lars Engels writes: >> 386BSD was even better, and I have a machine that boots it in less >> than 15 seconds from power-on... > >Me too, it's running Linux. ;-) You should upgrade the OS then... :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 09:13:44 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 D721F106566B; Thu, 16 Aug 2012 09:13:44 +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 6917F8FC08; Thu, 16 Aug 2012 09:13:44 +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 q7G9Da5h046490; Thu, 16 Aug 2012 11:13:37 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q7G9DaJK046489; Thu, 16 Aug 2012 11:13:36 +0200 (CEST) (envelope-from marius) Date: Thu, 16 Aug 2012 11:13:36 +0200 From: Marius Strobl To: Adrian Chadd Message-ID: <20120816091336.GA28757@alchemy.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: David Duchscher , Marius Strobl , hackers@freebsd.org Subject: Re: Disabling ethernet link on an Intel nic? 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, 16 Aug 2012 09:13:44 -0000 On Mon, Aug 13, 2012 at 01:47:01PM -0700, Adrian Chadd wrote: > Hi, > > On 11 August 2012 06:35, David Duchscher wrote: > > Greetings, > > > > I have a need to turn off the link of an ethernet port on a Intel nic. The issue is not a big deal but one we would like to solve. we have no way of signaling an upstream router that a path is down but via turning off the link of the ethernet port. This would only be used when something goes wrong. The hope is that we could automate some problems and handle other situations remotely avoiding having to visit the system in person. > > > > Any thoughts? We can modify the system so if it means modifying the driver or some other code, I am willing to try. Just need a little direction. > > Marius talked about doing this. Maybe it's time we added it as a > device option, so people can have the PHY disabled when the NIC is > brought down? > I'm working on adding support to mii(4) for powering down PHYs when the network interface is down, but as you have noticed this non- trivial to get right, i.e. so they actually come out of power down mode again when bringing up the interface regardless of the media options used. We also clearly need a way to disable this behavior for the known-broken PHYs. This is orthogonal to the 1 and 10 Gigabit Intel Ethernet drivers so as these don't take advantage of mii(4). Some time ago someone posted patches to net@ implementing/activating powering down the PHYs when these interfaces are down though. Marius From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 09:47:01 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 55A58106566C; Thu, 16 Aug 2012 09:47:01 +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 E252B8FC0A; Thu, 16 Aug 2012 09:47:00 +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 q7G9kl4V087203; Thu, 16 Aug 2012 10:46:47 +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: <20120816091336.GA28757@alchemy.franken.de> Date: Thu, 16 Aug 2012 10:46:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4A66D60B-5824-423B-906C-309A1F925E95@gid.co.uk> References: <20120816091336.GA28757@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1278) Cc: David Duchscher , Adrian Chadd , hackers@freebsd.org, Marius Strobl Subject: Re: Disabling ethernet link on an Intel nic? 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, 16 Aug 2012 09:47:01 -0000 Hi, On 16 Aug 2012, at 10:13, Marius Strobl wrote: > I'm working on adding support to mii(4) for powering down PHYs when > the network interface is down, but as you have noticed this non- > trivial to get right, i.e. so they actually come out of power down > mode again when bringing up the interface regardless of the media > options used. We also clearly need a way to disable this behavior > for the known-broken PHYs. Please be very careful in case the PHY is carrying a piggy-backed IPMI = NIC too. > This is orthogonal to the 1 and 10 Gigabit Intel Ethernet drivers > so as these don't take advantage of mii(4). Some time ago someone > posted patches to net@ implementing/activating powering down the > PHYs when these interfaces are down though. >=20 > Marius -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 11:15:47 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 6DD9F106566C for ; Thu, 16 Aug 2012 11:15:47 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC60F8FC16 for ; Thu, 16 Aug 2012 11:15:46 +0000 (UTC) Received: by lbbgk8 with SMTP id gk8so1690963lbb.13 for ; Thu, 16 Aug 2012 04:15:45 -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=nPGmRbpfJx0n9ASZwblPfE+EtWv8HlNYSlXLn3Ck7Gw=; b=ZJY7x89H0cyuISpAm4lLh91y3nyF/vheM8BN9LUq4AYlT0KDNOkxdbUW7x5MRPddWE t8TWFhvntePDkl7AVGhGVNhBCqp1s2FbGwobtiiToAsdV2pklp5j9gFB1Lc6avMEGul5 aRYrAyia37TD6flCHFDR1mYRrShMm9pv4+VZqgW5vabL6prxOmJ/w1weyLoc66bp/c6z ak/3+8HjyYCrX1VESbKTfZPxKuG4nrvYyhV7rwAFPwkF1Z+ESctYkvw8CtKZpXkzikXl FEfs6+DgAlrr2qUGd7iUShZemnwFrKigc9fl+z8vra8vKyS/N5br8AbN1jhPQUu2LgMx Gg0w== Received: by 10.152.46.49 with SMTP id s17mr901856lam.17.1345115745176; Thu, 16 Aug 2012 04:15:45 -0700 (PDT) Received: from dhcp170-234-red.yandex.net (dhcp170-234-red.yandex.net. [95.108.170.234]) by mx.google.com with ESMTPS id n7sm976888lbk.10.2012.08.16.04.15.44 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 04:15:44 -0700 (PDT) Message-ID: <502CD65E.4010900@zonov.org> Date: Thu, 16 Aug 2012 15:15:42 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Daniel Braniss References: <201208151116.21461.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnmQdnhT9Sbbh1Sns3/4q/UHH8uNbyMYURBEsnprSdZ6dKyGDZ5PbZmGdErYXDazVKpcWtt Cc: Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: GPT boot from 2nd. disk fails 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, 16 Aug 2012 11:15:47 -0000 On 8/16/12 11:06 AM, Daniel Braniss wrote: >> On Wednesday, August 15, 2012 4:46:28 am Garrett Cooper wrote: >>> On Wed, Aug 15, 2012 at 1:27 AM, Daniel Braniss wrote: >>>> hi, >>>> this host has to disks: >>>> sa0> gpart show >>>> => 34 976773101 ada0 GPT (465G) >>>> 34 128 1 freebsd-boot (64k) >>>> 162 4194304 2 freebsd-ufs (2.0G) >>>> 4194466 33554432 3 freebsd-swap (16G) >>>> 37748898 939024237 4 freebsd-zfs (447G) >>>> >>>> => 34 976773101 ada1 GPT (465G) >>>> 34 128 1 freebsd-boot (64k) >>>> 162 4194304 2 freebsd-ufs [bootme] (2.0G) >>>> 4194466 8388608 3 freebsd-swap (4.0G) >>>> 12583074 964190061 4 freebsd-zfs (459G) >>>> >>>> but no amount of magic will cause boot from the second disk, it will >> always >>>> boot from the first disk. >>>> >>>> any insights? >>> >>> Use boot0cfg -s 5 (untested with GPT disks)? >> >> Will not work with GPT disks. They use /boot/pmbr to boot, not /boot/boot0. >> >> If you can get your BIOS to explicitly boot ada1 from the start via a BIOS >> setting, that should work. Another option would be to break into gptboot's >> prompt (similar to breaking into boot2) aud typing in 'ad1p2:/boot/loader' or >> some such. If that works you should even be able to write that to >> /boot.config on ada0p2's filesystem. > > sorry, as usual my questions are a bit terse :-), > I want to switch between roots either at boot time (this is very tricky now, > since breaking into boot2 needs very fast fingers) or before reboot. > btw, it's 1:ad(0p2)/boot/loader > also, since the disks are hot swap, i can switch between them, but I realy > want to do it via software! > > the bootme trick did work, on a different host/setup and sometime ago. > > before GPT, when we had MBR, I could switch between slices/partitions either > via the menu or via boot0cfg, so maybe I should go back to mbr. > You can erase boot record of the first disk, then your BIOS will try to use second one. Be careful, some BIOS'es try only first disk. -- Andrey Zonov From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 08:13: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 D8748106566C for ; Thu, 16 Aug 2012 08:13:37 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9090C8FC0C for ; Thu, 16 Aug 2012 08:13:37 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id CD7C06A6001; Thu, 16 Aug 2012 10:13:36 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id q7G8DaZ5094736; Thu, 16 Aug 2012 10:13:36 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id q7G8DagD094314; Thu, 16 Aug 2012 10:13:36 +0200 (CEST) (envelope-from lars) Date: Thu, 16 Aug 2012 10:13:36 +0200 From: Lars Engels To: Poul-Henning Kamp Message-ID: <20120816081336.GB27128@e-new.0x20.net> References: <62153.1345056899@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <62153.1345056899@critter.freebsd.dk> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p2 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 16 Aug 2012 11:28:42 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: [maybe spam] 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: Thu, 16 Aug 2012 08:13:38 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 15, 2012 at 06:54:59PM +0000, Poul-Henning Kamp wrote: > In message > , Adrian Chadd writes: > >Holy. Crap. 17 seconds? > > > >Can we please go back to having it take this long? please? >=20 > 386BSD was even better, and I have a machine that boots it in less > than 15 seconds from power-on... Me too, it's running Linux. ;-) --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAsq7AACgkQKc512sD3afiYiQCgrMQmKcPMirCfPA100LPY00Cx Zl4AoLI9E8Qfv5oNBLlrGSCEAClkVsM+ =xS9G -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 11:44: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 8E2F9106564A; Thu, 16 Aug 2012 11:44:32 +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 0CA8B8FC17; Thu, 16 Aug 2012 11:44:31 +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 q7GBidri095603; Thu, 16 Aug 2012 14:44:39 +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 q7GBiRw4031637; Thu, 16 Aug 2012 14:44:27 +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 q7GBiQpw031636; Thu, 16 Aug 2012 14:44:26 +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, 16 Aug 2012 14:44:26 +0300 From: Konstantin Belousov To: davidxu@freebsd.org Message-ID: <20120816114426.GR5883@deviant.kiev.zoral.com.ua> References: <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8Bx+wEju+vH9ym24" Content-Disposition: inline In-Reply-To: <502C3D8B.4060008@gmail.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: freebsd-hackers@freebsd.org, Jilles Tjoelker 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: Thu, 16 Aug 2012 11:44:32 -0000 --8Bx+wEju+vH9ym24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 16, 2012 at 08:23:39AM +0800, David Xu wrote: > On 2012/08/16 01:49, Konstantin Belousov wrote: > >On Wed, Aug 15, 2012 at 07:40:04AM +0800, David Xu wrote: > >>On 2012/08/15 05:09, Jilles Tjoelker wrote: > >>>On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: > >>>>But in real word, pthread atfork handlers are not async-signal safe, > >>>>they mostly do mutex locking and unlocking to keep consistent state, > >>>>mutex is not async-signal safe. > >>>>The malloc prefork and postfork handlers happen to work because I have > >>>>some hacking code in library for malloc locks. Otherwise, you even > >>>>can not use fork() in signal handler. > >>>This problem was also reported to the Austin Group at > >>>http://austingroupbugs.net/view.php?id=3D62 > >>> > >>>Atfork handlers are inherently async-signal-unsafe. > >>> > >>>An interpretation was issued suggesting to remove fork() from the list > >>>of async-signal-safe functions and add a new async-signal-safe function > >>>_Fork() which does not call the atfork handlers. > >>> > >>>This change will however not be in POSIX.1-2008 TC1 but only in the ne= xt > >>>issue (SUSv5). > >>> > >>>A slightly earlier report http://austingroupbugs.net/view.php?id=3D18 = just > >>>requested the _Fork() function because an existing application > >>>deadlocked when calling fork() from a signal handler. > >>> > >>Thanks, although SUSv5 will have _Fork(), but application will not catc= h=20 > >>up. > >> > >>One solution for this problem is thread library does not execute > >>atfork handler when fork() is called from signal handler, but it > >>requires some work to be done in thread library's signal wrapper, > >>for example, set a flag that the thread is executing signal handler, > >>but siglongjmp can mess the flag, so I have to tweak sigsetjmp and > >>siglongjmp to save/restore the flag, I have such a patch: it fetches > >>target stack pointer stored in jmpbuf, and compare it with top most > >>stack pointer when a first signal was delivered to the thread, if the > >>target stack pointer is larger than the top most stack pointer, the > >>flag is cleared. > >> > >I do not understand how this interacts with altstacks. > > > >Also, there are longjmp()s implemented outside the base, e.g. in the > >libunwind, which cannot be fixed this way. > > > >Also, there are language runtimes that relies heavily on the (synchronou= s) > >signals and which use their internal analogues of the stack unwinding, > >which again be broken by such approach. > My patch is very experimental. There are setcontext and getcontext > which also can break it. Another solution would save a flag into > jmpbuf or ucontext, and indicates the signal handler is executing. > a setjmp or getcontext executed in normal context would not > have such a flag, but if they executes in signal handler, the per-thread > flag will be saved. but it requires lots of changes, and setcontext and > getcontext are syscall, kernel does know such a userland flag, unless > they are shared between kernel and userland. >=20 My point is that the fact that fork() is called from dynamic context that was identified as the signal handler does not mean anything. It can be mis-identified for many reasons, which both me and you tried to partially enumerate above. The really important thing is the atomicity of the current context, e.g. synchronous SIGSEGV caused by a language runtime GC is very much safe place to call atfork handlers, since runtimes usually cause signal generations only at the safe place. I do not think that such approach as you described can be completed, the _Fork() seems the only robust way. BTW, returning to Jilles proposal, can we call vfork() only for single-threaded parent ? I think it gives good boost for single-threaded case, and also eliminates the concerns of non-safety. --8Bx+wEju+vH9ym24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAs3RoACgkQC3+MBN1Mb4jIzwCgusnKixcw5EdhopIt8hMszX4L KqsAoOpTByxsSGt7rQ5CkbGLz8eKHnx8 =74GS -----END PGP SIGNATURE----- --8Bx+wEju+vH9ym24-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 12:03:27 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 3CD10106566C for ; Thu, 16 Aug 2012 12:03:27 +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 8AEE78FC12 for ; Thu, 16 Aug 2012 12:03:26 +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 q7GC3NKI002054 for ; Thu, 16 Aug 2012 14:03:23 +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 q7GC3NB9002051 for ; Thu, 16 Aug 2012 14:03:23 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 16 Aug 2012 14:03:23 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 16 Aug 2012 14:03:23 +0200 (CEST) Subject: any status of that project? 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, 16 Aug 2012 12:03:27 -0000 http://freebsdfoundation.blogspot.com/2012/03/new-project-nand-flash-support.html this would be great thing to have it working properly. any progress info? From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 13:02: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 9463B106566B for ; Thu, 16 Aug 2012 13:02:46 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 489528FC14 for ; Thu, 16 Aug 2012 13:02:46 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 2D741C4D87; Thu, 16 Aug 2012 15:02:45 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id x8ePYDG8gWrj; Thu, 16 Aug 2012 15:02:44 +0200 (CEST) Received: from [10.0.0.22] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 8759DC4D63; Thu, 16 Aug 2012 15:02:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: Date: Thu, 16 Aug 2012 15:02:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Puchar X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Re: any status of that project? 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, 16 Aug 2012 13:02:46 -0000 On 2012-08-16, at 14:03, Wojciech Puchar wrote: > = http://freebsdfoundation.blogspot.com/2012/03/new-project-nand-flash-suppo= rt.html >=20 > this would be great thing to have it working properly. any progress = info? FYI: the code was merged w/ HEAD some time ago. See = http://svnweb.freebsd.org/base?view=3Drevision&revision=3D235537 and = follow up commits. Rafal From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 13:06: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 7425C106566C; Thu, 16 Aug 2012 13:06:40 +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 0AD988FC22; Thu, 16 Aug 2012 13:06:39 +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 q7GD6cRR002638; Thu, 16 Aug 2012 16:06:38 +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 q7GD6P7Z032355; Thu, 16 Aug 2012 16:06:25 +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 q7GD6Pm6032354; Thu, 16 Aug 2012 16:06:25 +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, 16 Aug 2012 16:06:25 +0300 From: Konstantin Belousov To: Dan Plassche Message-ID: <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cUjMc5fB5G+GsIM6" 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 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: Thu, 16 Aug 2012 13:06:40 -0000 --cUjMc5fB5G+GsIM6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 15, 2012 at 05:32:03PM -0400, Dan Plassche wrote: > On Mon, Aug 13, 2012 at 9:28 PM, Julian Elischer > wrote: >=20 > > you will also have to change PID_MAX (spelling?) to be 60000 > > I have considered making this a tunable.. > > If you don't then the shell in the 1.1.5.1 environment will not be able= to > > handle when a child > > get s a pid of > 16 bits and it will not be able to wait on it. so it w= ill > > suspend for ever. > > teh result is that you can not complete a "make world". >=20 > The shell hangs as you described on "make world" when the PID > hits 32768. Looks like this was the old limit and things changed > around release 3. >=20 > I went to recompile the kernel with "define PID_MAX 30000" in > /usr/src/sys/sys/proc.h and got a new build error that I'm still > trying to resolve: >=20 > In file included from /usr/src/sys/sys/buf.h:258, > from /usr/src/sys/i386/i386/genassym.c:47: >=20 > /usr/src/sys/sys/proc.h:670: error: expected '=3D', ',', ';', > 'asm' or '__attribute__' before 'PID_MAX' >=20 > /usr/src/sys/sys/proc.h:769: warning data definition has no > type or storage class >=20 > /usr/src/sys/sys/proc.h:769: warning: type defaults to 'int' > in declaration of 'pidhashtbl' >=20 > *** Error code 1 >=20 > Line 670 in proc.h is the define PID_MAX line. I have the > feeling I may be missing something obvious here, but I haven't > been able to sort out the problem. 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. --cUjMc5fB5G+GsIM6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAs8FEACgkQC3+MBN1Mb4iANgCgtMMuFMTrLXP5bRUdzip431Mg qXoAn287jmSfHLrnCCwquvER7pD5G9WS =XjKg -----END PGP SIGNATURE----- --cUjMc5fB5G+GsIM6-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 13:16:20 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 7E13D106564A for ; Thu, 16 Aug 2012 13:16:20 +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 882038FC08 for ; Thu, 16 Aug 2012 13:16:19 +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 q7GDGG8B067099; Thu, 16 Aug 2012 15:16:17 +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 q7GDGGk6067049; Thu, 16 Aug 2012 15:16:16 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 16 Aug 2012 15:16:16 +0200 (CEST) From: Wojciech Puchar To: Rafal Jaworowski In-Reply-To: Message-ID: References: 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]); Thu, 16 Aug 2012 15:16:17 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: any status of that project? 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, 16 Aug 2012 13:16:20 -0000 thank you. > > On 2012-08-16, at 14:03, Wojciech Puchar wrote: > >> http://freebsdfoundation.blogspot.com/2012/03/new-project-nand-flash-support.html >> >> this would be great thing to have it working properly. any progress info? > > FYI: the code was merged w/ HEAD some time ago. See http://svnweb.freebsd.org/base?view=revision&revision=235537 and follow up commits. > > Rafal > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 13:37:56 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 C46DC106564A for ; Thu, 16 Aug 2012 13:37:56 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8179E8FC15 for ; Thu, 16 Aug 2012 13:37:56 +0000 (UTC) Received: from nis-128-194-60-144.dhcp.tamu.edu (nis-128-194-60-144.dhcp.tamu.edu [128.194.60.144]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7GDbtwf035145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Aug 2012 08:37:55 -0500 (CDT) (envelope-from daved@tamu.edu) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_A91C3812-AF82-4830-AAAC-9A3C77211A2C"; protocol="application/pkcs7-signature"; micalg=sha1 From: Dave Duchscher In-Reply-To: <5029ED51.9000600@rdtc.ru> Date: Thu, 16 Aug 2012 08:37:49 -0500 Message-Id: References: <5029ED51.9000600@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1278) Received-SPF: pass (nostrum.com: 128.194.60.144 is authenticated by a trusted mechanism) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: Disabling ethernet link on an Intel nic? 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, 16 Aug 2012 13:37:56 -0000 --Apple-Mail=_A91C3812-AF82-4830-AAAC-9A3C77211A2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=koi8-r On Aug 14, 2012, at 1:16 AM, Eugene Grosbein wrote: > 11.08.2012 20:35, David Duchscher =D0=C9=DB=C5=D4: >> Greetings,=20 >>=20 >> I have a need to turn off the link of an ethernet port on a Intel = nic. The issue is not a big deal but one we would like to solve. we = have no way of signaling an upstream router that a path is down but via = turning off the link of the ethernet port. This would only be used when = something goes wrong. The hope is that we could automate some problems = and handle other situations remotely avoiding having to visit the system = in person. >>=20 >> Any thoughts? We can modify the system so if it means modifying the = driver or some other code, I am willing to try. Just need a little = direction. >>=20 >> Thanks for your time, >=20 > I made such patch a couple of years ago and run it in production with = copper-based > em(4) and igb(4) NICs. The patch introduces new sysctls like = dev.em.X.down_disables_link > and dev.igb.X.down.disables_link with default zero values.=20 > Setting sysctl dev.em.0.down_disables_link=3D1 makes "ifconfig em0 = down" bring link down. >=20 > http://www.grosbein.net/freebsd/patches/em_sysctl-8.3.diff.gz > http://www.grosbein.net/freebsd/patches/igb_sysctl-8.3.diff.gz This is exactly what we needed. Thanks for sharing this with us. -- DaveD --Apple-Mail=_A91C3812-AF82-4830-AAAC-9A3C77211A2C-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 16:57: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 E240F1065702 for ; Thu, 16 Aug 2012 16:57:09 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id C2D618FC0A for ; Thu, 16 Aug 2012 16:57:09 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta05.emeryville.ca.mail.comcast.net with comcast id nULd1j00116AWCUA5Ux9BH; Thu, 16 Aug 2012 16:57:09 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta06.emeryville.ca.mail.comcast.net with comcast id nUs81j00X4NgCEG8SUs9lG; Thu, 16 Aug 2012 16:52:09 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7GGq64F017186; Thu, 16 Aug 2012 10:52:06 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Wojciech Puchar In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Aug 2012 10:52:06 -0600 Message-ID: <1345135926.27688.41.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: any status of that project? 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, 16 Aug 2012 16:57:10 -0000 On Thu, 2012-08-16 at 14:03 +0200, Wojciech Puchar wrote: > http://freebsdfoundation.blogspot.com/2012/03/new-project-nand-flash-support.html > > this would be great thing to have it working properly. any progress info? In the past few days I've tested the flash code in -current on a GlobalScale DreamPlug (arm platform), and confirmed that the low-level part of the code is working. I can read the flash on the unit and identify the existing partitions and data within them (but the main partition is formatted as UBI fs, so I've only looked at it with hexdump so far). I haven't tried the nandfs layer yet, or writing to the flash. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 22:17:34 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 3895F1065680; Thu, 16 Aug 2012 22:17:34 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id EDC788FC08; Thu, 16 Aug 2012 22:17:33 +0000 (UTC) Received: from [140.242.210.2] (helo=vanmgmt02.vancouver.polycom.com) by hq.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1T28NG-0000EE-6m; Thu, 16 Aug 2012 15:17:06 -0700 From: Oleksandr Tymoshenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 16 Aug 2012 15:17:26 -0700 Message-Id: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> To: "arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1463\)) X-Mailer: Apple Mail (2.1463) Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, 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: Grzegorz Bernacki (gber@) Aleksander Dutkowski Ben R. Gray (bgray@) Olivier Houchard (cognet@) Rafal Jaworowski (raj@) and Semihalf team Tim Kientzle (kientzle@) Jakub Wojciech Klama (jceel@) Ian Lepore Warner Losh (imp@) Damjan Marion (dmarion@) Lukasz Plachno Stanislav Sedov (stas@) Mark Tinguely Andrew Turner (andrew@) [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: arch@freebsd.org, hackers@freebsd.org Subject: 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: Thu, 16 Aug 2012 22:17:34 -0000 Hello, 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: Grzegorz Bernacki (gber@) Aleksander Dutkowski Ben R. Gray (bgray@) Olivier Houchard (cognet@) Rafal Jaworowski (raj@) and Semihalf team Tim Kientzle (kientzle@) Jakub Wojciech Klama (jceel@) Ian Lepore Warner Losh (imp@) Damjan Marion (dmarion@) Lukasz Plachno Stanislav Sedov (stas@) Mark Tinguely Andrew Turner (andrew@) Thanks to all, who contributed by submitting code, testing and giving valuable advices. Code drop includes following parts: - General ARMv6/ARMv7 kernel bits (pmap, cache, assembler routines, etc...) - ARM SMP support - VFP/Neon support - ARM Generic Interrupt Controller driver - Improved thread-local storage for cpus >=ARMv6 - Two new values for TARGET_ARCH: armv6 and armv6eb - Driver for SMSC LAN95XX and LAN8710A ethernet controllers - Marvell MV78x60 support (multiuser, ARMADA XP kernel config) - TI OMAP4 and AM335x support (multiuser, no GPU or graphics support, kernel configs for Pandaboard and Beaglebone) - LPC32x0 support (multiuser, frame buffer works with SSD1289 LCD controller.Embedded Artists EA3250 kernel config) - Barebone Nvidia Tegra2 support (timers, interrupts and UART. No kernel config) Hope now that the code is in trunk it will get more attention and love from developers. Happy hacking -- gonzo From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 16 22:39: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 A53D1106564A; Thu, 16 Aug 2012 22:39:35 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 39C8E8FC14; Thu, 16 Aug 2012 22:39:35 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 0E9781DD59C; Fri, 17 Aug 2012 00:39:34 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id E92512847B; Fri, 17 Aug 2012 00:39:33 +0200 (CEST) Date: Fri, 17 Aug 2012 00:39:33 +0200 From: Jilles Tjoelker To: Konstantin Belousov Message-ID: <20120816223933.GA19925@stack.nl> References: <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120816114426.GR5883@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 16 Aug 2012 22:39:35 -0000 On Thu, Aug 16, 2012 at 02:44:26PM +0300, Konstantin Belousov wrote: > My point is that the fact that fork() is called from dynamic context > that was identified as the signal handler does not mean anything. > It can be mis-identified for many reasons, which both me and you > tried to partially enumerate above. > The really important thing is the atomicity of the current context, > e.g. synchronous SIGSEGV caused by a language runtime GC is very > much safe place to call atfork handlers, since runtimes usually cause > signal generations only at the safe place. > I do not think that such approach as you described can be completed, > the _Fork() seems the only robust way. Agreed, that way (detecting signal handler) lies madness. If need be, _Fork() is easily implemented and used. > BTW, returning to Jilles proposal, can we call vfork() only for > single-threaded parent ? I think it gives good boost for single-threaded > case, and also eliminates the concerns of non-safety. 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. 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). 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 affected 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). -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 17 09:24:24 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 2C7AF106564A; Fri, 17 Aug 2012 09:24:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F36C28FC15; Fri, 17 Aug 2012 09:24:23 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8D5A746B20; Fri, 17 Aug 2012 05:24:23 -0400 (EDT) Date: Fri, 17 Aug 2012 10:24:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Oleksandr Tymoshenko In-Reply-To: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> Message-ID: References: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@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 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: Fri, 17 Aug 2012 09:24:24 -0000 On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: > 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: Amazing work -- many thanks are due to to everyone who was involved! Robert > > Grzegorz Bernacki (gber@) > Aleksander Dutkowski > Ben R. Gray (bgray@) > Olivier Houchard (cognet@) > Rafal Jaworowski (raj@) and Semihalf team > Tim Kientzle (kientzle@) > Jakub Wojciech Klama (jceel@) > Ian Lepore > Warner Losh (imp@) > Damjan Marion (dmarion@) > Lukasz Plachno > Stanislav Sedov (stas@) > Mark Tinguely > Andrew Turner (andrew@) > > Thanks to all, who contributed by submitting code, > testing and giving valuable advices. > > Code drop includes following parts: > > - General ARMv6/ARMv7 kernel bits (pmap, cache, > assembler routines, etc...) > - ARM SMP support > - VFP/Neon support > - ARM Generic Interrupt Controller driver > - Improved thread-local storage for cpus >=ARMv6 > - Two new values for TARGET_ARCH: armv6 and armv6eb > - Driver for SMSC LAN95XX and LAN8710A ethernet controllers > - Marvell MV78x60 support (multiuser, ARMADA XP kernel config) > - TI OMAP4 and AM335x support (multiuser, no GPU or graphics > support, kernel configs for Pandaboard and Beaglebone) > - LPC32x0 support (multiuser, frame buffer works with SSD1289 > LCD controller.Embedded Artists EA3250 kernel config) > - Barebone Nvidia Tegra2 support (timers, interrupts and UART. > No kernel config) > > Hope now that the code is in trunk it will get more attention > and love from developers. > > Happy hacking > > -- > gonzo > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 17 12:43: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 4C7531065670; Fri, 17 Aug 2012 12:43:21 +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 3D3C38FC16; Fri, 17 Aug 2012 12:43:19 +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 q7HChPfn016945; Fri, 17 Aug 2012 15:43:25 +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 q7HChCC7040398; Fri, 17 Aug 2012 15:43:12 +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 q7HChCbj040397; Fri, 17 Aug 2012 15:43:12 +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, 17 Aug 2012 15:43:12 +0300 From: Konstantin Belousov To: Jilles Tjoelker Message-ID: <20120817124312.GD33100@deviant.kiev.zoral.com.ua> References: <20120814081830.GA5883@deviant.kiev.zoral.com.ua> <502A1788.9090702@freebsd.org> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline In-Reply-To: <20120816223933.GA19925@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: Fri, 17 Aug 2012 12:43:21 -0000 --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > My point is that the fact that fork() is called from dynamic context > > that was identified as the signal handler does not mean anything. > > It can be mis-identified for many reasons, which both me and you > > tried to partially enumerate above. >=20 > > The really important thing is the atomicity of the current context, > > e.g. synchronous SIGSEGV caused by a language runtime GC is very > > much safe place to call atfork handlers, since runtimes usually cause > > signal generations only at the safe place. >=20 > > I do not think that such approach as you described can be completed, > > the _Fork() seems the only robust way. >=20 > Agreed, that way (detecting signal handler) lies madness. >=20 > If need be, _Fork() is easily implemented and used. >=20 > > BTW, returning to Jilles proposal, can we call vfork() only for > > single-threaded parent ? I think it gives good boost for single-threaded > > 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). 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 > 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 affected > 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). If rtld does not work, then any library function call from a signal handler is problematic. My goal is to get a working rtld and possibly malloc. 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. Below is the latest version of my patch for vfork, which survives (modified) tools/test/pthread_vfork_test. Patch is only for x86 right 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..1f0714f --- /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_child) + 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..134ba80 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; @@ -756,7 +752,7 @@ fork1(struct thread *td, int flags, int pages, struct p= roc **procp, struct thread *td2; struct vmspace *vm2; vm_ooffset_t mem_charged; - int error; + int error, single_threaded; static int curfail; static struct timeval lastfail; #ifdef PROCDESC @@ -815,6 +811,19 @@ fork1(struct thread *td, int flags, int pages, struct = proc **procp, } #endif =20 + if (((p1->p_flag & (P_HADTHREADS | P_SYSTEM)) =3D=3D P_HADTHREADS) && + (flags & RFPPWAIT) !=3D 0) { + PROC_LOCK(p1); + if (thread_single(SINGLE_BOUNDARY)) { + PROC_UNLOCK(p1); + error =3D ERESTART; + goto fail2; + } + PROC_UNLOCK(p1); + single_threaded =3D 1; + } else + single_threaded =3D 0; + mem_charged =3D 0; vm2 =3D NULL; if (pages =3D=3D 0) @@ -945,6 +954,12 @@ fail1: if (vm2 !=3D NULL) vmspace_free(vm2); uma_zfree(proc_zone, newproc); + if (single_threaded) { + PROC_LOCK(p1); + thread_single_end(); + PROC_UNLOCK(p1); + } +fail2: #ifdef PROCDESC if (((flags & RFPROCDESC) !=3D 0) && (fp_procdesc !=3D NULL)) { fdclose(td->td_proc->p_fd, fp_procdesc, *procdescp, td); --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAuPGAACgkQC3+MBN1Mb4hX7ACfT7TOl3/pYf8O6pqZCeGCNDBv 7V8AoMVz/suqGIqvU9J1hmiAJqcllF+Q =7/Wn -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 17 16:08: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 951E91065672; Fri, 17 Aug 2012 16:08:49 +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 C3C018FC1B; Fri, 17 Aug 2012 16:08:48 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id A175B358C68; Fri, 17 Aug 2012 18:08:47 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 7BA1D2847B; Fri, 17 Aug 2012 18:08:47 +0200 (CEST) Date: Fri, 17 Aug 2012 18:08:47 +0200 From: Jilles Tjoelker To: Konstantin Belousov Message-ID: <20120817160847.GA34417@stack.nl> References: <502A1788.9090702@freebsd.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120817124312.GD33100@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 17 Aug 2012 16:08:49 -0000 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-threaded > > > case, and also eliminates the concerns of non-safety. > > 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. > > 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). > 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. If libc calls a function with hidden visibility, this proceeds directly (not via the PLT) and rtld is not involved. 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 extern __typeof(next) next_int __attribute((alias("next"), visibility("hidden"))); in the same source as the definition of the function int next(void) { ...; } 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). 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/?). 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). 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. 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. An alternative is to write the core of posix_spawn() in assembler using system calls directly but I would rather avoid that :( > > 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 affected > > 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). > If rtld does not work, then any library function call from a signal handler > is problematic. My goal is to get a working rtld and possibly malloc. > 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. Oops :( Can this still be fixed (like by exporting identical functions in multiple versions)? > Below is the latest version of my patch for vfork, which survives (modified) > tools/test/pthread_vfork_test. Patch is only for x86 right now. 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). 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. 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. > [snip] > diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c > index 46cdca1..134ba80 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; > > -#ifdef XEN > - flags = RFFDG | RFPROC; /* validate that this is still an issue */ > -#else > flags = RFFDG | RFPROC | RFPPWAIT | RFMEM; > -#endif > error = fork1(td, flags, 0, &p2, NULL, 0); > if (error == 0) { > td->td_retval[0] = p2->p_pid; > @@ -756,7 +752,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > struct thread *td2; > struct vmspace *vm2; > vm_ooffset_t mem_charged; > - int error; > + int error, single_threaded; > static int curfail; > static struct timeval lastfail; > #ifdef PROCDESC > @@ -815,6 +811,19 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp, > } > #endif > > + if (((p1->p_flag & (P_HADTHREADS | P_SYSTEM)) == P_HADTHREADS) && > + (flags & RFPPWAIT) != 0) { > + PROC_LOCK(p1); > + if (thread_single(SINGLE_BOUNDARY)) { > + PROC_UNLOCK(p1); > + error = ERESTART; > + goto fail2; > + } > + PROC_UNLOCK(p1); > + single_threaded = 1; > + } else > + single_threaded = 0; > + > mem_charged = 0; > vm2 = NULL; > if (pages == 0) > @@ -945,6 +954,12 @@ fail1: > if (vm2 != NULL) > vmspace_free(vm2); > uma_zfree(proc_zone, newproc); > + if (single_threaded) { > + PROC_LOCK(p1); > + thread_single_end(); > + PROC_UNLOCK(p1); > + } > +fail2: > #ifdef PROCDESC > if (((flags & RFPROCDESC) != 0) && (fp_procdesc != NULL)) { > fdclose(td->td_proc->p_fd, fp_procdesc, *procdescp, td); -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 18 07:56:06 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 14F2D106566B for ; Sat, 18 Aug 2012 07:56:06 +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 14F1E8FC0A for ; Sat, 18 Aug 2012 07:56:01 +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 q7I7tivm068125 for ; Sat, 18 Aug 2012 09:55:46 +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 q7I7tg2W068122 for ; Sat, 18 Aug 2012 09:55:44 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 18 Aug 2012 09:55:42 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 18 Aug 2012 09:55:46 +0200 (CEST) Subject: posix_fadvise64? 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, 18 Aug 2012 07:56:06 -0000 i tried to compile xfsprogs from ports linking fails with missing posix_fadvise64 man posix_fadvise gives me manual, but what is fadvise64? From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 18 08:10:20 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 3ABDB106566B for ; Sat, 18 Aug 2012 08:10:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3918FC08 for ; Sat, 18 Aug 2012 08:10:20 +0000 (UTC) Received: from Xins-MacBook-Pro.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 29ACD17952; Sat, 18 Aug 2012 01:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1345277414; bh=ff8HWNmo+lsp1kyDmlUqctjjJHIJZqkD298JW0zLglc=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=AMjauF5TR49fbqkSJ5+rzinFxZr3w9Iqmb3db2GfBMoqbZ7vbO5HLy8Vkd2cuME4A hsG/JZPXXPZjcz2IWaptXdMsmBBY0VO77uJ614+Y+AX9mxuY2Vx7MqGfpoNKO2/mBB ftakOSzGCHU/ialD8rqQJF0cAB9pn/V4AJyIjpKc= Message-ID: <502F4DE5.9000906@delphij.net> Date: Sat, 18 Aug 2012 01:10:13 -0700 From: Xin Li Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Wojciech Puchar References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: posix_fadvise64? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 08:10:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 8/18/12 12:55 AM, Wojciech Puchar wrote: > i tried to compile xfsprogs from ports > > > linking fails with missing posix_fadvise64 > > man posix_fadvise gives me manual, but what is fadvise64? Looking at Linux manual page I believe you can just replace it with posix_fadvise. On *BSD off_t is always 64-bit. Cheers, -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBCAAGBQJQL03lAAoJEG80Jeu8UPuzs38H/3mM3SSpzdpDJggiigLLfLZo ijBp9mzR052Ar5v8qlAVsY8KZPY/gtCHvsApEsWJ3CRqNqzaPstczlHmUR2BpTOb n2UkLKx8ktl5cQDBq4E9CCojGnJwhr6J8JTSHKa4ahse/1+1+HcifFV1z06QjPE+ fTkzSPD7gBsLa6hphs0gqnUq0uSoPQimToYBkqMvnn3UQiwZD6fIEfu70sLg/HSe 5g8E4kXtSmXHAKbWGAwleNStPP6Wptxeg9bVbVxUQ4R7PJJEPU+6zx14yEqQs0go QHgqZRE4IRpD6+z/n3P/fm5cw0J9xadj/q1CXl1cFS1E6ne9Y/QdnNGF+8dpMwk= =k2lu -----END PGP SIGNATURE-----