[PATCH xserver] xfree86: lock input during PreInit

[Peter Hutterer]

This is a problem for the libinput driver that uses the same context across
multiple devices. The driver may be halfway through setting up an input device
(and the only way to do so is to add it to libinput) when the input thread
comes in an reads events. This then causes mayhem when data is dereferenced
that hasn't been set up yet.

In my case the cause was the call to libinput_path_remove_device() inside
preinit racing with evdev_dispatch_device() handling of ENODEV. The sequence
was:
- thread 2 gets an event and calls evdev_dispatch_device()
- thread 1 calls libinput_path_remove_device() which sets the device->source
  to NULL
- thread 2 reads from the fd, gets ENODEV and now removes the device->source,
  dereferencing the null-pointer

This is the one I could reproduce the most, but there are other potential
pitfalls that affect any driver that uses the same fd for multiple devices.
Avoid all this and wrap PreInit into the lock.

Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
---
 hw/xfree86/common/xf86Xinput.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 054eb3e..6359e37 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -926,7 +926,9 @@ xf86NewInputDevice(InputInfoPtr pInfo, DeviceIntPtr *pdev, BOOL enable)
 
     xf86AddInput(drv, pInfo);
 
+    input_lock();
     rval = drv->PreInit(drv, pInfo, 0);
+    input_unlock();
 
     if (rval != Success) {
         xf86Msg(X_ERROR, "PreInit returned %d for \"%s\"\n", rval, pInfo->name);
-- 
2.7.4