rfork(RFPROC|RFMEM)

[Igor Sysoev]

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/