[PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Henrik Rydberg]

This patch adds the ability to extract the MT slot state sequentially
via EVIOCGABS. The slot parameter is first selected by calling
EVIOCSABS with ABS_MT_SLOT as argument, followed by a set of EVIOCGABS
calls. The slot selection is local to the evdev client handler, and
does not affect the actual input state.

Cc: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
Hi Dmitry,

the first version of this patch was sent a long time ago (May 2010),
but was put on hold due to a lack of usecases. Now, it seems such a
case has arrived, in the X server (evdev). Some MT events may be much
less frequent than others (ABS_MT_ORIENTATION, for example), resulting
in wrong touch values being assumed after, say, an X restart.

I am not 100% in favor of this patch myself. Perhaps there should be a
more explicit mechanism for selecting slots, for instance.

The patch has been tested against both 3.2 and 3.1 stable.

Cheers,
Henrik

 drivers/input/evdev.c |   23 +++++++++++++++++++----
 1 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 4cf2534..4878e63 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -20,7 +20,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/input.h>
+#include <linux/input/mt.h>
 #include <linux/major.h>
 #include <linux/device.h>
 #include "input-compat.h"
@@ -46,6 +46,7 @@ struct evdev_client {
 	struct fasync_struct *fasync;
 	struct evdev *evdev;
 	struct list_head node;
+	int mt_slot;		/* used to extract MT events via EVIOC */
 	unsigned int bufsize;
 	struct input_event buffer[];
 };
@@ -621,6 +622,16 @@ static int evdev_handle_set_keycode_v2(struct input_dev *dev, void __user *p)
 	return input_set_keycode(dev, &ke);
 }
 
