I made this RFC in case folks with more experience spot something I've
missed, although this looks pretty safe to me.
>From c1700fbd613ac94d95406eb83ada3d15e511e98c Mon Sep 17 00:00:00 2001
From: John Kacur <[email protected]>
Date: Sun, 18 Oct 2009 22:45:34 +0200
Subject: [PATCH] raw: Remove the BKL from raw_open
The BKL was pushed into raw_open with
commit c0bed680f0ca603864375ed5f9fed4296a53aa62
Jonathan's comments were " Put explicit lock_kernel() calls into raw_open(), even though the existing locking looks adequate."
I have to agree, the raw_mutex should provide all the protection needed here.
Signed-off-by: John Kacur <[email protected]>
---
drivers/char/raw.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/char/raw.c b/drivers/char/raw.c
index 64acd05..d9cfad1 100644
--- a/drivers/char/raw.c
+++ b/drivers/char/raw.c
@@ -19,7 +19,6 @@
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/mutex.h>
-#include <linux/smp_lock.h>
#include <asm/uaccess.h>
@@ -54,7 +53,6 @@ static int raw_open(struct inode *inode, struct file *filp)
return 0;
}
- lock_kernel();
mutex_lock(&raw_mutex);
/*
@@ -81,7 +79,6 @@ static int raw_open(struct inode *inode, struct file *filp)
bdev->bd_inode->i_mapping;
filp->private_data = bdev;
mutex_unlock(&raw_mutex);
- unlock_kernel();
return 0;
out2:
@@ -90,7 +87,6 @@ out1:
blkdev_put(bdev, filp->f_mode);
out:
mutex_unlock(&raw_mutex);
- unlock_kernel();
return err;
}
--
1.6.0.6
On Sunday 18 October 2009, John Kacur wrote:
> The BKL was pushed into raw_open with
> commit c0bed680f0ca603864375ed5f9fed4296a53aa62
>
> Jonathan's comments were " Put explicit lock_kernel() calls into raw_open(),
> even though the existing locking looks adequate."
>
> I have to agree, the raw_mutex should provide all the protection needed here.
The raw driver uses the BKL in both the ioctl and the llseek function, so
I think you have to look if there is any interaction between those and the
open method, ideally removing it from all of them at the same time.
An unrelated bug I spotted while looking at your patch is that there is no
compat_ioctl method in the raw file_operations, which is really needed here
if you want any of the block ioctls to work on a compat task.
Whatever that tells us...
Arnd <><