From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny
crashes with SIGSYS on radeonsi
Date: Wed, 20 Feb 2019 20:12:32 +0000
Message-ID:
Bug ID
109695
Summary
qemu using spice gl and sandbox resourcecontrol=3Ddeny crashe=
s with SIGSYS on radeonsi
Product
Mesa
Version
18.3
Hardware
x86-64 (AMD64)
OS
Linux (All)
Status
NEW
Severity
major
Priority
medium
Component
Drivers/Gallium/radeonsi
Assignee
dri-devel@lists.freedesktop.org
Reporter
Ahzo@tutanota.com
QA Contact
dri-devel@lists.freedesktop.org
Since upgrading Mesa from 18.2 to 18.3, launching a QEMU virtu=
al machine with
Spice OpenGL enabled (for virgl), causes QEMU to crash with SIGSYS inside t=
he
radeonsi driver. The reason for this is that the QEMU sandbox option
'resourcecontrol=3Ddeny' disables the sched_setaffinity syscall called in
pthread_setaffinity_np, which is now used by the radeonsi driver.
A simple way to reproduce this problem is:
$ gdb --batch --ex run --ex bt --args qemu-system-x86_64 -spice gl=3Don -sa=
ndbox
on,resourcecontrol=3Ddeny
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so=
.1".
[New Thread 0x7ffff45aa700 (LWP 23432)]
[New Thread 0x7ffff08e5700 (LWP 23433)]
[New Thread 0x7fffe3fff700 (LWP 23434)]
[New Thread 0x7fffe37fe700 (LWP 23435)]
Thread 4 "qemu-system-x86" received signal SIGSYS, Bad system cal=
l.
[Switching to Thread 0x7fffe3fff700 (LWP 23434)]
0x00007ffff68cc9cf in __pthread_setaffinity_new (th=3D<optimized out>,
cpusetsize=3Dcpusetsize@entry=3D128, cpuset=3Dcpuset@entry=3D0x7fff=
e3ffe680) at
../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
34 ../sysdeps/unix/sysv/linux/pthread_setaffinity.c: No such file or
directory.
#0 0x00007ffff68cc9cf in __pthread_setaffinity_new (th=3D<optimized out=
>,
cpusetsize=3Dcpusetsize@entry=3D128, cpuset=3Dcpuset@entry=3D0x7fff=
e3ffe680) at
../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
#1 0x00007ffff12ba2b3 in util_queue_thread_func
(input=3Dinput@entry=3D0x55555640b1f0) at ../src/util/u_queue.c:252
#2 0x00007ffff12b9c17 in impl_thrd_routine (p=3D<optimized out>) at
../src/../include/c11/threads_posix.h:87
#3 0x00007ffff68c1fa3 in start_thread (arg=3D<optimized out>) at
pthread_create.c:486
#4 0x00007ffff67f280f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
The problematic code at src/util/u_queue.c:252 was added in the following
commit:
commit d877451b48a59ab0f9a4210fc736f51da5851c9a
Author: Marek Ol=C5=A1=C3=A1k <marek.olsak@amd.com>
Date: Mon Oct 1 15:51:06 2018 -0400
util/u_queue: add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY
Initial version discussed with Rob Clark under a different patch name.
This approach leaves his driver unaffected.
Since setting the thread affinity seems non-essential here, the failing sys=
call
should be handled gracefully, for example by setting a signal handler to ig=
nore
the SIGSYS signal.