+static int evdev_get_abs_value(const struct evdev_client *client,
+			       const struct input_dev *dev, unsigned int code)
+{
+	if (code == ABS_MT_SLOT)
+		return client->mt_slot;
+	if (dev->mt && input_is_mt_axis(code))
+		return input_mt_get_value(&dev->mt[client->mt_slot], code);
+	return dev->absinfo[code].value;
+}
+
 static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 			   void __user *p, int compat_mode)
 {
@@ -757,6 +768,7 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 
 			t = _IOC_NR(cmd) & ABS_MAX;
 			abs = dev->absinfo[t];
+			abs.value = evdev_get_abs_value(client, dev, t);
 
 			if (copy_to_user(p, &abs, min_t(size_t,
 					size, sizeof(struct input_absinfo))))
@@ -782,9 +794,12 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 			if (size < sizeof(struct input_absinfo))
 				abs.resolution = 0;
 
-			/* We can't change number of reserved MT slots */
-			if (t == ABS_MT_SLOT)
-				return -EINVAL;
+			/* Set the MT slot to return through EVIOCGABS */
+			if (t == ABS_MT_SLOT) {
+				if (abs.value >= 0 && abs.value < dev->mtsize)
+					client->mt_slot = abs.value;
+				return 0;
+			}
 
 			/*
 			 * Take event lock to ensure that we are not
-- 
1.7.8.1

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Chase Douglas]

On 01/06/2012 07:16 AM, Henrik Rydberg wrote:
> This patch adds the ability to extract the MT slot state sequentially
> via EVIOCGABS. The slot parameter is first selected by calling
> EVIOCSABS with ABS_MT_SLOT as argument, followed by a set of EVIOCGABS
> calls. The slot selection is local to the evdev client handler, and
> does not affect the actual input state.
> 
> Cc: Chase Douglas <chase.douglas@canonical.com>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Dmitry,
> 
> the first version of this patch was sent a long time ago (May 2010),
> but was put on hold due to a lack of usecases. Now, it seems such a
> case has arrived, in the X server (evdev). Some MT events may be much
> less frequent than others (ABS_MT_ORIENTATION, for example), resulting
> in wrong touch values being assumed after, say, an X restart.
> 
> I am not 100% in favor of this patch myself. Perhaps there should be a
> more explicit mechanism for selecting slots, for instance.
> 
> The patch has been tested against both 3.2 and 3.1 stable.

To bolster the claim, I have been working on the X multitouch
implementation and a library on top of it, utouch-frame. I wrote a test
case that expects the proper sequence and values of events that
propagate from the kernel to the X input module, through utouch-frame.
It was during this testing that I noticed issues that could occur if we
don't know the current values of axes in each slot.

This patch does what is says, so I'm happy to review it positively
as-is. It doesn't require a new ioctl, which is a good thing :).

Reviewed-by: Chase Douglas <chase.douglas@canonical.com>

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Benjamin Tissoires]

Hi guys,
I read somewhere in the code of Android a comment in which they
complain about not being able to retrieve the slots states. So they
assume they are all at 0.
So this mechanism is good to have.
However, back in January 2011, Dmitry raised the problem that this
code was not thread safe.What happens if 2 applications ask for
different slots values (let say X.org and utouch-frame)?
One little comment in the patch:

On Fri, Jan 6, 2012 at 16:16, Henrik Rydberg <rydberg@euromail.se> wrote:
> This patch adds the ability to extract the MT slot state sequentially
> via EVIOCGABS. The slot parameter is first selected by calling
> EVIOCSABS with ABS_MT_SLOT as argument, followed by a set of EVIOCGABS
> calls. The slot selection is local to the evdev client handler, and
> does not affect the actual input state.
>
> Cc: Chase Douglas <chase.douglas@canonical.com>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Dmitry,
>
> the first version of this patch was sent a long time ago (May 2010),
> but was put on hold due to a lack of usecases. Now, it seems such a
> case has arrived, in the X server (evdev). Some MT events may be much
> less frequent than others (ABS_MT_ORIENTATION, for example), resulting
> in wrong touch values being assumed after, say, an X restart.
>
> I am not 100% in favor of this patch myself. Perhaps there should be a
> more explicit mechanism for selecting slots, for instance.
>
> The patch has been tested against both 3.2 and 3.1 stable.
>
> Cheers,
> Henrik
>
>  drivers/input/evdev.c |   23 +++++++++++++++++++----
>  1 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index 4cf2534..4878e63 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -20,7 +20,7 @@
>  #include <linux/slab.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
> -#include <linux/input.h>
> +#include <linux/input/mt.h>
>  #include <linux/major.h>
>  #include <linux/device.h>
>  #include "input-compat.h"
> @@ -46,6 +46,7 @@ struct evdev_client {
>        struct fasync_struct *fasync;
>        struct evdev *evdev;
>        struct list_head node;
> +       int mt_slot;            /* used to extract MT events via EVIOC */
>        unsigned int bufsize;
>        struct input_event buffer[];
>  };
> @@ -621,6 +622,16 @@ static int evdev_handle_set_keycode_v2(struct input_dev *dev, void __user *p)
>        return input_set_keycode(dev, &ke);
>  }
>
> +static int evdev_get_abs_value(const struct evdev_client *client,
> +                              const struct input_dev *dev, unsigned int code)
> +{
> +       if (code == ABS_MT_SLOT)
> +               return client->mt_slot;

This is wrong.
Returning the current asked slot (by someone in the user-space) will
break the EVIOCGABS mechanism:
Asking for the current active slot (of the device) is allowed and
should be done by every application that starts to talk to evdev. As
the slot is state-full, it's not updated between touches and nothing
guarantees that it's to a null state, which often happens when X.org
or the app restarts.

Cheers,
Benjamin

> +       if (dev->mt && input_is_mt_axis(code))
> +               return input_mt_get_value(&dev->mt[client->mt_slot], code);
> +       return dev->absinfo[code].value;
> +}
> +
>  static long evdev_do_ioctl(struct file *file, unsigned int cmd,
>                           void __user *p, int compat_mode)
>  {
> @@ -757,6 +768,7 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
>
>                        t = _IOC_NR(cmd) & ABS_MAX;
>                        abs = dev->absinfo[t];
> +                       abs.value = evdev_get_abs_value(client, dev, t);
>
>                        if (copy_to_user(p, &abs, min_t(size_t,
>                                        size, sizeof(struct input_absinfo))))
> @@ -782,9 +794,12 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
>                        if (size < sizeof(struct input_absinfo))
>                                abs.resolution = 0;
>
> -                       /* We can't change number of reserved MT slots */
> -                       if (t == ABS_MT_SLOT)
> -                               return -EINVAL;
> +                       /* Set the MT slot to return through EVIOCGABS */
> +                       if (t == ABS_MT_SLOT) {
> +                               if (abs.value >= 0 && abs.value < dev->mtsize)
> +                                       client->mt_slot = abs.value;
> +                               return 0;
> +                       }
>
>                        /*
>                         * Take event lock to ensure that we are not
> --
> 1.7.8.1
>
> --
> 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
--
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

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Dmitry Torokhov]

Hi Benjamin,

On Fri, Jan 06, 2012 at 07:00:22PM +0100, Benjamin Tissoires wrote:
> Hi guys,
> I read somewhere in the code of Android a comment in which they
> complain about not being able to retrieve the slots states. So they
> assume they are all at 0.
> So this mechanism is good to have.
> However, back in January 2011, Dmitry raised the problem that this
> code was not thread safe.What happens if 2 applications ask for
> different slots values (let say X.org and utouch-frame)?

2 different processes should be fine; the problem would be if 2 threads
of the same process share the same file descriptor. So far the rest of
evdev copes just fine with multiple threads using the same fd (all
operations are atomic in this regard), setting ABS_MT_SLOT before
fetching the state break this property.

Thanks.

-- 
Dmitry

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Henrik Rydberg]

> However, back in January 2011, Dmitry raised the problem that this
> code was not thread safe.

I had forgotten about that respin, thanks for the reminder.

> What happens if 2 applications ask for
> different slots values (let say X.org and utouch-frame)?

As already pointed out, nothing bad.

[...]
> Asking for the current active slot (of the device) is allowed and
> should be done by every application that starts to talk to evdev.

Right you are. The hunk can be removed at the cost of loss of
symmetry, but then it starts to look really ugly. ;-)

Cheers,
Henrik

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Henrik Rydberg]

> 2 different processes should be fine; the problem would be if 2 threads
> of the same process share the same file descriptor. So far the rest of
> evdev copes just fine with multiple threads using the same fd (all
> operations are atomic in this regard), setting ABS_MT_SLOT before
> fetching the state break this property.

Are we talking about the need for a per-client mutex, or something
more subtle, like introducing indirect coupling between threads
through per-client states? The former ought to be easily remedied.

Henrik

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Chase Douglas]

On 01/06/2012 10:18 AM, Dmitry Torokhov wrote:
> Hi Benjamin,
> 
> On Fri, Jan 06, 2012 at 07:00:22PM +0100, Benjamin Tissoires wrote:
>> Hi guys,
>> I read somewhere in the code of Android a comment in which they
>> complain about not being able to retrieve the slots states. So they
>> assume they are all at 0.
>> So this mechanism is good to have.
>> However, back in January 2011, Dmitry raised the problem that this
>> code was not thread safe.What happens if 2 applications ask for
>> different slots values (let say X.org and utouch-frame)?
> 
> 2 different processes should be fine; the problem would be if 2 threads
> of the same process share the same file descriptor. So far the rest of
> evdev copes just fine with multiple threads using the same fd (all
> operations are atomic in this regard), setting ABS_MT_SLOT before
> fetching the state break this property.

How is this any different than two threads trying to set a different
property, like the fuzz factor of an axis? This seems like something
that should be guarded by a lock in userspace, essentially.

-- Chase

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Henrik Rydberg]

On Fri, Jan 06, 2012 at 07:55:44PM +0100, Henrik Rydberg wrote:
> > 2 different processes should be fine; the problem would be if 2 threads
> > of the same process share the same file descriptor. So far the rest of
> > evdev copes just fine with multiple threads using the same fd (all
> > operations are atomic in this regard), setting ABS_MT_SLOT before
> > fetching the state break this property.
> 
> Are we talking about the need for a per-client mutex, or something
> more subtle, like introducing indirect coupling between threads
> through per-client states? The former ought to be easily remedied.

Ok, maybe not to so easy after all, which probably answers my own
question. Looks like a EVIOCGMTSLOT, taking both slot and event code
as argument, would be the cleaner route to take. Another ioctl, how do we
feel about that?

Henrik

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Chase Douglas]

On 01/06/2012 11:18 AM, Henrik Rydberg wrote:
> On Fri, Jan 06, 2012 at 07:55:44PM +0100, Henrik Rydberg wrote:
>>> 2 different processes should be fine; the problem would be if 2 threads
>>> of the same process share the same file descriptor. So far the rest of
>>> evdev copes just fine with multiple threads using the same fd (all
>>> operations are atomic in this regard), setting ABS_MT_SLOT before
>>> fetching the state break this property.
>>
>> Are we talking about the need for a per-client mutex, or something
>> more subtle, like introducing indirect coupling between threads
>> through per-client states? The former ought to be easily remedied.
> 
> Ok, maybe not to so easy after all, which probably answers my own
> question. Looks like a EVIOCGMTSLOT, taking both slot and event code
> as argument, would be the cleaner route to take. Another ioctl, how do we
> feel about that?

What's the problem with userspace locking?

-- Chase

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Henrik Rydberg]

> > Ok, maybe not to so easy after all, which probably answers my own
> > question. Looks like a EVIOCGMTSLOT, taking both slot and event code
> > as argument, would be the cleaner route to take. Another ioctl, how do we
> > feel about that?
> 
> What's the problem with userspace locking?

The idea was to get by without it.

Regarding ioctls, it does not seem realizable due to ioctl number
exhaustion. A sysfs interface for all EV_ABS and per-slot MT values
could be a more future-proof alternative.

Henrik

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Dmitry Torokhov]

On Fri, Jan 06, 2012 at 10:56:46AM -0800, Chase Douglas wrote:
> On 01/06/2012 10:18 AM, Dmitry Torokhov wrote:
> > Hi Benjamin,
> > 
> > On Fri, Jan 06, 2012 at 07:00:22PM +0100, Benjamin Tissoires wrote:
> >> Hi guys,
> >> I read somewhere in the code of Android a comment in which they
> >> complain about not being able to retrieve the slots states. So they
> >> assume they are all at 0.
> >> So this mechanism is good to have.
> >> However, back in January 2011, Dmitry raised the problem that this
> >> code was not thread safe.What happens if 2 applications ask for
> >> different slots values (let say X.org and utouch-frame)?
> > 
> > 2 different processes should be fine; the problem would be if 2 threads
> > of the same process share the same file descriptor. So far the rest of
> > evdev copes just fine with multiple threads using the same fd (all
> > operations are atomic in this regard), setting ABS_MT_SLOT before
> > fetching the state break this property.
> 
> How is this any different than two threads trying to set a different
> property, like the fuzz factor of an axis? This seems like something
> that should be guarded by a lock in userspace, essentially.

>From kernel POV both operations succeed and produce consistent reults.
Consider EVIOCSABS when one thread using the same FD sets range 0-100
and another 200-1000. At no time in the kernel we get to state of
min = 200 and max = 1000. In the end we'll end up with either 0-100 or
200-1000 but not mix of both. So the kernle state is internally
consistent.

With proposed solution one client may request data for slot 2 but
instead get info for slot 5 if another client manages to slide in.

-- 
Dmitry

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Dmitry Torokhov]

On Fri, Jan 06, 2012 at 08:48:15PM +0100, Henrik Rydberg wrote:
> > > Ok, maybe not to so easy after all, which probably answers my own
> > > question. Looks like a EVIOCGMTSLOT, taking both slot and event code
> > > as argument, would be the cleaner route to take. Another ioctl, how do we
> > > feel about that?
> > 
> > What's the problem with userspace locking?
> 
> The idea was to get by without it.
> 
> Regarding ioctls, it does not seem realizable due to ioctl number
> exhaustion.

I am prettu sure we cabn spare 1 ioctl number. We just need to pass slot
number not as part of ioctl number but in data instead. Like
EVIOCGKEYCODE works.

-- 
Dmitry

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Dmitry Torokhov]

On Fri, Jan 06, 2012 at 11:34:06AM -0800, Chase Douglas wrote:
> On 01/06/2012 11:18 AM, Henrik Rydberg wrote:
> > On Fri, Jan 06, 2012 at 07:55:44PM +0100, Henrik Rydberg wrote:
> >>> 2 different processes should be fine; the problem would be if 2 threads
> >>> of the same process share the same file descriptor. So far the rest of
> >>> evdev copes just fine with multiple threads using the same fd (all
> >>> operations are atomic in this regard), setting ABS_MT_SLOT before
> >>> fetching the state break this property.
> >>
> >> Are we talking about the need for a per-client mutex, or something
> >> more subtle, like introducing indirect coupling between threads
> >> through per-client states? The former ought to be easily remedied.
> > 
> > Ok, maybe not to so easy after all, which probably answers my own
> > question. Looks like a EVIOCGMTSLOT, taking both slot and event code
> > as argument, would be the cleaner route to take. Another ioctl, how do we
> > feel about that?
> 
> What's the problem with userspace locking?

It relies on userspace? ;)

-- 
Dmitry

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Chase Douglas]

On 01/06/2012 11:58 AM, Dmitry Torokhov wrote:
> On Fri, Jan 06, 2012 at 10:56:46AM -0800, Chase Douglas wrote:
>> On 01/06/2012 10:18 AM, Dmitry Torokhov wrote:
>>> Hi Benjamin,
>>>
>>> On Fri, Jan 06, 2012 at 07:00:22PM +0100, Benjamin Tissoires wrote:
>>>> Hi guys,
>>>> I read somewhere in the code of Android a comment in which they
>>>> complain about not being able to retrieve the slots states. So they
>>>> assume they are all at 0.
>>>> So this mechanism is good to have.
>>>> However, back in January 2011, Dmitry raised the problem that this
>>>> code was not thread safe.What happens if 2 applications ask for
>>>> different slots values (let say X.org and utouch-frame)?
>>>
>>> 2 different processes should be fine; the problem would be if 2 threads
>>> of the same process share the same file descriptor. So far the rest of
>>> evdev copes just fine with multiple threads using the same fd (all
>>> operations are atomic in this regard), setting ABS_MT_SLOT before
>>> fetching the state break this property.
>>
>> How is this any different than two threads trying to set a different
>> property, like the fuzz factor of an axis? This seems like something
>> that should be guarded by a lock in userspace, essentially.
> 
> From kernel POV both operations succeed and produce consistent reults.
> Consider EVIOCSABS when one thread using the same FD sets range 0-100
> and another 200-1000. At no time in the kernel we get to state of
> min = 200 and max = 1000. In the end we'll end up with either 0-100 or
> 200-1000 but not mix of both. So the kernle state is internally
> consistent.

I don't see how modifying the slot requested could ever get the kernel
into an inconsistent state.

> With proposed solution one client may request data for slot 2 but
> instead get info for slot 5 if another client manages to slide in.

You can do the same thing with EVIOCSABS. If you don't do proper locking
and handling, two threads can assume they wrote a value to evdev and it
was successful, when in reality only the second thread to make the call
has any effect.

I know there's a slight distinction between these two scenarios, but my
point is that if you are doing multithreaded evdev reading from the same
evdev fd, you are asking for trouble and you need to be careful. That
even goes for modifying any of the other state through EVIOCSABS from
multiple processes. And really, how many programs are out there reading
from the same evdev fd in multiple threads. I'd wager a fair amount of
money the answer is 0.

-- Chase

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Henrik Rydberg]

On Fri, Jan 06, 2012 at 12:02:40PM -0800, Dmitry Torokhov wrote:
> On Fri, Jan 06, 2012 at 08:48:15PM +0100, Henrik Rydberg wrote:
> > > > Ok, maybe not to so easy after all, which probably answers my own
> > > > question. Looks like a EVIOCGMTSLOT, taking both slot and event code
> > > > as argument, would be the cleaner route to take. Another ioctl, how do we
> > > > feel about that?
> > > 
> > > What's the problem with userspace locking?
> > 
> > The idea was to get by without it.
> > 
> > Regarding ioctls, it does not seem realizable due to ioctl number
> > exhaustion.
> 
> I am prettu sure we cabn spare 1 ioctl number. We just need to pass slot
> number not as part of ioctl number but in data instead. Like
> EVIOCGKEYCODE works.

Right, thanks. Perhaps we could even pass it as result data -
returning all mt data in one go? With the purpose being to capture the
full MT state, it ought to be both simpler and faster.

Henrik

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Dmitry Torokhov]

On Fri, Jan 06, 2012 at 12:09:36PM -0800, Chase Douglas wrote:
> On 01/06/2012 11:58 AM, Dmitry Torokhov wrote:
> > On Fri, Jan 06, 2012 at 10:56:46AM -0800, Chase Douglas wrote:
> >> On 01/06/2012 10:18 AM, Dmitry Torokhov wrote:
> >>> Hi Benjamin,
> >>>
> >>> On Fri, Jan 06, 2012 at 07:00:22PM +0100, Benjamin Tissoires wrote:
> >>>> Hi guys,
> >>>> I read somewhere in the code of Android a comment in which they
> >>>> complain about not being able to retrieve the slots states. So they
> >>>> assume they are all at 0.
> >>>> So this mechanism is good to have.
> >>>> However, back in January 2011, Dmitry raised the problem that this
> >>>> code was not thread safe.What happens if 2 applications ask for
> >>>> different slots values (let say X.org and utouch-frame)?
> >>>
> >>> 2 different processes should be fine; the problem would be if 2 threads
> >>> of the same process share the same file descriptor. So far the rest of
> >>> evdev copes just fine with multiple threads using the same fd (all
> >>> operations are atomic in this regard), setting ABS_MT_SLOT before
> >>> fetching the state break this property.
> >>
> >> How is this any different than two threads trying to set a different
> >> property, like the fuzz factor of an axis? This seems like something
> >> that should be guarded by a lock in userspace, essentially.
> > 
> > From kernel POV both operations succeed and produce consistent reults.
> > Consider EVIOCSABS when one thread using the same FD sets range 0-100
> > and another 200-1000. At no time in the kernel we get to state of
> > min = 200 and max = 1000. In the end we'll end up with either 0-100 or
> > 200-1000 but not mix of both. So the kernle state is internally
> > consistent.
> 
> I don't see how modifying the slot requested could ever get the kernel
> into an inconsistent state.

It may cause client get data that it did not request. In other worse it
kernel may supply wrong data to the caller.

> 
> > With proposed solution one client may request data for slot 2 but
> > instead get info for slot 5 if another client manages to slide in.
> 
> You can do the same thing with EVIOCSABS. If you don't do proper locking
> and handling, two threads can assume they wrote a value to evdev and it
> was successful, when in reality only the second thread to make the call
> has any effect.

As with pretty much any other resource; but there is a reason we have
atomic variables and operations. The distinction is that both operations
carried out completely and consistently.

> 
> I know there's a slight distinction between these two scenarios, but my
> point is that if you are doing multithreaded evdev reading from the same
> evdev fd, you are asking for trouble and you need to be careful. That
> even goes for modifying any of the other state through EVIOCSABS from
> multiple processes. And really, how many programs are out there reading
> from the same evdev fd in multiple threads. I'd wager a fair amount of
> money the answer is 0.

I am really not concerned about what userspace might do - I've looked at
enough code to see all kinds of weird stuff. My task is to make sure
that kernel interface is sane and since it is userspace ABI matter I
want to be extra careful.

Thanks.

-- 
Dmitry

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Dmitry Torokhov]

On Fri, Jan 06, 2012 at 09:14:34PM +0100, Henrik Rydberg wrote:
> On Fri, Jan 06, 2012 at 12:02:40PM -0800, Dmitry Torokhov wrote:
> > On Fri, Jan 06, 2012 at 08:48:15PM +0100, Henrik Rydberg wrote:
> > > > > Ok, maybe not to so easy after all, which probably answers my own
> > > > > question. Looks like a EVIOCGMTSLOT, taking both slot and event code
> > > > > as argument, would be the cleaner route to take. Another ioctl, how do we
> > > > > feel about that?
> > > > 
> > > > What's the problem with userspace locking?
> > > 
> > > The idea was to get by without it.
> > > 
> > > Regarding ioctls, it does not seem realizable due to ioctl number
> > > exhaustion.
> > 
> > I am prettu sure we cabn spare 1 ioctl number. We just need to pass slot
> > number not as part of ioctl number but in data instead. Like
> > EVIOCGKEYCODE works.
> 
> Right, thanks. Perhaps we could even pass it as result data -
> returning all mt data in one go? With the purpose being to capture the
> full MT state, it ought to be both simpler and faster.

Yes, if caller passes buffer size and buffer address we can return all
data in one go. We just need to make _really sure_ we are using 32/64 bit
safe interface.

-- 
Dmitry

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Henrik Rydberg]

On Fri, Jan 06, 2012 at 12:23:42PM -0800, Dmitry Torokhov wrote:
> On Fri, Jan 06, 2012 at 09:14:34PM +0100, Henrik Rydberg wrote:
> > On Fri, Jan 06, 2012 at 12:02:40PM -0800, Dmitry Torokhov wrote:
> > > On Fri, Jan 06, 2012 at 08:48:15PM +0100, Henrik Rydberg wrote:
> > > > > > Ok, maybe not to so easy after all, which probably answers my own
> > > > > > question. Looks like a EVIOCGMTSLOT, taking both slot and event code
> > > > > > as argument, would be the cleaner route to take. Another ioctl, how do we
> > > > > > feel about that?
> > > > > 
> > > > > What's the problem with userspace locking?
> > > > 
> > > > The idea was to get by without it.
> > > > 
> > > > Regarding ioctls, it does not seem realizable due to ioctl number
> > > > exhaustion.
> > > 
> > > I am prettu sure we cabn spare 1 ioctl number. We just need to pass slot
> > > number not as part of ioctl number but in data instead. Like
> > > EVIOCGKEYCODE works.
> > 
> > Right, thanks. Perhaps we could even pass it as result data -
> > returning all mt data in one go? With the purpose being to capture the
> > full MT state, it ought to be both simpler and faster.
> 
> Yes, if caller passes buffer size and buffer address we can return all
> data in one go. We just need to make _really sure_ we are using 32/64 bit
> safe interface.

Yep. Great, I think we are getting closer. Will look into it.

Thanks,
Henrik

Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state

[Chase Douglas]

On 01/06/2012 12:17 PM, Dmitry Torokhov wrote:
> On Fri, Jan 06, 2012 at 12:09:36PM -0800, Chase Douglas wrote:
>> I know there's a slight distinction between these two scenarios, but my
>> point is that if you are doing multithreaded evdev reading from the same
>> evdev fd, you are asking for trouble and you need to be careful. That
>> even goes for modifying any of the other state through EVIOCSABS from
>> multiple processes. And really, how many programs are out there reading
>> from the same evdev fd in multiple threads. I'd wager a fair amount of
>> money the answer is 0.
> 
> I am really not concerned about what userspace might do - I've looked at
> enough code to see all kinds of weird stuff. My task is to make sure
> that kernel interface is sane and since it is userspace ABI matter I
> want to be extra careful.

Evdev by its very nature is thread unsafe. There's no way to atomically
retrieve an event frame including all the new values up through the next
EV_SYN. That's the meat and potatoes of evdev. If the base of an API is
thread-unsafe, it does very little to add thread safety to functions
surrounding it.

If you want to make a line of demarcation to say that evdev reads are
not thread-safe, but ioctls are, then that makes a slight bit of
technical sense. However, it still seems like a fools errand to me,
because no one will ever make a multithreaded program that opens an
evdev device, accesses its ioctls through multiple threads, while never
reading from the evdev fd. If for some reason someone actually does
this, all they need is a simple mutex.

I really think this is a waste of time when Henrik's patch is ready to
go, is small and self contained, and meets everyone's needs. But this is
the last I'll speak of it.

-- Chase