input: evdev: Dynamic buffers (rev4)
in [Kernel]
|
From: Chase Douglas on 10 Jun 2010 10:30 On Sat, 2010-06-05 at 13:04 +0200, Henrik Rydberg wrote: > Dmitry, > > Please find enclosed the fourth version of the evdev buffer patches. > > This version implements buffer locking using event_lock as you > suggested, such that we can proceed with fixing the evdev buffer > problem independently from providing a suitable one-to-many buffer. > > The first patch converts the per-client buffers to a common buffer, > and adds a fixme since the code is expected to be further > improved. The second and third patch includes your review comments. > > Thanks, > Henrik > > --- > > Henrik Rydberg (3): > input: evdev: Use multi-reader buffer to save space (rev4) > input: evdev: Convert to dynamic event buffer (rev4) > input: Use driver hint to compute the evdev buffer size (rev2) > > drivers/input/evdev.c | 68 +++++++++++++++++++++++++++++++++---------------- > include/linux/input.h | 17 ++++++++++++ > 2 files changed, 63 insertions(+), 22 deletions(-) I like the first patch for the simplification of buffer management into one buffer per device, and I think it may be more efficient due to there being less locking when syncing the clients. The second and third patches seem like reasonable solutions to the buffers being too small for some devices that can handle many MT events simultaneously and offer many attributes per event. Acked-by: Chase Douglas <chase.douglas(a)canonical.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 14 Jun 2010 23:20 On Saturday, June 05, 2010 04:04:26 am Henrik Rydberg wrote: > Dmitry, > > Please find enclosed the fourth version of the evdev buffer patches. > > This version implements buffer locking using event_lock as you > suggested, such that we can proceed with fixing the evdev buffer > problem independently from providing a suitable one-to-many buffer. > > The first patch converts the per-client buffers to a common buffer, > and adds a fixme since the code is expected to be further > improved. The second and third patch includes your review comments. Henrik, Applied to .36 queue with minor adjustments, please take a peek in my 'for-linus' branch and see if you spot anything wrong. The changes have been made with an eye of implementing a per-client event filters which would again require using private event queues (but only by clients that request filtering). The desire for allowing event filtering in kernel is to avoid waking up HAL-ish processes (ones that only interested in certain special events, like KEY_SUSPEND, KEY_WIFI, KEY_MUTE, etc) needlessly. Not sure if I am going to have time to actually implement it though, anyone wants to take a stab? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrik Rydberg on 15 Jun 2010 05:50 Dmitry Torokhov wrote: > On Saturday, June 05, 2010 04:04:26 am Henrik Rydberg wrote: >> Dmitry, >> >> Please find enclosed the fourth version of the evdev buffer patches. >> >> This version implements buffer locking using event_lock as you >> suggested, such that we can proceed with fixing the evdev buffer >> problem independently from providing a suitable one-to-many buffer. >> >> The first patch converts the per-client buffers to a common buffer, >> and adds a fixme since the code is expected to be further >> improved. The second and third patch includes your review comments. > > Henrik, > > Applied to .36 queue with minor adjustments, please take a peek in my > 'for-linus' branch and see if you spot anything wrong. We are talking about your tree @kernel.org, right? Nothing appeared there... > The changes have > been made with an eye of implementing a per-client event filters which > would again require using private event queues (but only by clients that > request filtering). Would not having the separate reader tails suffice? Implementing the filtering during client read? > The desire for allowing event filtering in kernel is to avoid waking up > HAL-ish processes (ones that only interested in certain special events, > like KEY_SUSPEND, KEY_WIFI, KEY_MUTE, etc) needlessly. Not sure if I am > going to have time to actually implement it though, anyone wants to > take a stab? I see. Something like a lovely new ioctl() command, setting the evbits on a per client basis? Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Kosina on 16 Jun 2010 10:50 On Thu, 10 Jun 2010, Dmitry Torokhov wrote: > > This version implements buffer locking using event_lock as you > > suggested, such that we can proceed with fixing the evdev buffer > > problem independently from providing a suitable one-to-many buffer. > > > > The first patch converts the per-client buffers to a common buffer, > > and adds a fixme since the code is expected to be further > > improved. The second and third patch includes your review comments. > > Henrik, > > Applied to .36 queue with minor adjustments, please take a peek in my > 'for-linus' branch and see if you spot anything wrong. Hi Dmitry, I guess you forgot to push it to kernel.org? Last change I see in your tree is 6 days old. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrik Rydberg on 16 Jun 2010 12:20 Jiri Kosina wrote: > On Thu, 10 Jun 2010, Dmitry Torokhov wrote: > >>> This version implements buffer locking using event_lock as you >>> suggested, such that we can proceed with fixing the evdev buffer >>> problem independently from providing a suitable one-to-many buffer. >>> >>> The first patch converts the per-client buffers to a common buffer, >>> and adds a fixme since the code is expected to be further >>> improved. The second and third patch includes your review comments. >> Henrik, >> >> Applied to .36 queue with minor adjustments, please take a peek in my >> 'for-linus' branch and see if you spot anything wrong. > > Hi Dmitry, > > I guess you forgot to push it to kernel.org? Last change I see in your > tree is 6 days old. > > Thanks, > .... which seems like a lucky strike; the patch has a blatant security hole, leaking grabbed events to listening clients after ungrab. I sent an updated patch to Dmitry earlier today, in a brown paper bag. Not knowing if the original patch was actually applied or not, I thought I had better hold on to the change just a little bit. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Next
|
Last
Pages: 1 2 Prev: input: mt: Introduce MT event slots (rev 5) Next: [19/23] KVM: Fix unused but set warnings |