It is not quite clear what does mutex_lock(&dev->lock) defend against. If there is a chance that some other code can try to lock the mutex during probe(), then mutex_unlock(&dev->lock); kfree(dev); looks suspicious, because when that code get control form mutex_lock(dev->lock) the dev could be already freed. Otherwise, dev->lock should not be acquired so early. Another problem is that on the path going via goto done there is no mutex_unlock(&dev->lock). Found by Linux Driver Verification project (linuxtesting.org). -- Alexey Khoroshilov Linux Verification Center, ISPRAS web: http://linuxtesting.org -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
