Re: BKL removal from find_exported_dentry()

["Jose R. Santos" <jrsantos@austin.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On 03/09/04 07:54:51, Jose R. Santos wrote:
> Is there anything in particular the BKL is trying to protect here or is it 
> safe to remove?

Should I push this through Andrew Morton or should this go through you guys 
first?  Is there a particular scenario were this would be unsafe?

Looking at the code it seems there is a possibility of racing if directories
get rename or remove, but BKL doesn't seem to protect against these races, it
may slow down thing a bit to avoid them though.

I'm attaching a patch that removes BKL from find_exported_dentry().  I see a 
huge improvement on SpecSFS benchmark and haven't seen any failure up to date.

Comments?

Thanks

-JRS

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: exportfs_bkl_removal.patch --]
[-- Type: text/x-patch; charset=unknown-8bit, Size: 846 bytes --]

===== fs/exportfs/expfs.c 1.13 vs edited =====
--- 1.13/fs/exportfs/expfs.c	Sun Apr 20 01:22:23 2003
+++ edited/fs/exportfs/expfs.c	Thu Mar 11 13:59:35 2004
@@ -135,7 +135,6 @@
 	 * the noprogress counter.  If we go through the loop 10 times (2 is
 	 * probably enough) without getting anywhere, we just give up
 	 */
-	lock_kernel();
 	noprogress= 0;
 	while (target_dir->d_flags & DCACHE_DISCONNECTED && noprogress++ < 10) {
 		struct dentry *pd = target_dir;
@@ -232,7 +231,6 @@
 		/* something went wrong - oh-well */
 		if (!err)
 			err = -ESTALE;
-		unlock_kernel();
 		goto err_target;
 	}
 	/* if we weren't after a directory, have one more step to go */
@@ -254,7 +252,6 @@
 		}
 	}
 	dput(target_dir);
-	unlock_kernel();
 	/* now result is properly connected, it is our best bet */
 	if (acceptable(context, result))
 		return result;