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

[Jan Kiszka]

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?

Jan

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