hid-magicmouse driver race condition (second try)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Resending as the first email bounced.
--------
Folks,
   There is a race condition in hid-magicmouse driver that I am
encountering. In the probe function, we call magicmouse_setup_input
after hid_hw_start which calls
hidinput_connect.

So if a userspace thread scans "/dev" to see if there is a new input
device and on seeing the new magicmouse device added, makes the ioctl
call EVCIOGBIT for EV_ABS or EV_KEY or any other type it will get
wrong values as magicmouse_setup_input has not been called yet.

So these keybits will change under the hood for the userspace program
on an open file descriptor.

I am able to reproduce this race condition easily. To verify the
above, as a hack, I called magicmouse_setup_input just before calling
input_register_device in hidp_connect and things were fine.

We were not using hidp-input parser but in the following commit we
moved to it which introduced the race condition:

commit 64eb105d7f92fa48798106ac0d8bf17668eb2524
Author: Michael Poole <mdpoole@xxxxxxxxxxx>
Date:   Fri Sep 24 13:58:18 2010 +0200

    HID: magicmouse: Use hid-input parsing rather than bypassing it

Any pointers for a clean fix ? Do we want to add a new field to
hid_driver structure so that we can use it to call from hid-input to
indicate parsing is done before the input device is registered ?

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux