[9fans] 9vx fork problem

[9fans] 9vx fork problem

[Anthony Martin]

On 9vx, iostats suicides:

  term% iostats echo
  iostats 128: suicide: sys: trap: page fault pc=0x0000b21c

Apparently, after a fork, a child retains it's parent's
pid in _tos->pid. It isn't updated until the next syscall
finishes with kexit.

This is a problem if the child's first function call is
malloc. When malloc locks it's pool, it stores the pid
from _tos in a private area. After the kernel returns from
the brk, _tos->pid has been corrected by the call to kexit.
Punlock then fails because the pids don't match.

I'm not sure of the best way to go about fixing this.

     Anthony

Re: [9fans] 9vx fork problem

[Russ Cox]

> On 9vx, iostats suicides:
>
>   term% iostats echo
>   iostats 128: suicide: sys: trap: page fault pc=0x0000b21c
>
> Apparently, after a fork, a child retains it's parent's
> pid in _tos->pid. It isn't updated until the next syscall
> finishes with kexit.
>
> This is a problem if the child's first function call is
> malloc. When malloc locks it's pool, it stores the pid
> from _tos in a private area. After the kernel returns from
> the brk, _tos->pid has been corrected by the call to kexit.
> Punlock then fails because the pids don't match.
>
> I'm not sure of the best way to go about fixing this.

Thank you for the detailed reports.
It makes it very easy to fix the bugs!

a1=; hg diff -r37 9vx/vx32.c
diff -r d945b0921bdc src/9vx/vx32.c
--- a/src/9vx/vx32.c	Sun Jun 29 22:01:07 2008 -0400
+++ b/src/9vx/vx32.c	Sun Jun 29 22:01:55 2008 -0400
@@ -186,6 +186,9 @@ void
 void
 forkret(void)
 {
+	extern void kexit(Ureg*);
+
+	kexit(nil);
 	touser(0);
 }

a1=;

Re: [9fans] 9vx fork problem

[Anthony Martin]

> Thank you for the detailed reports.
> It makes it very easy to fix the bugs!

It really is my pleasure. Hunting bugs is
one of my favorite pastimes. Well, that's
not completely true: hunting bugs is usually
only fun when dealing with code of a certain
quality. Plan 9 makes the cut, as does all
of your code.

> +	kexit(nil);

I figured that would do it. :)

     Anthony

Re: [9fans] 9vx fork problem

[Steve Simon]

> Apparently, after a fork, a child retains it's parent's
> pid in _tos->pid.

I think this is at the root of why 9vx cannot run on MS-Windows.

I have been very slowly crawling towards an updated port of 9pm
(p9p for windows as it was) learing the Windows API and the plan9
kernel as I go.

The one total show stopper is a lack of a real fork() in windows.

This meant I chose to implement rfork(RFPROC) as somthing like vfork() -
CreateThread() followed by CreateProcess() whilst the parent is blocked.
This works in simple cases but breaks on rc(1). This is fixable by
modifying the rc source (rc runs under windows in its inferno form anyway)
but that is not the point.

I implemented rfork(RFPROC|RFMEM) as CreateThread() with stack copy
and relocation. This works well but means every windows-thread/plan9-psudo-proc
has a different stack and thus _tos and _tos->pid won't work.

This is OK, I just recompile every app using a modified malloc.c in libc
but once again, if you break the purity of unmodified plan9 binaries then
then you win almost noting over recompiling them on the target platform anyway -
kencc syntax extensions not withstanding.

I would love to get 9vx running on windows and if anyone has any ideas how to
solve these problems then let me know.

-Steve

Re: [9fans] 9vx fork problem

[Pietro Gagliardi]

- Modify the kernel (it is based on Unix - even Microsoft says so)
- Learn how Cygwin does it
- Don't use real processes, like in Inferno

On Jun 30, 2008, at 8:34 AM, Steve Simon wrote:

>> Apparently, after a fork, a child retains it's parent's
>> pid in _tos->pid.
>
> I think this is at the root of why 9vx cannot run on MS-Windows.
>
> I have been very slowly crawling towards an updated port of 9pm
> (p9p for windows as it was) learing the Windows API and the plan9
> kernel as I go.
>
> The one total show stopper is a lack of a real fork() in windows.
>
> This meant I chose to implement rfork(RFPROC) as somthing like
> vfork() -
> CreateThread() followed by CreateProcess() whilst the parent is
> blocked.
> This works in simple cases but breaks on rc(1). This is fixable by
> modifying the rc source (rc runs under windows in its inferno form
> anyway)
> but that is not the point.
>
> I implemented rfork(RFPROC|RFMEM) as CreateThread() with stack copy
> and relocation. This works well but means every windows-thread/plan9-
> psudo-proc
> has a different stack and thus _tos and _tos->pid won't work.
>
> This is OK, I just recompile every app using a modified malloc.c in
> libc
> but once again, if you break the purity of unmodified plan9 binaries
> then
> then you win almost noting over recompiling them on the target
> platform anyway -
> kencc syntax extensions not withstanding.
>
> I would love to get 9vx running on windows and if anyone has any
> ideas how to
> solve these problems then let me know.
>
> -Steve
>

Re: [9fans] 9vx fork problem

[Russ Cox]

>> Apparently, after a fork, a child retains it's parent's
>> pid in _tos->pid.
>
> I think this is at the root of why 9vx cannot run on MS-Windows.

No, it's not.  The words fork and pid in that sentence
are concepts completely internal to 9vx.  The host OS,
be it OS X or Linux or Windows, has absolutely no idea
they exist and is not contributing at all toward their
implementation.  The only thing the host OS sees is a bunch
of pages from a file being mapped and unmapped from
memory.

In fact, 9vx would probably be easier to bring up on Windows
than trying to do anything special just to implement rfork
for a p9p-style port (not implementing rfork would
be easier still; see below).

> I have been very slowly crawling towards an updated port of 9pm
> (p9p for windows as it was) learing the Windows API and the plan9
> kernel as I go.
>
> The one total show stopper is a lack of a real fork() in windows.
>
> This meant I chose to implement rfork(RFPROC) as somthing like vfork() -
> CreateThread() followed by CreateProcess() whilst the parent is blocked.
> This works in simple cases but breaks on rc(1). This is fixable by
> modifying the rc source (rc runs under windows in its inferno form anyway)
> but that is not the point.
>
> I implemented rfork(RFPROC|RFMEM) as CreateThread() with stack copy
> and relocation. This works well but means every windows-thread/plan9-psudo-proc
> has a different stack and thus _tos and _tos->pid won't work.

This is a separate issue.  In p9p I prepared for this by getting
rid of all the uses of rfork to create threads, replacing them
with the thread library and threadcreate.  The latter should be
easier to implement with Windows primitives, if you stay that
course.

Russ

Re: [9fans] 9vx fork problem

[Steve Simon]

>> I think this is at the root of why 9vx cannot run on MS-Windows.

> No, it's not.

I can only appologise for emailing before reading the vx30 paper properly,
I now understand (some of) how cunning it really is.

I 9vx for windows is the way to go.

Thanks russ.

-Steve

Re: [9fans] 9vx fork problem

[Robert William Fuller]

Pietro Gagliardi wrote:
> - Modify the kernel (it is based on Unix - even Microsoft says so)

Sure it is...in the same way that VMS is based on UNIX (which means not
at all....)