linux-kernel - Re: [RFT/PATCH] i8042: remove polling timer (v6)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 Oct 2006 18:20:19 -0500
From:	"Dave Neuer" <mr.fred.smoothie@...ox.com>
To:	"Dmitry Torokhov" <dtor@...ightbb.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...l.org>, "Vojtech Pavlik" <vojtech@...e.cz>
Subject: Re: [RFT/PATCH] i8042: remove polling timer (v6)

On 8/23/06, Dmitry Torokhov <dtor@...ightbb.com> wrote:
> Hi everyone,
>
> Here is another version of the patch removing polling timer from i8042
> which is needed if we want tickless kernel. Keyboards should now work
> on boxes that do not have mouse plugged in. PLease give it a test.

 What's the intent of this; just to allow tickless? Or is it also to
make the i8042 driver less racy? I ask because I've applied this over
(a modified) 2.6.18 on my Compaq Presario X1010us laptop which has
been driving me crazy w/ Synaptics problems and keyboard problems
(intermittent, but   frequent enough lately that I finally figured I
needed to do something about it).

If removing raciness is part of the goal, isn't the window in
i8042_aux_write still a problem?

	if (port->mux == -1)
		retval = i8042_command(&c, I8042_CMD_AUX_SEND);
	else
		retval = i8042_command(&c, I8042_CMD_MUX_SEND + port->mux);

        /* i8042_command has re-enabled interrupts;
           what happens if real interrupt happens here, before we call
the ISR ourselves? */

	i8042_interrupt(0, NULL, NULL);
	return retval;
}

I don't really know if or how much the races in this driver are
contributing to my problems (keyboard getting stuck repeating last
key, or ignoring interrupts, or synaptics touchpad freezing, last of
which requires cold boot to fix). Maybe more likely an ACPI thing?

Anyway, thought I'd point this out and see if this patch is actually
going in someone's queue. I think I'll keep running w/ the patch since
w/ the polling in there and HZ set to 1000, it seemed like there were
an awful lot of opportunities for the driver to get confused, and even
if it's not causing my problems it doesn't seem like it could be
helping.

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/