Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 28 Nov 2003 16:37:28 +0100 | From | Pavel Machek <> | Subject | insunficient locking in input.c (?) |
| |
Hi!
It seems to me some more locking is needed:
1) input_event() seems to be called from both keyboard interupt and from timer. That makes it pretty nasty beast.
It does:
... list_for_each_entry(handle, &dev->h_list, d_node) if (handle->open) handle->handler->event(handle, type, code, value); ...
while input_unregister_handler could be running (on other CPU?)
void input_unregister_handler(struct input_handler *handler) { struct list_head * node, * next;
list_for_each_safe(node, next, &handler->h_list) { struct input_handle * handle = to_handle_h(node); list_del_init(&handle->h_node); list_del_init(&handle->d_node); handler->disconnect(handle); }
I guess that some locking around these lists is needed.
2) input_event() is called from both keyboard interupt and from timer. That makes it behave pretty badly w.r.t. low-level handlers. I think that you can have one low-level handler running two times concurrently.
There's no locking preventing that. AFAICS autorepeat timer can tick once more after key is released, which is normally not a problem, but if key is pressed while that, it looks to me like there can be normal key down and autorepeat entering input_event() concurrently, which then calls low-level handler (for example kbd_keycode) concurrently. kbd_keycode() certainly is not written to handle _that_.
Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |