[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi - bugzilla-daemon

From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.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	[thread overview]
Message-ID: <bug-109695-502@http.bugs.freedesktop.org/> (raw)

[-- Attachment #1.1: Type: text/plain, Size: 3089 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

            Bug ID: 109695
           Summary: qemu using spice gl and sandbox resourcecontrol=deny
                    crashes 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 virtual machine with
Spice OpenGL enabled (for virgl), causes QEMU to crash with SIGSYS inside the
radeonsi driver. The reason for this is that the QEMU sandbox option
'resourcecontrol=deny' 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=on -sandbox
on,resourcecontrol=deny
[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 call.
[Switching to Thread 0x7fffe3fff700 (LWP 23434)]
0x00007ffff68cc9cf in __pthread_setaffinity_new (th=<optimized out>,
cpusetsize=cpusetsize@entry=128, cpuset=cpuset@entry=0x7fffe3ffe680) 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=<optimized out>,
cpusetsize=cpusetsize@entry=128, cpuset=cpuset@entry=0x7fffe3ffe680) at
../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
#1  0x00007ffff12ba2b3 in util_queue_thread_func
(input=input@entry=0x55555640b1f0) at ../src/util/u_queue.c:252
#2  0x00007ffff12b9c17 in impl_thrd_routine (p=<optimized out>) at
../src/../include/c11/threads_posix.h:87
#3  0x00007ffff68c1fa3 in start_thread (arg=<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šák <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 syscall
should be handled gracefully, for example by setting a signal handler to ignore
the SIGSYS signal.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4596 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel