From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSCeS-0000Om-Js for qemu-devel@nongnu.org; Wed, 09 May 2012 15:34:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SSCeQ-0004Xx-KU for qemu-devel@nongnu.org; Wed, 09 May 2012 15:34:20 -0400 Received: from goliath.siemens.de ([192.35.17.28]:22755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSCeQ-0004TT-As for qemu-devel@nongnu.org; Wed, 09 May 2012 15:34:18 -0400 Message-ID: <4FAAC6B2.7040009@siemens.com> Date: Wed, 09 May 2012 16:34:10 -0300 From: Jan Kiszka MIME-Version: 1.0 References: <4FAAC3A3.5040503@siemens.com> <4FAAC521.5000907@msgid.tls.msk.ru> In-Reply-To: <4FAAC521.5000907@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1.1] coroutine: Avoid ucontext usage on i386 Linux host List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: Kevin Wolf , Peter Maydell , Anthony Liguori , qemu-devel On 2012-05-09 16:27, Michael Tokarev wrote: > On 09.05.2012 23:21, Jan Kiszka wrote: >> On i386, glibc only saves/restores the signal mask via sigprocmask, >> excluding RT signal. A Linux bug in the compat version of this syscall >> corrupts the RT signal state, which will cause lockups of QEMU's VCPU >> threads. > > This should obviously be fixed in kernel, for benefit of all (not only > qemu), do you have any details here? compat_sys_sigprocmask reads 32-bit sigmask from user space, i.e. excluding RT signal, but calls sys_sigprocmask that takes a 64-bit sigset. So the RT signals are unblocked. I'm testing a simple patch ATM, will post it to LKML once this works. > >> Signed-off-by: Jan Kiszka >> --- >> >> I'm not sure where to fall back to. The existing code uses gthread, >> likely because it is the safer harbor. So I picked it as well. > > Can't we resort to the SIGUSR1 workaround for the time being, while > no RT signals are in actual use, and just have the time to let the > kernel side to fix the things up before some actual RTsig user will > emerge in qemu? I think it is a bit more conservative approach, > especially having in mind the minority of users this issue affects > (only 32/64 mixed environment). I'd favor for this variant, and > it looks like I'm the "main" 32/64bit user of qemu in this world :) Most conservative is definitely this patch, not switching to SIGUSR1, hoping that no other RT signal user shows up until current kernel are no longer in use. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux