2000-11-14 21:52:09

by Jeff Garzik

Subject: PATCH 2.4.0.11.4: loopback block device fixes

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
diff -u -r1.1.1.8 loop.c
--- drivers/block/loop.c 2000/11/10 02:10:21 1.1.1.8
+++ drivers/block/loop.c 2000/11/14 21:17:27
@@ -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 {

2000-11-14 22:28:01

by Alexander Viro

Subject: Re: PATCH 2.4.0.11.4: loopback block device fixes

On Tue, 14 Nov 2000, Jeff Garzik wrote:

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