Fix the following race:
Possible data race during read of size 8 at 0xA112510 by thread #6 Locks held: 1, at address 0x366B40 at 0x14C8B9: GetMaster (devices.c:2691) by 0x15CFC5: IsFloating (events.c:346) by 0x2B9554: miPointerGetScreen (mipointer.c:527) by 0x1A5136: xf86PostButtonEventM (xf86Xinput.c:1379) by 0x1A52BD: xf86PostButtonEvent (xf86Xinput.c:1345) by 0x485F45B: EvdevProcessEvent (in /usr/lib64/xorg/modules/input/evdev_drv.so) by 0x485FDAC: EvdevReadInput (in /usr/lib64/xorg/modules/input/evdev_drv.so) by 0x195427: xf86ReadInput (xf86Events.c:247) by 0x2CC113: InputReady (inputthread.c:180) by 0x2CE4EA: ospoll_wait (ospoll.c:657) by 0x2CC077: InputThreadDoWork (inputthread.c:369) by 0x484A336: mythread_wrapper (hg_intercepts.c:406) This conflicts with a previous write of size 8 by thread #1 Locks held: none at 0x14D2C6: AttachDevice (devices.c:2609) by 0x15CF85: ReattachToOldMaster (events.c:1457) by 0x1647DD: DeactivateKeyboardGrab (events.c:1700) by 0x25D7F1: ProcXIUngrabDevice (xigrabdev.c:169) by 0x2552AD: ProcIDispatch (extinit.c:398) by 0x155291: Dispatch (dispatch.c:479) by 0x158CBA: dix_main (main.c:276) by 0x143A3D: main (stubmain.c:34) Address 0xa112510 is 336 bytes inside a block of size 904 alloc'd at 0x4846571: calloc (vg_replace_malloc.c:1328) by 0x14A0B3: AddInputDevice (devices.c:260) by 0x1A31A0: xf86ActivateDevice (xf86Xinput.c:365) by 0x1A4549: xf86NewInputDevice (xf86Xinput.c:948) by 0x1A4B44: NewInputDeviceRequest (xf86Xinput.c:1090) by 0x1B81FE: device_added (udev.c:282) by 0x1B8516: config_udev_init (udev.c:439) by 0x1B7091: config_init (config.c:50) by 0x197970: InitInput (xf86Init.c:814) by 0x158C6B: dix_main (main.c:250) by 0x143A3D: main (stubmain.c:34) Block was alloc'd by thread #1
The steps to trigger the race are:
- Main thread does cleanup at mipointer.c:360 setting the slave device's miPointerPtr to null.
- Input thread use MIPOINTER in mipointer.c and get the slave's miPointerPtr = null.
- Main thread updates dev->master at devices.c:2632 (shown as line 2609 in trace above because of changes in master since the trace was captured).
- MIPOINTER would now return the master's miPointerPtr but the input thread already got the slave's miPointerPtr in step 2 and segfaults by null ptr deref.
Bug report with analysis: #1260 (closed)