[PATCH] Fix open/close race in saa7134

[Arjan van de Ven]

From: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Date: Sun, 22 Jun 2008 10:03:02 -0700
Subject: [PATCH] Fix open/close race in saa7134

The saa7134 driver uses a (non-atomic) variable in an attempt to
only allow one opener of the device (how it deals with sending
the fd over unix sockets I don't know).

Unfortunately, the release function first decrements this variable,
and THEN goes on to disable more of the device. This allows for
a race where another opener of the device comes in after the decrement of
the variable, configures the hardware just to then see the hardware
be disabled by the rest of the release function.

This patch makes the release function use the same lock as the open
function to protect the hardware as well as the variable (which now
at least has some locking to protect it).

Signed-off-by: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
---
 drivers/media/video/saa7134/saa7134-empress.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/saa7134/saa7134-empress.c b/drivers/media/video/saa7134/saa7134-empress.c
index 81431ee..9108843 100644
--- a/drivers/media/video/saa7134/saa7134-empress.c
+++ b/drivers/media/video/saa7134/saa7134-empress.c
@@ -110,6 +110,8 @@ static int ts_release(struct inode *inode, struct file *file)
 {
 	struct saa7134_dev *dev = file->private_data;
 
+	mutex_lock(&dev->empress_tsq.vb_lock);
+
 	videobuf_stop(&dev->empress_tsq);
 	videobuf_mmap_free(&dev->empress_tsq);
 	dev->empress_users--;
@@ -121,6 +123,8 @@ static int ts_release(struct inode *inode, struct file *file)
 	saa_writeb(SAA7134_AUDIO_MUTE_CTRL,
 		saa_readb(SAA7134_AUDIO_MUTE_CTRL) | (1 << 6));
 
+	mutex_unlock(&dev->empress_tsq.vb_lock);
+
 	return 0;
 }
 
-- 
1.5.5.1



-- 
If you want to reach me at my work email, use arjan@xxxxxxxxxxxxxxx
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/