linux-kernel - [PATCH] IB/uverbs: BKL is not needed for ib_uverbs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Jun 2008 14:43:20 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Jonathan Corbet <corbet@....net>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Andi Kleen <andi@...stfloor.org>, general@...ts.openfabrics.org
Subject: [PATCH] IB/uverbs: BKL is not needed for ib_uverbs_open()

Remove explicit lock_kernel() calls and document why the code is safe.

Signed-off-by: Roland Dreier <rolandd@...co.com>
---
Hi Jon,

Is this sort of patch the next step in the BKL-removal plan?  Is now an
appropriate time to send such things?

If this looks good to you I will do a careful audit of the rest of
drivers/infiniband/core and send you a few more similar patches.

Thanks,
  Roland

 drivers/infiniband/core/uverbs_main.c |   20 +++++++++++++-------
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/core/uverbs_main.c b/drivers/infiniband/core/uverbs_main.c
index f839dde..661b3f8 100644
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -45,7 +45,6 @@
 #include <linux/file.h>
 #include <linux/mount.h>
 #include <linux/cdev.h>
-#include <linux/smp_lock.h>
 
 #include <asm/uaccess.h>
 
@@ -611,23 +610,32 @@ static int ib_uverbs_mmap(struct file *filp, struct vm_area_struct *vma)
 		return file->device->ib_dev->mmap(file->ucontext, vma);
 }
 
+/*
+ * ib_uverbs_open() does not need the BKL:
+ *
+ *  - dev_table[] accesses are protected by map_lock, the
+ *    ib_uverbs_device structures are properly reference counted, and
+ *    everything else is purely local to the file being created, so
+ *    races against other open calls are not a proble;
+ *  - there is no ioctl method to race against;
+ *  - the device is added to dev_table[] as the last part of module
+ *    initialization, the open method will either immediately run
+ *    -ENXIO, or all required initialization will be done.
+ */
 static int ib_uverbs_open(struct inode *inode, struct file *filp)
 {
 	struct ib_uverbs_device *dev;
 	struct ib_uverbs_file *file;
 	int ret;
 
-	lock_kernel();
 	spin_lock(&map_lock);
 	dev = dev_table[iminor(inode) - IB_UVERBS_BASE_MINOR];
 	if (dev)
 		kref_get(&dev->ref);
 	spin_unlock(&map_lock);
 
-	if (!dev) {
-		unlock_kernel();
+	if (!dev)
 		return -ENXIO;
-	}
 
 	if (!try_module_get(dev->ib_dev->owner)) {
 		ret = -ENODEV;
@@ -648,7 +656,6 @@ static int ib_uverbs_open(struct inode *inode, struct file *filp)
 
 	filp->private_data = file;
 
-	unlock_kernel();
 	return 0;
 
 err_module:
@@ -656,7 +663,6 @@ err_module:
 
 err:
 	kref_put(&dev->ref, ib_uverbs_release_dev);
-	unlock_kernel();
 	return ret;
 }
 
-- 
1.5.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/