Prev: [patch 2/2] tty fix fu_list abuse
Next: x86, paravirt: Add a global synchronization point for pvclock
From: Jiri Slaby on 7 Jul 2010 09:00 Hi, stanse found a locking error in lirc_dev_fop_read: if (mutex_lock_interruptible(&ir->irctl_lock)) return -ERESTARTSYS; .... while (written < length && ret == 0) { if (mutex_lock_interruptible(&ir->irctl_lock)) { #1 ret = -ERESTARTSYS; break; } ... } remove_wait_queue(&ir->buf->wait_poll, &wait); set_current_state(TASK_RUNNING); mutex_unlock(&ir->irctl_lock); #2 If lock at #1 fails, it beaks out of the loop, with the lock unlocked, but there is another "unlock" at #2. regards, -- js -- 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: Jarod Wilson on 7 Jul 2010 10:10
On Wed, Jul 07, 2010 at 02:52:58PM +0200, Jiri Slaby wrote: > Hi, > > stanse found a locking error in lirc_dev_fop_read: > if (mutex_lock_interruptible(&ir->irctl_lock)) > return -ERESTARTSYS; > ... > while (written < length && ret == 0) { > if (mutex_lock_interruptible(&ir->irctl_lock)) { #1 > ret = -ERESTARTSYS; > break; > } > ... > } > > remove_wait_queue(&ir->buf->wait_poll, &wait); > set_current_state(TASK_RUNNING); > mutex_unlock(&ir->irctl_lock); #2 > > If lock at #1 fails, it beaks out of the loop, with the lock unlocked, > but there is another "unlock" at #2. Yeah, ok, I see the problem there, should be able to get a patch to fix it in flight later today. Thanks much, -- Jarod Wilson jarod(a)redhat.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/ |