From: "Steinar H. Gunderson" <se...@samfundet.no>
dvb_usercopy(), which is called on all ioctls, not only copies data to and from
userspace, but also takes a lock on the file descriptor, which means that only
one ioctl can run at a time. This means that if one thread of mumudvb is busy
trying to get, say, the SNR from the frontend (which can hang due to the issue
above), the CAM thread's ioctl(fd, CA_GET_SLOT_INFO, ...) will hang, even
though it doesn't need to communicate with the hardware at all. This obviously
requires a better fix, but I don't know the generic DVB layer well enough to
say what it is. Maybe it's some sort of remnant of from when all ioctl()s took
the BKL. Note that on UMP kernels without preemption, mutex_lock is to the best
of my knowledge a no-op, so these delay issues would not show up on non-SMP.
Signed-off-by: Steinar H. Gunderson <se...@samfundet.no>
---
drivers/media/dvb/dvb-core/dvbdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
b/drivers/media/dvb/dvb-core/dvbdev.c
index 00a6732..e1217f6 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -417,10 +417,8 @@ int dvb_usercopy(struct file *file,
}
/* call driver */
- mutex_lock(&dvbdev_mutex);
if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD)
err = -EINVAL;
- mutex_unlock(&dvbdev_mutex);
if (err < 0)
goto out;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
