[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