Hi Dmitry On Thu, Mar 28, 2013 at 6:06 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Thu, Mar 28, 2013 at 01:49:24AM +0100, David Herrmann wrote: >> + spin_lock_irq(&dev->event_lock); >> + spin_lock(&client->buffer_lock); >> + >> + ret = bits_to_user(bits, max, size, p, compat); > > This copies data to userspace and thus may sleep. You can not hold spinlocks > here. > > I think you need to collect the data, flush the events and then try > copying the data out. If we fail on copying data out - too bad. Maybe we > can stuff SYN_DROPPED in the queue, but it is not really necessary. Ugh, I need to turn on CONFIG_DEBUG_ATOMIC_SLEEP again. Thanks for catching it. I will allocate a temporary buffer and queue SYN_DROPPED if the copy to userspace fails after that. While we are at it, I stumbled across bits_to_user()+CONFIG_COMPAT+LITTLE_ENDIAN. How is that supposed to work? If sizeof(compat_long_t) == 4 and sizeof(long) == 8, we end up splitting each key-state across two compat_long_t entries of the user. Maybe I'm just missing something, but I think we cannot special-case little-endian here. Could you have a look? And I have a small helper to test EVIOCGKEY+flush. Should I add it to the new kernel test-suite? Thanks David -- 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
