lkml.org 
[lkml]   [2001]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: ramdisk corruption problems - was: RE: pivot_root and initrd kern el panic woes
Date
From
Yes, this does fix the problem.  Thank you very much!

Hopefully something like this will make it into 2.4.18?

(I have to admit I applied and tested your patch to
2.4.17-rc2, and did not test -rc2 without your patch.
However, -rc1 has the bug and I don't think any other changes
between -rc1 and -rc2 would have fixed this. If someone out
there wants me to, I can recompile and test -rc2 vanilla.)

Torrey Hoffman


Tachino Nobuhiro (tachino@open.nm.fujitsu.co.jp) wrote:

> Hello,
>
> Following patch may fix your problem.
>
> diff -r -u linux-2.4.17-rc2.org/drivers/block/rd.c
> linux-2.4.17-rc2/drivers/block/rd.c
> --- linux-2.4.17-rc2.org/drivers/block/rd.c Thu Dec 20 20:30:57 2001
> +++ linux-2.4.17-rc2/drivers/block/rd.c Thu Dec 20 20:46:53 2001
> @@ -194,9 +194,11 @@
> static int ramdisk_readpage(struct file *file, struct page * page)
> {
> if (!Page_Uptodate(page)) {
> - memset(kmap(page), 0, PAGE_CACHE_SIZE);
> - kunmap(page);
> - flush_dcache_page(page);
> + if (!page->buffers) {
> + memset(kmap(page), 0, PAGE_CACHE_SIZE);
> + kunmap(page);
> + flush_dcache_page(page);
> + }
> SetPageUptodate(page);
> }
> UnlockPage(page);
>
>
> grow_dev_page() creates not Uptodate page which has valid
> buffers, so
> it is wrong that ramdisk_readpage() clears whole page unconditionally.
>
>
> At Tue, 18 Dec 2001 12:14:49 -0800,
> Torrey Hoffman wrote:
> >
> > More information! And a workaround!
> >
> > I conjecture that the ramdisk driver (post 2.4.9) only grabs
> > VM pages properly if it is accessed directly, as a dd to
> > /dev/ram0 does. I further conjecture that accessing the
> > ramdisk through a mounted filesystem does not grab pages
> > properly.
> >
> > The reason I believe this is that removing the call to
> > "freeramdisk" from my original script avoids corruption.
> >
> > Another way to avoid ramdisk corruption is to
> > "dd if=/dev/zero of=/dev/ram0 bs=1k count=4000"
> > immediately after the call to freeramdisk.
> >
> > If my conjecture is right, then the corruption is caused
> > because mke2fs on a "freed" /dev/ram0 doesn't touch every
> > block of the fs, leaving "holes" where pages are not properly
> > grabbed from the VM. The resulting filesystem appears to work,
> > but dd'ing from /dev/ram0 gets a broken filesystem image.
> >
> > Note that "freeramdisk /dev/ram0" is pretty much just:
> > #define FLKFLSBUF _IO(0x12,97) /* flush buffer cache */
> > f = open("/dev/ram0", O_RDWR);
> > ioctl(f, BLKFLSBUF);
> >
> > To experiment for yourself, stick the following script in
> > a subdirectory which also contains a "testdir" directory
> > with about 3 MB of data.
> >
> > - - - - - - - -
> > #!/bin/bash
> >
> > # to tickle the bug, do the freeramdisk but not the
> > # dd from /dev/zero to /dev/ram0.
> >
> > freeramdisk /dev/ram0
> > #dd if=/dev/zero of=/dev/ram0 bs=1k count=4000
> >
> > mke2fs -m0 /dev/ram0 4000
> > mount -t ext2 /dev/ram0 /mnt/ramdisk
> > rm -rf /mnt/ramdisk/*
> >
> > cp -a ./testdir /mnt/ramdisk
> > umount /dev/ram0
> >
> > dd if=/dev/ram0 of=ram0.img bs=1k count=4000
> > dd if=ram0.img of=/dev/ram0 bs=1k count=4000
> >
> > mount -t ext2 /dev/ram0 /mnt/ramdisk
> > diff -q -r ./testdir /mnt/ramdisk/testdir
> >
> > # If diff reports mismatches, you saw the bug.
> >
> > umount /dev/ram0
> > - - - - - - - -
> >
> > If the gods of the VM and VFS don't bother to look at
> > it, I might take a peek at the relevant kernel code myself.
> > Might take two months of study before I know enough though.
> >
> > Torrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:14    [W:0.211 / U:2.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site