On Friday 18 March 2011, Mark Brown wrote: > On Fri, Mar 18, 2011 at 01:19:53PM +0100, Arnd Bergmann wrote: > > On Friday 18 March 2011, Waldemar Rymarkiewicz wrote: > > > > + > > > + mutex_lock(&info->rx_mutex); > > > + info->irq_state = 1; > > > + mutex_unlock(&info->rx_mutex); > > > + > > > + wake_up_interruptible(&info->rx_waitq); > > > + > > > + return IRQ_HANDLED; > > > +} > > > You cannot take a mutex from interrupt context, that may > > cause deadlocks. > > This is a threaded IRQ handler so mutexes are fine. Ah, right. I've never seen one of these used in the field, so I didn't think of this. Looking at the mutexes though: The read function does not hold the rx_mutex when reading the irq_state variable, so that is potentially racy. The read function seems to have another problem regarding the user space buffer: it bails out if the provided buffer is larger than the available data, which is pointless, but it does not check if the user buffer is too short. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
