On Fri, Jan 06, 2012 at 10:56:46AM -0800, Chase Douglas wrote:

On 01/06/2012 10:18 AM, Dmitry Torokhov wrote:

quoted

Hi Benjamin,

On Fri, Jan 06, 2012 at 07:00:22PM +0100, Benjamin Tissoires wrote:

quoted

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