(In reply to Daniel P. Berrange from comment #3) > (In reply to Ahzo from comment #2) > > To check for the availability of the syscall, one can try it in a child > > process and see if the child is terminated by a signal, e.g. like this: > > Afraid not, QEMU's seccomp filter blocks use of fork() too :-)
Maybe it should, at least when using the spawn=deny option, but currently it doesn't. That option only blocks the fork, vfork and execve syscalls, but glibc's fork() function uses the clone syscall, and thus continues to work. However, that behavior might be different when using other C library implementations, so it wouldn't be correct to rely on this. One could use clone() instead of fork(), but future versions of qemu might block the clone syscall, as well. Unfortunately, I'm not aware of a proper solution for this bug short of adding a new API to the kernel. -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1815889/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
