On Sun, Mar 28, 2010 at 2:00 PM, John David Anglin
<dave@xxxxxxxxxxxxxxxxxx> wrote:
> Ok, it might be glibc that's broken (i.e., it doesn't restore correct
> dave).
I don't think this is broken.
>> 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)")
>
> Tried that and it didn't trigger.
OK, your kernel is perhaps fixed?
>> > 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.
>
> Hmmm, I'm not seeing that, but I do have the patch installed that
> reloads %r16 after calling schedule. %r16 isn't clobbered by the
> call but I believe %cr30 can change. As a result, we may run a task
> with the wrong registers with the current code.
When schedule returns you are either still in the current process, or
have switched to another process via arch/parisc/kernel/entry.S
(_switch_to), so yes %cr30 will have been changed and must be reloaded
(kernel threads IIUC don't have their own register state, you are
simply just switching %cr30 around and reloading the appropriate
pt_regs).
Where are the new space ids loaded into the space registers for the new process?
> See <http://article.gmane.org/gmane.linux.ports.parisc/2687>.
Applied.
> It's only supposed to happen if there is an error in the execve call.
> I think our task scheduling is broken ;(
>
> Could you try my change and see if it helps?
It doesn't help.
Just so we are on the same page, please find attached vforktest.tgz.
Unpack it.
Run ./build.sh
Run ./vfork
What are the results on your machine?
I'm running a 64-bit kernel 2.6.32 (kyle's tree) SMP two PA8700's at 650MHz.
Cheers,
Carlos.
Attachment:
vforktest.tgz
Description: GNU Zip compressed data
