PATCH/RFC: fix 2.5.20 ramdisk

PATCH/RFC: fix 2.5.20 ramdisk

[Russell King]

2.5.20 seems to be incapable of executing binaries in a ramdisk-based
root filesystem.  The ramdisk in question is an ext2fs, with a 1K
block size loaded via the compressed ramdisk loader in do_mounts().

It appears that, in the case of a 1K block sized filesystem, we attempt
to read two 512-byte sectors into a BIO vector.  The first one is copied
into the first 512 bytes.  The second sector, however, is copied over
the first 512 bytes.  Obviously not what we really want.

Here is _a_ patch which solves this for me, which may not be correct.
Jens?

--- orig/drivers/block/rd.c	Wed May 29 21:40:26 2002
+++ linux/drivers/block/rd.c	Mon Jun  3 17:59:08 2002
@@ -144,7 +144,7 @@
 {
 	struct address_space * mapping;
 	unsigned long index;
-	int offset, size, err;
+	int offset, vec_offset, size, err;
 
 	err = 0;
 	mapping = rd_bdev[minor]->bd_inode->i_mapping;
@@ -152,6 +152,7 @@
 	index = sector >> (PAGE_CACHE_SHIFT - 9);
 	offset = (sector << 9) & ~PAGE_CACHE_MASK;
 	size = vec->bv_len;
+	vec_offset = 0;
 
 	do {
 		int count;
@@ -186,13 +187,14 @@
 		if (rw == READ) {
 			src = kmap(page);
 			src += offset;
-			dst = kmap(vec->bv_page) + vec->bv_offset;
+			dst = kmap(vec->bv_page) + vec->bv_offset + vec_offset;
 		} else {
 			dst = kmap(page);
 			dst += offset;
-			src = kmap(vec->bv_page) + vec->bv_offset;
+			src = kmap(vec->bv_page) + vec->bv_offset + vec_offset;
 		}
 		offset = 0;
+		vec_offset += count;
 
 		memcpy(dst, src, count);
 

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: PATCH/RFC: fix 2.5.20 ramdisk

[Jens Axboe]

On Mon, Jun 03 2002, Russell King wrote:
> 2.5.20 seems to be incapable of executing binaries in a ramdisk-based
> root filesystem.  The ramdisk in question is an ext2fs, with a 1K
> block size loaded via the compressed ramdisk loader in do_mounts().
> 
> It appears that, in the case of a 1K block sized filesystem, we attempt
> to read two 512-byte sectors into a BIO vector.  The first one is copied
> into the first 512 bytes.  The second sector, however, is copied over
> the first 512 bytes.  Obviously not what we really want.
> 
> Here is _a_ patch which solves this for me, which may not be correct.
> Jens?

Looks good.

-- 
Jens Axboe

Re: PATCH/RFC: fix 2.5.20 ramdisk

[Russell King]

On Tue, Jun 04, 2002 at 10:35:25AM +0200, Jens Axboe wrote:
> On Mon, Jun 03 2002, Russell King wrote:
> > 2.5.20 seems to be incapable of executing binaries in a ramdisk-based
> > root filesystem.  The ramdisk in question is an ext2fs, with a 1K
> > block size loaded via the compressed ramdisk loader in do_mounts().
> > 
> > It appears that, in the case of a 1K block sized filesystem, we attempt
> > to read two 512-byte sectors into a BIO vector.  The first one is copied
> > into the first 512 bytes.  The second sector, however, is copied over
> > the first 512 bytes.  Obviously not what we really want.
> 
> Looks good.

Ok, rev. 2, slightly cleaned up:

--- orig/drivers/block/rd.c	Wed May 29 21:40:26 2002
+++ linux/drivers/block/rd.c	Tue Jun  4 09:44:21 2002
@@ -144,6 +144,7 @@
 {
 	struct address_space * mapping;
 	unsigned long index;
+	unsigned int vec_offset;
 	int offset, size, err;
 
 	err = 0;
@@ -152,6 +153,7 @@
 	index = sector >> (PAGE_CACHE_SHIFT - 9);
 	offset = (sector << 9) & ~PAGE_CACHE_MASK;
 	size = vec->bv_len;
+	vec_offset = vec->bv_offset;
 
 	do {
 		int count;
@@ -186,13 +188,14 @@
 		if (rw == READ) {
 			src = kmap(page);
 			src += offset;
-			dst = kmap(vec->bv_page) + vec->bv_offset;
+			dst = kmap(vec->bv_page) + vec_offset;
 		} else {
 			dst = kmap(page);
 			dst += offset;
-			src = kmap(vec->bv_page) + vec->bv_offset;
+			src = kmap(vec->bv_page) + vec_offset;
 		}
 		offset = 0;
+		vec_offset += count;
 
 		memcpy(dst, src, count);
 

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: PATCH/RFC: fix 2.5.20 ramdisk

[Martin Dalecki]

Russell King wrote:
> On Tue, Jun 04, 2002 at 10:35:25AM +0200, Jens Axboe wrote:
> 
>>On Mon, Jun 03 2002, Russell King wrote:
>>
>>>2.5.20 seems to be incapable of executing binaries in a ramdisk-based
>>>root filesystem.  The ramdisk in question is an ext2fs, with a 1K
>>>block size loaded via the compressed ramdisk loader in do_mounts().
>>>
>>>It appears that, in the case of a 1K block sized filesystem, we attempt
>>>to read two 512-byte sectors into a BIO vector.  The first one is copied
>>>into the first 512 bytes.  The second sector, however, is copied over
>>>the first 512 bytes.  Obviously not what we really want.
>>
>>Looks good.
> 
> 
> Ok, rev. 2, slightly cleaned up:
> 
> --- orig/drivers/block/rd.c	Wed May 29 21:40:26 2002
> +++ linux/drivers/block/rd.c	Tue Jun  4 09:44:21 2002
> @@ -144,6 +144,7 @@
>  {
>  	struct address_space * mapping;
>  	unsigned long index;
> +	unsigned int vec_offset;


Just a small nit. Shouldn't taht be size_t ?

Re: PATCH/RFC: fix 2.5.20 ramdisk

[Jens Axboe]

On Tue, Jun 04 2002, Martin Dalecki wrote:
> Russell King wrote:
> >On Tue, Jun 04, 2002 at 10:35:25AM +0200, Jens Axboe wrote:
> >
> >>On Mon, Jun 03 2002, Russell King wrote:
> >>
> >>>2.5.20 seems to be incapable of executing binaries in a ramdisk-based
> >>>root filesystem.  The ramdisk in question is an ext2fs, with a 1K
> >>>block size loaded via the compressed ramdisk loader in do_mounts().
> >>>
> >>>It appears that, in the case of a 1K block sized filesystem, we attempt
> >>>to read two 512-byte sectors into a BIO vector.  The first one is copied
> >>>into the first 512 bytes.  The second sector, however, is copied over
> >>>the first 512 bytes.  Obviously not what we really want.
> >>
> >>Looks good.
> >
> >
> >Ok, rev. 2, slightly cleaned up:
> >
> >--- orig/drivers/block/rd.c	Wed May 29 21:40:26 2002
> >+++ linux/drivers/block/rd.c	Tue Jun  4 09:44:21 2002
> >@@ -144,6 +144,7 @@
> > {
> > 	struct address_space * mapping;
> > 	unsigned long index;
> >+	unsigned int vec_offset;
> 
> 
> Just a small nit. Shouldn't taht be size_t ?

It's just the offset into the current page.

-- 
Jens Axboe

Re: PATCH/RFC: fix 2.5.20 ramdisk

[Russell King]

On Tue, Jun 04, 2002 at 09:54:14AM +0200, Martin Dalecki wrote:
> > --- orig/drivers/block/rd.c	Wed May 29 21:40:26 2002
> > +++ linux/drivers/block/rd.c	Tue Jun  4 09:44:21 2002
> > @@ -144,6 +144,7 @@
> >  {
> >  	struct address_space * mapping;
> >  	unsigned long index;
> > +	unsigned int vec_offset;
> 
> Just a small nit. Shouldn't taht be size_t ?

I really don't see where you got that thought from.  A bio_vec is:

struct bio_vec {
        struct page     *bv_page;
        unsigned int    bv_len;
        unsigned int    bv_offset;
};

bv_offset is unsigned int.  Therefore, vec_offset should be likewise.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: PATCH/RFC: fix 2.5.20 ramdisk

[Martin Dalecki]

Russell King wrote:
> On Tue, Jun 04, 2002 at 09:54:14AM +0200, Martin Dalecki wrote:
> 
>>>--- orig/drivers/block/rd.c	Wed May 29 21:40:26 2002
>>>+++ linux/drivers/block/rd.c	Tue Jun  4 09:44:21 2002
>>>@@ -144,6 +144,7 @@
>>> {
>>> 	struct address_space * mapping;
>>> 	unsigned long index;
>>>+	unsigned int vec_offset;
>>
>>Just a small nit. Shouldn't taht be size_t ?
> 
> 
> I really don't see where you got that thought from.  A bio_vec is:
> 
> struct bio_vec {
>         struct page     *bv_page;
>         unsigned int    bv_len;
>         unsigned int    bv_offset;
> };
> 
> bv_offset is unsigned int.  Therefore, vec_offset should be likewise.

Ahh. Of course I see. Thank you for explaining.