[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libc6:m68k 2.28-1

Finn,

Am 08.12.2018 um 12:37 schrieb Finn Thain:

On Sat, 8 Dec 2018, John Paul Adrian Glaubitz wrote:



This seems to affect qemu-user only while the lock-up problem with dash
occurs on qemu-system only.

Finn, did you verify the lock-up problem on real hardware by any chance?



I don't have my 68k hardware with me at the moment.


Just to make sure the lock-up is not a qemu bug.



Well, if it's a qemu bug then it's also an aranym bug.

If you want to reproduce on elgar, you only need 3 files:

# ls -lR
.:
total 8
drwxr-xr-x 2 root root 4096 Dec  3 07:31 bin
drwxr-xr-x 3 root root 4096 Nov 28 22:42 lib

./bin:
total 112
-rwxr-xr-x 1 root root 108220 Dec  3 07:31 dash
lrwxrwxrwx 1 root root      4 Dec  3 07:31 sh -> dash

./lib:
total 4
lrwxrwxrwx 1 root root   25 Nov 28 22:42 ld.so.1 -> m68k-linux-gnu/ld-2.28.so
drwxr-xr-x 2 root root 4096 Dec  3 07:31 m68k-linux-gnu

./lib/m68k-linux-gnu:
total 1412
-rwxr-xr-x 1 root root  120008 Nov 28 22:42 ld-2.28.so
lrwxrwxrwx 1 root root      10 Nov 28 22:42 ld.so.1 -> ld-2.28.so
-rwxr-xr-x 1 root root 1314040 Nov 28 22:42 libc-2.28.so
lrwxrwxrwx 1 root root      12 Nov 28 22:42 libc.so.6 -> libc-2.28.so
# chroot . /bin/sh
# /bin/sh -c foo
/bin/sh: 1: foo: not found

At this point dash has hung. If you strace that process from outside the
chroot, you can see it looping around wait4() = -1 ECHILD.
Can you strace the whole procedure (i.e. starting with the call to chroot) from the outside? With time stamps, for preference?
The strace you did show with dash does indicate that SIGCHLD was sent by the child process / thread but even before that, the parent process got -ECHILD.
To me, this would indicate that wait4 uses the wrong task struct to search for childs / threads to check. 

Might this have something to do with it?


/*
 * Why not generic sys_clone, you ask?  m68k passes all arguments on stack.
 * And we need all registers saved, which means a bunch of stuff pushed
 * on top of pt_regs, which means that sys_clone() arguments would be
 * buried.  We could, of course, copy them, but it's too costly for no
 * good reason - generic clone() would have to copy them *again* for
 * do_fork() anyway.  So in this case it's actually better to pass pt_regs *
 * and extract arguments for do_fork() from there.  Eventually we might
 * go for calling do_fork() directly from the wrapper, but only after we
 * are finished with do_fork() prototype conversion.
 */
asmlinkage int m68k_clone(struct pt_regs *regs)
{
        /* regs will be equal to current_pt_regs() */
        return do_fork(regs->d1, regs->d2, 0,
                       (int __user *)regs->d3, (int __user *)regs->d4);
}



Other architectures seem to treat clone() different from fork()?

Cheers,

	Michael
Reply to: