[PATCH 4/6] USB-BKL: Remove BKL use in uhci-debug

[Arnd Bergmann]

From: Andi Kleen <ak@xxxxxxxxxxxxxxx>

BKL was not really needed, just came from earlier push downs.

The only part that's a bit dodgy is the lseek function. Would
need another lock or atomic access to fpos on 32bit?
Better to have a libfs lseek

Signed-off-by: Andi Kleen <ak@xxxxxxxxxxxxxxx>
---
 drivers/usb/host/uhci-debug.c |   17 ++++++-----------
 1 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/host/uhci-debug.c b/drivers/usb/host/uhci-debug.c
index 98cf0b2..b0cf4f8 100644
--- a/drivers/usb/host/uhci-debug.c
+++ b/drivers/usb/host/uhci-debug.c
@@ -495,18 +495,16 @@ static int uhci_debug_open(struct inode *inode, struct file *file)
 {
 	struct uhci_hcd *uhci = inode->i_private;
 	struct uhci_debug *up;
-	int ret = -ENOMEM;
 	unsigned long flags;
 
-	lock_kernel();
 	up = kmalloc(sizeof(*up), GFP_KERNEL);
 	if (!up)
-		goto out;
+		return -ENOMEM;
 
 	up->data = kmalloc(MAX_OUTPUT, GFP_KERNEL);
 	if (!up->data) {
 		kfree(up);
-		goto out;
+		return -ENOMEM;
 	}
 
 	up->size = 0;
@@ -517,10 +515,7 @@ static int uhci_debug_open(struct inode *inode, struct file *file)
 
 	file->private_data = up;
 
-	ret = 0;
-out:
-	unlock_kernel();
-	return ret;
+	return 0;
 }
 
 static loff_t uhci_debug_lseek(struct file *file, loff_t off, int whence)
@@ -528,9 +523,9 @@ static loff_t uhci_debug_lseek(struct file *file, loff_t off, int whence)
 	struct uhci_debug *up;
 	loff_t new = -1;
 
-	lock_kernel();
 	up = file->private_data;
 
+	/* XXX: atomic 64bit seek access, but that needs to be fixed in the VFS */
 	switch (whence) {
 	case 0:
 		new = off;
@@ -539,11 +534,11 @@ static loff_t uhci_debug_lseek(struct file *file, loff_t off, int whence)
 		new = file->f_pos + off;
 		break;
 	}
+
+	/* XXX: Can size shrink? */
 	if (new < 0 || new > up->size) {
-		unlock_kernel();
 		return -EINVAL;
 	}
-	unlock_kernel();
 	return (file->f_pos = new);
 }
 
-- 
1.7.0.4

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