armdev: sys_clone is broken

[shrik3]

new task with pc == 0 will fail, of course.

with this simple program:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main()
{
    printf("testing fork; init pid = %d\n", getpid());
    pid_t p = fork();
    if (p < 0) {
        printf("fork failed!");
        exit(1);
    }
    if (p == 0) {
        printf("print from child. pid = %d\n", getpid());
    } else {
        printf("print from parent. pid = %d\n", getpid());
    }
    return 0;
}

Erorr Log:

[INFO] [1/43c0140000|0] (1/1)------get call id sys_clone arg0:4111
[INFO] [1/43c0140000|0] Clone opts is CloneOptions { sharingOption: SharingOptions { NewAddressSpace: false, NewSignalHandlers: true, NewThreadGroup: true, TerminationSignal: Signal(11), NewPIDNamespace: false, NewUserNamespace: false, NewNetworkNamespace: false, NewFiles: true, NewFSContext: true, NewUTSNamespace: false, NewIPCNamespace: false }, Stack: 7f4d8e3137b0, SetTLS: false, TLS: fffffffe7fffffff, ChildClearTID: false, ChildSetTID: false, ChildTID: 0, ParentSetTID: false, ParentTID: 0, Vfork: true, Untraced: false, InheritTracer: false }
[INFO] [1/43c0140000|0] created child task with context with pc 0 , sp 43c01dfec8
[DEBUG] [1/43c0140000|0] set tpidr_el0 from 2b8410f7f640 to 2b8410f7f640
[DEBUG] [1/43c01c0000|0] get instruction abort fault from el1
[INFO] [1/43c01c0000|0] DFSC/IFSC == 0x5, FAR == 0x0, acces-type fault == --x, during address translation == false, ESR=86000005, PC=0
[ERROR] [1/43c01c0000|0] VM: PageFault in kernel FAR: 0x0, TTBR: 0x43c0401000, PtRegs: SP:[0x43c01dfec8]
                   PC:[0x0]                   <<<<<<< note that this pc is null
                   State:[0x800003c5]
                   X0:[0x7f4d8e3137b0]
                   GenRegs:[[ ... ]]

I'll try fixing this.

btw @CharlyYu I saw your comment in task_clone.rs#677

        // TODO what is this?
        #[cfg(target_arch = "x86_64")]
        {
            toPtRegs.rax = 0;
        }

If I unsderstand correctly, this is because the fork() returns child PID to the parent, and returns 0 to the child.

[shrik3]

this is due to inconsistent definition of aarch64 context. This has been fixed.

However this sys_clone is still incorrect as it returns EFAULT (bad address) , this is undefined in man 2 clone

[shrik3]

patch coming soon.

I'm getting access flag faults and permission faults on the forked child process.

[CharlyYu]

this is because the fork() returns child PID to the parent, and returns 0 to the child.

That makes sense.

[shrik3]

data abort: child process is trying to write to read-only memory. The FAR is user stack, so it's not supposed to be read-only...

[DEBUG] [1/43c0140000|0] get data abort fault from el0
[INFO] [1/43c0140000|0] DFSC/IFSC == 0xF, FAR == 0x7F1438AE4AA0, acces-type fault == -w-, during address translation == false, ESR=9200004f, PC=419580
[DEBUG] [1/43c0140000|0] need to handle fault: ctx is SP:[0x7f1438ae4ae0]
                   PC:[0x419580]
                   State:[0x0]
                   X0:[0x2]
                   GenRegs:[[
    2,
    0,
    2,
    0,
    4825296,
    4827072,
    4825088,
    0,
    220,
    139724827020007,
    49,
    10,
    1,
    0,
    0,
    0,
    1,
    4286080,
    0,
    2,
    48,
    4788224,
    4827072,
    0,
    4778008,
    24,
    0,
    0,
    4792368,
    139724827020000,
    4296412,
]]
[DEBUG] [1/43c0140000|0] VM: Entered HandleFault.
[ERROR] [1/43c0140000|0] PF HANDLER: sending SIGSEGV
[ERROR] [1/43c0140000|0] TASK ID: 290985345024, thread-uid: 307
[DEBUG] [1/43c0140000|0] Dump mapping for virt addr 7f1438ae4aa0
[DEBUG] [1/43c0140000|0] L0[254] 0000000000000000 - 0043c040d - 010001000011 - MapRange:     7f0000000000 + 512G
[DEBUG] [1/43c0140000|0]     L1[080] 0000000000000000 - 0043c040e - 010001000011 - MapRange:     7f1400000000 + 1G
[DEBUG] [1/43c0140000|0]         L2[453] 0000000000000000 - 0043c040f - 010001000011 - MapRange:     7f1438a00000 + 2M
[DEBUG] [1/43c0140000|0]             L3[228] 0000000000000000 - 0043c040c - 010011000011 - MapRange:     7f1438ae4000 + 4K

[chl337]

@shrik3 Can we now close this?

[chl337]

@shrik3 is the issue still relevant or can be closed?