Re: [Qemu-devel] coroutine-ucontext broken for x86-32

[Anthony Liguori <aliguori@us.ibm.com>]

On 05/09/2012 12:25 PM, Jan Kiszka wrote:
> On 2012-05-09 14:17, Anthony Liguori wrote:
>> On 05/09/2012 06:38 AM, Jan Kiszka wrote:
>>> On 2012-05-09 08:15, Peter Maydell wrote:
>>>> On 9 May 2012 11:11, Kevin Wolf<kwolf@redhat.com>   wrote:
>>>>> Am 08.05.2012 21:35, schrieb Jan Kiszka:
>>>>>> I hunted down a fairly subtle corruption of the VCPU thread signal mask
>>>>>> in KVM mode when using the ucontext version of coroutines:
>>>>>>
>>>>>> coroutine_new calls getcontext, makecontext, swapcontext. Those
>>>>>> functions get/set also the signal mask of the caller. Unfortunately,
>>>>>> they only use the sigprocmask syscall on i386, not the rt_sigprocmask
>>>>>> version. So they do not properly save/restore the blocked RT signals,
>>>>>> namely our SIG_IPI - it becomes unblocke this way.
>>>>>
>>>>> If other coroutine backends work (sigaltstack?), we could try to detect
>>>>> the situation in configure and set the right default. Not sure what the
>>>>> condition is, glibc + i386?
>>>>
>>>> I don't think you can do a compile-time test for this short of
>>>> just disabling use of the ucontext code on all i386/Linux platforms.
>>>>
>>>> I think it's becoming increasingly obvious that the setcontext/getcontext
>>>> code path is not very well used and prone to nasty libc bugs. Trying
>>>> to implement coroutines in C is just a really bad idea and I think
>>>> we should be trying to reduce our use of them if we possibly can,
>>>> presumably by switching to actually using threads where we really
>>>> need the parallelism.
>>>
>>> I tend to agree.
>>>
>>> FWIW, sigaltstack works around the issue here, but I'm still looking s
>>> bit skeptical at its implementation.
>>
>> Is there any downside to using SIGUSR1?
>
> You mean for SIG_IPI? I don't think so. But the point is that the, well,
> limitation of ucontext will continue to break RT signals,

Yes, but we currently don't use RT signals, right?  So we could switch to 
SIGUSR1, fix the problem in glibc, and call it a day, no?

Regards,

Anthony Liguori

  and this in a
> very nasty way as only a specific setup is affected. I can't imagine we
> want this.
>
> Jan
>