Re: locking in psmouse

From: Pavel Machek
Date: Thu Apr 29 2004 - 04:59:40 EST


Hi!

> > psmouse-base.c does not have any locking. For example psmouse_command
> > could race with data coming from the mouse, resulting in problem. This
> > should fix it.
>
> Although I am not arguing that locking might be needed in psmouse module I
> am somewhat confused how it will help in case of data stream coming from the
> mouse... If mouse sent a byte before the kernel issue a command then it will
> be delivered by KBC controller and will be processed by the interrupt handler,
> probably messing up detection process. That's why as soon as we decide that
> the device behind PS/2 port is some kind of mouse we disable the stream mode.

Does that mean that mouse can not talk while we are sending commands
to it? That would help a bit.

Anyway, locking still seems to be needed:

while (psmouse->cmdcnt && timeout--) {

if (psmouse->cmdcnt == 1 && command == PSMOUSE_CMD_RESET_BAT &&
timeout > 100000) /* do not run in a endless loop */
timeout = 100000; /* 1 sec */

if (psmouse->cmdcnt == 1 && command == PSMOUSE_CMD_GETID &&
psmouse->cmdbuf[1] != 0xab && psmouse->cmdbuf[1] != 0xac) {
psmouse->cmdcnt = 0;
break;
}

spin_unlock_irq(&psmouse_lock);
udelay(1);
spin_lock_irq(&psmouse_lock);
}

racing with

if (psmouse->cmdcnt) {
psmouse->cmdbuf[--psmouse->cmdcnt] = data;
goto out;
}

now... if each runs on different CPU, it can be possible that
psmouse->cmdcnt is seen as 1 but data are not yet in
psmouse->cmdbuf... Locking seems neccessary here.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/