lkml.org 
[lkml]   [2004]   [Apr]   [29]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 29 Apr 2004 21:43:45 +0200
FromPavel Machek <>
SubjectRe: locking in psmouse
Hi!

> > 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.
> 
> I see.. but this particular case can be resolved but rearranging the code to
> write command response first and then decrementing the counter... and putting
> a barrier? Or just make cmdcnt atomic... spin_lock_irq feels heavier than
> absolutely necessary.

cmdcnt would have to be atomic_t, ack too, state too, and
you'd have to be very carefull with memory barriers...
I guess spinlock is better solution.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:02    [from the cache]
©2003-2008