[Bug 278841] rfork(2) bad documentation

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278841

            Bug ID: 278841
           Summary: rfork(2) bad documentation
           Product: Documentation
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Manual Pages
          Assignee: bugs@FreeBSD.org
          Reporter: i+freebsd@1a-insec.net
                CC: doc@FreeBSD.org

# problems about rfork(2)


rfork(RFTHREAD) returns 0 (but it doesn't do anything). This is not documented
explicitly.



RETURN VALUES section bad

>>> start (this part should be in RETURN VALUES)
     If RFPROC is set, the value returned in the parent process is the process
     id of the child process; the value returned in the child is zero.
     Without RFPROC, the return value is zero.  Process id's range from 1 to
     the maximum integer (int) value.  The rfork() system call will sleep, if
     necessary, until required process resources are available.
>>> end
     The fork() system call can be implemented as a call to rfork(RFFDG |
     RFPROC) but is not for backwards compatibility.

RETURN VALUES
     Upon successful completion, rfork() returns a value of 0 to the child
     process and returns the process ID of the child process to the parent
     process.  Otherwise, a value of -1 is returned to the parent process, no
     child process is created, and the global variable errno is set to
     indicate the error.



I don't understand this wording:

> RFTHREAD     If set, the new process shares file descriptor to process leaders table with its parent 

Since `man -K 'process leader'` gives no result, I've read the FreeBSD source
code and wrote about p_leader myself:
https://www.1a-insec.net/frag/35-freebsd-fd-race/. I hope I understand this
correctly.

For some reason, there are both `proc->p_fdtol->fdl_leader` and
`proc->p_leader`.


In sys/kern/kern_descrip.c, I see:

                        error = VOP_ADVLOCK(vp, (caddr_t)p->p_leader, F_SETLK,
                            flp, flg);

                                (void) VOP_ADVLOCK(vp,
                                    (caddr_t)fdtol->fdl_leader, F_UNLCK, &lf,
                                    F_POSIX);

What is happening here?

-- 
You are receiving this mail because:
You are the assignee for the bug.