Skip to contentSkip to conversation

PATCH 2.4.0.11.4: loopback block device fixes

PATCH Jeff Garzik 2 participants 2 messages Nov 14, 2000 Block layer

lore
Share & tools
lore

Jeff Garzik

author
#0 lore raw

Since I am not a block device expert, I am interested to know if these fixes look ok, and if they fix the reported loopback deadlocks.

I added calls to deactive_page and flush_dcache_page, and made sure that any error returns were propagated back to the caller.

This is UNTESTED but it looks ok to me [a blkdev newbie...]

Comments appreciated.

Jeff

Index: drivers/block/loop.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/drivers/block/loop.c,v retrieving revision 1.1.1.8

block/loop.c +19 -6
diff -u -r1.1.1.8 loop.c
@@ -56,7 +56,8 @@
 #include <linux/stat.h>
 #include <linux/errno.h>
 #include <linux/major.h>
-
+#include <linux/mm.h>
+#include <linux/swap.h>
 #include <linux/init.h>
 #include <linux/devfs_fs_kernel.h>
 

@@ -178,6 +179,7 @@
 	char *kaddr;
 	unsigned long index;
 	unsigned size, offset;
+	int ret;
 
 	index = pos >> PAGE_CACHE_SHIFT;
 	offset = pos & (PAGE_CACHE_SIZE - 1);

@@ -188,14 +190,23 @@
 			size = len;
 
 		page = grab_cache_page(mapping, index);
-		if (!page)
+		if (!page) {
+			ret = -ENOMEM;
 			goto fail;
-		if (aops->prepare_write(file, page, offset, offset+size))
+		}
+                /* We have exclusive IO access to the page.. */
+                if (!PageLocked(page))
+                        PAGE_BUG(page);
+		ret = aops->prepare_write(file, page, offset, offset+size);
+		if (ret)
 			goto unlock;
 		kaddr = page_address(page);
-		if ((lo->transfer)(lo, WRITE, kaddr+offset, data, size, IV))
+		ret = (lo->transfer)(lo, WRITE, kaddr+offset, data, size, IV);
+		flush_dcache_page(page);
+		if (ret)
 			goto write_fail;
-		if (aops->commit_write(file, page, offset, offset+size))
+		ret = aops->commit_write(file, page, offset, offset+size);
+		if (ret)
 			goto unlock;
 		data += size;
 		len -= size;

@@ -203,6 +214,7 @@
 		index++;
 		pos += size;
 		UnlockPage(page);
+		deactivate_page(page);
 		page_cache_release(page);
 	}
 	return 0;

@@ -213,9 +225,10 @@
 	kunmap(page);
 unlock:
 	UnlockPage(page);
+	deactivate_page(page);
 	page_cache_release(page);
 fail:
-	return -1;
+	return ret;
 }
 
 struct lo_read_data {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw
Quoted 5 lines · Jeff Garzik

Since I am not a block device expert, I am interested to know if these fixes look ok, and if they fix the reported loopback deadlocks.

I added calls to deactive_page and flush_dcache_page, and made sure that any error returns were propagated back to the caller.

The former looks fine (but I'ld rather cc that to VM folks). The latter is patently useless - for one thing, caller doesn't give a damn for the exact error value, for another it couldn't pass it further even if it wanted. We have no way to tell what went wrong when IO request fails - every async error turns into -EIO.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/