[PATCH RFC] raw: Remove the BKL from raw_open

[PATCH RFC] raw: Remove the BKL from raw_open

[John Kacur]

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 <jkacur@redhat.com>
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 <jkacur@redhat.com>
---
 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

Re: [PATCH RFC] raw: Remove the BKL from raw_open

[Arnd Bergmann]

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 <><