linux-kernel - Re: Error testing ext3 on brd ramdisk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Mar 2009 11:40:19 +0200
From:	Denis Karpov <ext-denis.2.karpov@...il.com>
To:	"ext Jorge Boncompte [DTI2]" <jorge@...2.net>
Cc:	"npiggin@...e.de" <npiggin@...e.de>,
	"Hunter Adrian (Nokia-D/Helsinki)" <adrian.hunter@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Error testing ext3 on brd ramdisk

On Fri, Mar 13, 2009 at 06:06:07PM +0100, ext Jorge Boncompte [DTI2] wrote:
> Nick Piggin escribió:
> > On Tue, Mar 10, 2009 at 05:49:13PM +0100, Jorge Boncompte [DTI2] wrote:
> >> Nick Piggin escribió:
> >>> Ah, of course, it would be due to directory-in-pagecache. You need
> >>> the following patch if you expect this to work.
> >>>
> >>> And that confirms the ext3 problem is a different one because it
> >>> doesn't use directory in pagecache I think. Well, I'll look at
> >>> that one tomorrow.
> 	Hi Nick, no problems noticed in the last days running with the below 
> patch...
> 
> --- linux-2.6.29-rc8/fs/super.c       2009-03-13 13:46:19 +0100
> +++ kernel/fs/super.c       2009-03-13 13:47:50 +0100
> @@ -647,6 +647,8 @@ int do_remount_sb(struct super_block *sb
>                  acct_auto_close(sb);
>          shrink_dcache_sb(sb);
>          fsync_super(sb);
> +       if (sb->s_bdev && (flags & MS_RDONLY))
> +               invalidate_bdev(sb->s_bdev);
> 
>          /* If we are remounting RDONLY and current sb is read/write,
>             make sure there are no rw files opened */
> 

Hello, 

first off, sorry if you getting this email twice.

I also tried to do ext3/ext4 fs smoketesting and used Adraian's
script.  I am consistently getting the same results - filesystem get's
corrupted. 
I tested on quad Xeon, with patches posted in this thread.

1. tests with brd:
- ext3fs on brd
    corruption (see attached ext3fs.brd.corruption.txt)
- ext4fs on brd
    corruption (see attached ext4fs.brd.corruption.txt)

In both cases I saw some complains from JBD/JBD2:
 JBD: Detected IO errors while flushing file data on

2. I enabled JBD debugging, re-run the tests. Console was 
flooded with messages and in the end I got a soft lockup.
I cannot consistently reproduce this (see attached 
brd.ext3fs.softlock.txt).

Just to be sure I re-run the tests on real block device (usb stick)

3. tests with real block device (usb stick)
- ext3fs
    no fs currption (overnight run)
- ext4fs 
    no fs currption (overnight run)

Any ideas what else can be done here? I'd like to find out if this is
filesystem or brd related fault.

Denis

View attachment "brd.ext3fs.corruption.txt" of type "text/plain" (973 bytes)

View attachment "brd.ext3fs.softlock.txt" of type "text/plain" (26468 bytes)

View attachment "brd.ext4fs.corruption.txt" of type "text/plain" (873 bytes)