Hi,
there is plain erronous special case for Xen in the handling of vfork(2)
syscall, which converts it into the fork(2), but only on Xen. I think this
was a bug to commit the change in the course of importing Xen support at all.

Could somebody of you, who use paravirtualized kernels, test the patch
below. After the patched kernel is booted, just running csh(1) and
calling any external command from it, e.g. ls(1), is enough.

I already tried to solicit the testing of the fix in private, but nobody
responded. I am going to commit the change in a week, unless somebody
report a real issue with Xen pmap, uncovered by it.

diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index b8a4825..0d2709f 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;

Attachment: pgpQ0tRlValmW.pgp
Description: PGP signature

Reply via email to