On Thu, Oct 19, 2017 at 3:48 PM, Dmitry Torokhov
[off-list ref] wrote:

On Thu, Oct 19, 2017 at 03:45:38PM -0700, Kees Cook wrote:

quoted

On Thu, Oct 19, 2017 at 3:32 PM, Dmitry Torokhov
[off-list ref] wrote:

quoted

On Mon, Oct 16, 2017 at 04:14:43PM -0700, Kees Cook wrote:

quoted

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

One input_dev user hijacks the input_dev software autorepeat timer to
perform its own repeat management. However, there is no path back to the
existing status variable, so add a generic one to the input structure and
use that instead.

That is too bad and it should not be doing this. I'd rather av7110 used
its own private timer for that.

Yeah, that was a pretty weird case. I couldn't see how to avoid it,
though. I didn't see a way to hook the autorepeat, but I'm not too
familiar with the code here.

You just need to manage the private timer in the driver and not mess up
with the input core if input core's autorepeat does not provide the
desired behavior...

I don't know how to fix this, but I still need to do this refactoring.
What's the correct step forward here? Should I temporarily disable the
timer in av7110?

Seems like the hijacking was introduced in ee820a648fb3 ("V4L/DVB
(5334): Dvb-ttpci: Infrared remote control refactoring").

Thanks!

-Kees

-- 
Kees Cook
Pixel Security