Mouse driver + VT switch [patch]

[Matthias Hopf]

I just found a rare race condition. It apparently only happens with an
fbdev server, PS/2 mice, and the only environment to happen seems to be
the test server functionality of SaX2. If you select it, a secondary
server with the new configuration is started. If you now select the Save
button on the test screen with the mouse (and not the keyboard), the
original fbdev server will / might segfault:

#0  0x080dfe49 in XisbBlockDuration (b=0x0, block_duration=-1) at xisb.c:178
#1  0xb7f24072 in MouseReadInput (pInfo=0x8201628) at mouse.c:1176
#2  0x080c054a in xf86SigioReadInput (fd=12, closure=0x8201628) at xf86Events.c:1212
#3  0x080aa5a1 in xf86SIGIO (sig=29) at ./../shared/sigio.c:113
#4  <signal handler called>
#5  0xb7f3c410 in ?? ()
#6  0xbf97fa78 in ?? ()
#7  0x00000000 in ?? ()

Looks like an SIGIO is received during mouse reopen, though I'm not 100%
sure how this can happen. As always with race conditions, if running the
Xserver in the debugger and having any watchpoints, the issue doesn't
surface any longer.

The applied patch checks the validity of the mouse driver before doing
anything. While in principle it has no bad side effects, I'm a bit
reluctant of applying it upstream, as it might obscure the real issue.
I'm also unsure whether checking (fd) is enough, as there still might be
a small race in MouseProc(OPEN), as fd is assigned first, and buffer
allocated later.

The whole history of this bug is in
https://bugzilla.novell.com/show_bug.cgi?id=219946

What d'ya think?

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mouse-readinput.diff
Type: text/x-patch
Size: 426 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20061117/6958b928/attachment.bin>