| Message ID | 20161121164013.8062.14361.malonedeb@soybean.canonical.com |
|---|---|
| State | New |
| Headers | show |
I also notice fd_trans_unregister does not appear in the socketcall implementation which seems like an oversight.
Strace jessie mips groupadd. ** Attachment added: "jessie_mips_groupadd.strace" https://bugs.launchpad.net/qemu/+bug/1643619/+attachment/4783716/+files/jessie_mips_groupadd.strace
Patch applied by James works for me as well. Dropping a qemu-user static binary from Debian qemu 2.1 into the mips chroot can also be used as workaround.
This has been fixed by 40493c5f2b0f124c9b2581e539bba14522e51269, which
is exactly the same diff as given here.
** Changed in: qemu
Status: New => Fix Committed
** Changed in: qemu
Status: Fix Committed => Fix Released
--- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -9331,7 +9331,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, #ifdef TARGET_NR_socket case TARGET_NR_socket: ret = do_socket(arg1, arg2, arg3); - fd_trans_unregister(ret); break; #endif #ifdef TARGET_NR_socketpair
Public bug reported: Debian QEMU version 2.7.0, but the bug also appears in current git master (commit c36ed06e9159) As the summary says, netlink is completely broken on big-endian mips running qemu-user. Running 'ip route' from within a Debian chroot with QEMU simply hangs. Running amd64 strace on qemu-mips-static shows that it's waiting for a netlink response from the kernel which never comes. [...] [pid 11249] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3 [pid 11249] setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 [pid 11249] setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0 [pid 11249] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0 [pid 11249] getsockname(3, {sa_family=AF_NETLINK, nl_pid=11249, nl_groups=00000000}, [12]) = 0 [pid 11249] time([1479745823]) = 1479745823 [pid 11249] sendto(3, {{len=671088640, type=0x1a00 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_MULTI|0x100, seq=539046744, pid=0}, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\0\0\1"}, 40, 0, NULL, 0) = 40 [pid 11249] recvmsg(3, Notice the len in the buffer passed to the kernel is 0x28000000 which looks byteswapped. Removing the call to fd_trans_unregister in the NR_socket syscall in do_syscall fixes this for me, but I don't understand why the fd translation was immediately unregistered after being registered just before in do_socket - presumably it was added for a reason. ** Affects: qemu Importance: Undecided Status: New