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 [off-list ref]
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
Hello,
On Thu, Sep 15, 2011 at 5:28 PM, Jaikumar Ganesh [off-list ref] wrote:
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 [off-list ref]
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 ?
I had a look at the hid-apple.c driver which also has a setup_input function.
But that function is called inside input_mapping - so that gets called
every single time input_mapping is called.
That will fix this issue too, but seems like an overkill to call
magicmouse_setup_input every single time in input_mapping.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Michael Poole <hidden> Date: 2011-09-16 19:30:12
On Fri, Sep 16, 2011 at 3:15 PM, Jaikumar Ganesh [off-list ref] wrote:
Hello,
On Thu, Sep 15, 2011 at 5:28 PM, Jaikumar Ganesh [off-list ref] wrote:
quoted
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 [off-list ref]
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 ?
I had a look at the hid-apple.c driver which also has a setup_input function.
But that function is called inside input_mapping - so that gets called
every single time input_mapping is called.
That will fix this issue too, but seems like an overkill to call
magicmouse_setup_input every single time in input_mapping.
Perhaps it is worth doing that, but adding a flag so that the bulk of
magicmouse_setup_input() only runs once.
(I can write and test a patch on Monday, once I get network access at home.)
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
On Fri, Sep 16, 2011 at 12:23 PM, Michael Poole [off-list ref] wrote:
On Fri, Sep 16, 2011 at 3:15 PM, Jaikumar Ganesh [off-list ref] wrote:
quoted
Hello,
On Thu, Sep 15, 2011 at 5:28 PM, Jaikumar Ganesh [off-list ref] wrote:
quoted
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 [off-list ref]
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 ?
I had a look at the hid-apple.c driver which also has a setup_input function.
But that function is called inside input_mapping - so that gets called
every single time input_mapping is called.
That will fix this issue too, but seems like an overkill to call
magicmouse_setup_input every single time in input_mapping.
Perhaps it is worth doing that, but adding a flag so that the bulk of
magicmouse_setup_input() only runs once.
I had a patch already ready with this flag, just sent to the list.
Have referenced this discussion.
(I can write and test a patch on Monday, once I get network access at home.)
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html