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

[Chase Douglas <chase.douglas@canonical.com>]

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