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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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 ?
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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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.