[PATCH] os: don't unconditionally unblock SIGIO in OsReleaseSignals()
Jeremy Huddleston Sequoia
jeremyhu at apple.com
Mon Aug 6 09:57:42 PDT 2012
On Aug 5, 2012, at 23:18, Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> Overall, this change seems very fragile.
>>
>> OsReleaseSIGIO and OsBlockSIGIO are well balanced. I think a safer fix
>> would be to change OsReleaseSignals().
>
> unfortunately, the problem is not with OsReleaseSignals(), the problem is
> OsBlockSIGIO(), which only looks balanced. when OsBlockSIGIO() is called
> from within the signal handler, SIGIO is already in the sigprocmask, and
> that must not be undone by the matching OsReleaseSIGIO(), even if the count
> reaches zero.
>
> For all other signals, this works because we remember the mask and re-apply
> it. For SIGIO, it is simply unblocked. My patch would simply align the sigio
> code with the other code, the functions are largely identical after.
>
>> void
>> OsReleaseSignals(void)
>> {
>> #ifdef SIG_BLOCK
>> if (--BlockedSignalCount == 0) {
>> sigprocmask(SIG_SETMASK, &PreviousSignalMask, 0);
>>
>> #ifdef SIGIO
>> OsReleaseSIGIO();
>
> with this code, you'd get a SIGIO here, leading to the same bug.
Gah... yeah... blech...
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu at apple.com>
Although I am 90% certain this is going to come back and bite us some day...
More information about the xorg-devel
mailing list