Re: [Qemu-devel] [PATCH 1/3] coroutine: adding sigaltstack method (.c source)

[Stefan Hajnoczi]

On Tue, Feb 14, 2012 at 1:21 PM, Alex Barcelo <address@hidden> wrote:
> On Tue, Feb 14, 2012 at 13:20, Stefan Hajnoczi <address@hidden> wrote:
>> On Tue, Feb 14, 2012 at 11:53 AM, Alex Barcelo <address@hidden> wrote:
>>> On Tue, Feb 14, 2012 at 10:24, Stefan Hajnoczi <address@hidden> wrote:
>>>> (...)
>>>> What happens when a vcpu thread creates a coroutine while another QEMU
>>>> thread raises SIG_IPI?  The SIG_IPI will be handled on the alternate
>>>> signal stack
>>>
>>> mmm no, it won't. The sigaction is set for the SIGUSR1 only (yes I
>>> have to change it to sigusr2, the V2 will have this changed). And only
>>> this signal will be handled on an alternate stack (the sa.sa_flags is
>>> the responsible).
>>>
>>> I'm not really sure about that, did I miss something?
>>
>> What I meant is that there are other signals handlers installed and
>> the signals will be unblocked between the time when sigsuspend() has
>> returned and before sigaltstack(NULL, &ss) is executed.  This seems
>> like a race condition to me.
>
> But nobody (in qemu) uses sa.sa_flags ONSTACK, so I see no problem. If
> a signal is delivered, it will be attended as it should. If there is
> some other sigaltstack (I looked for it, and found nothing) then you
> are right. But if no other signal uses sigaltstack, then there is no
> race condition between the sigaltstack and the sigsuspend. And we only
> use a signal that should not be used anywhere else (I have to change
> that, seems that SIGUSR1 is being used in some point). So no conflict
> here.
>
> Have I understood you? I'm not sure if this is what you were talking
> about... if not, please, explain a bit more the race condition and the
> exact problem.

No, you are right.  It's not a problem because SA_ONSTACK isn't used
elsewhere.  Sorry, I missed that you need to set it explicitly on a
per-signal basis.

There's no issue with other signals here.

Stefan