From owner-freebsd-arch@FreeBSD.ORG Tue May 6 12:44:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2839C37B401 for ; Tue, 6 May 2003 12:44:04 -0700 (PDT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0EE343FA3 for ; Tue, 6 May 2003 12:44:02 -0700 (PDT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h46Ji1mF089759; Tue, 6 May 2003 23:44:01 +0400 (MSD) Date: Tue, 6 May 2003 23:44:01 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: Terry Lambert In-Reply-To: <3EB7D23D.FD5E4191@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 19:44:04 -0000 On Tue, 6 May 2003, Terry Lambert wrote: >Igor Sysoev wrote: >> On Mon, 5 May 2003, Terry Lambert wrote: >> > Igor Sysoev wrote: >> > > On Mon, 5 May 2003, Terry Lambert wrote: >> > > What is stack glue ? >> > >> > See the code in fork1() in /sys/kern/kern_fork.c. >> >> I do not see any stack manipulation in kern_fork.c except the creating >> alternate kstack for KSE thread in 5.0. And rfork(2) can not create >> such stack - it passes 0 to fork1(). > >You misunderstand. After the rfork() returns, there is >different stack glue required to implement "a threads >library" when you use RFTHREAD than when you don't use >RFTHREAD. I do not see any difference in a stack glue when rfork() called with RFTHREAD and without it. >And I *know* it can't create the stack: you have to do >that in user space with assembly language glue you provide. > >In other words, it's working without RFTHREAD, you're just >using the wrong stack glue in user space. What is difference of these stack glues ? >> > > I use rfork_thread(3) wrapper that allows to setup another stack for >> > > rfork()ed process. >> >> By the way I found the bug in x86 rfork_thread(3)'s error handling: >> >> --- /usr/src/lib/libc/i386/gen/rfork_thread.S Wed Feb 7 03:12:45 2001 >> +++ /usr/src/lib/libc/i386/gen/rfork_thread.S Tue May 6 17:45:14 2003 >> @@ -108,5 +108,8 @@ >> * Branch here if the thread creation fails: >> */ >> 2: >> + popl %esi >> + movl %ebp, %esp >> + popl %ebp >> PIC_PROLOGUE >> jmp PIC_PLT(HIDENAME(cerror)) > > >sendpr the fix to the linuxthreads maintainer, please. I will sendpr but not to the linuxthreads maintainer. linuxthreads port does not use rfork_thread(3). It uses its own similar rfork(2) wrapper to set up the stack and this wrapper handles errors correctly. >> > > By the way linuxthreads port always uses RFTHREAD flag. >> > >> > They don't know any other way than the moral equivalent of >> > the Linux "clone" system call, so that's what they use; it's >> > technically not necessary. See also the source code in the >> >> Now it's necessary. Otherwise rfork() returns EINVAL. > >It only does that if at least one of a set of flags is not >set; I don't see where you think EINVAL is coming from. It's recent changes 1.182 in 5.0 and 1.72.2.12 in 4.8 in kern_fork.c. Now rfork() requires RFTHREAD to be set if RFPROC is set. >But in any case, if RFTHREAD makes something work for you, >then by all means use it. It should not be implied, and >it should not be required by documentation, since, as you >noticed reading the code, all it does is associate sibling >threads under a parent for killing and advisory locking. Well, but I think this change should be documented. Right now rfork(RFPROC|RFMEM) returns EINVAL and rfork_thread(2) causes segmentation fault because it does not handle errors correctly. >> > directory /usr/src/lib/libpthread, which doesn't use rfork() >> > at all. >> >> I know it. > >My point was that the only code that uses it without RFTHREAD >successfully is probably about two years old, and was never >committed to the tree as part of a threads library. You Yes, I belive it, rfork(RFPROC|RFMEM) runs on FreeBSD-4.3. >would need to check the mailing list archives for "Jason Evans" >and "John Dyson", in combination with "rfork", to find the code >that "fixes" needing RFTHREAD. RFTHREAD got to be required recently. Igor Sysoev http://sysoev.ru/en/