On Sun, Mar 28, 2010 at 11:42 AM, John David Anglin
<dave@xxxxxxxxxxxxxxxxxx> wrote:
>> Test case attached.
>
> I was not able to save your pt-fork.S file. mutt didn't understand
> the encoding.
Attached as vforktest.tgz.
> I tried the vfork.c test case on my c3750 with 32-bit kernel. It
> didn't segv in a limited number of runs. However, I did notice that
> getpid() is broken after vfork().
Broken how?
A small note about getpid():
Since the parent and child share the same memory space, the parent
temporarily negates the cached PID value just before the vfork. Only
the parent, after the vfork, restores the cached PID. This is on
purpose to prevent any functions like PID-related functions from
working in the child() during the window bewteen vfork and execve.
> The printf call in the child path probably isn't legit. It's also not
> legit to simply return if execve fails. _exit must be called.
The printf call in the child path is ABSOLUTELY wrong, but I wanted to
see what the return was. You could equally well insert:
#define ABORT_INSTRUCTION asm ("iitlbp %r0,(%sr0, %r0)")
And cause the child to abort with an invalid instruction trap, and
inspect r28 at the time of the fault to see what execve returned.
In fact I use this in my testing now to avoid printf.
> My guess would be that the parent is not blocked leading to corruption.
What I see is that the child is returning from the kernel execve, and
continuing to execute.
If I use ABORT_INSTRUCTION in the child right after the execve I see this:
carlos@firin:~/fsrc/vforkfailure/test$ ./vfork
Illegal instruction
carlos@firin:~/fsrc/vforkfailure/test$ In child 28734
This makes *no* sense.
What I don't understand is this:
* vfork'd child shares memory space with parent, therefore space id
has to be the same?
* Does execve give the process a new space id or does it simply
overwrite the entire process image?
So I had the test case try to exec a binary that just calls ABORT_INSTRUCTION.
What I noticed is the following:
carlos@firin:~/fsrc/vforkfailure/test$ ./vfork
parent sr3 is 0x3428000
Illegal instruction
There are 2 entries in dmesg:
vfork (pid 28964): Illegal instruction (code 8) at 00000000000106a7
main (pid 28965): Illegal instruction (code 8) at 00000000000104af
* The child returning from execve has the same space id as the parent
e.g. 0x3418000
* The process run via the execve has a different space id e.g. 0x3418800
What is supposed to stop the child, which called execve, from
returning to the parent?
Cheers,
Carlos.
Attachment:
vforktest.tgz
Description: GNU Zip compressed data
