[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1.1] coroutine: Avoid ucontext usage on i386 Lin

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 1.1] coroutine: Avoid ucontext usage on i386 Linux host
Date: Wed, 09 May 2012 16:57:03 -0300
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2012-05-09 16:48, Anthony Liguori wrote:
> On 05/09/2012 02:34 PM, Jan Kiszka wrote:
>> 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<address@hidden>
>>>> ---
>>>> 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.
> Sorry, how is using a totally different code path more conservative than 
> using a 
> different signal number?

If the gthread version is not safe to use, why do we fall back to it?

> Why would we even use an RT signal in the future?

As both SIGUSR1 and 2 are now in use?


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

reply via email to

[Prev in Thread] Current Thread [Next in Thread]