public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
To: npiggin@suse.de
Cc: ext-adrian.hunter@nokia.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Error testing ext3 on brd ramdisk
Date: Tue, 10 Mar 2009 17:49:13 +0100	[thread overview]
Message-ID: <49B69A09.3080408@dti2.net> (raw)
In-Reply-To: <20090310163002.GC19352@wotan.suse.de>

Nick Piggin escribió:
> On Tue, Mar 10, 2009 at 05:12:47PM +0100, Nick Piggin wrote:
>> On Thu, Mar 05, 2009 at 01:12:25PM +0100, Jorge Boncompte [DTI2] wrote:
>>> Jorge Boncompte [DTI2] escribió:
>>>> Ok. I have modified the script to do...
>>>> ------------
>>>> mount -no remount,ro /dev/ram0
>>>> dd if=/dev/ram0 of=/tmp/config.bin bs=1k count=1000
>>>> fsck.minix -fv /tmp/config.bin
>>>> if [ $? != 0 ]; then
>>>>    echo "FATAL: Filesystem is corrupted"
>>>>    exit 2
>>>> fi
>>>> mount -no remount,rw /dev/ram0
>>>> md5sum config.bin
>>>> dd if=config.bin of=/dev/hda1
>>>> echo $md5sum | dd of=/dev/hda1 bs=1k seek=1100 count=32
>>>> ------------
>>>> ... after some cycles of modifying files on the filesystem and trying to 
>>>> save it to disk...
>>>> ------------------
>>>> fsck.minix: BusyBox v1.8.2 (2008-12-03 14:24:56 CET)
>>>> Forcing filesystem check on /tmp/config.bin
>>>> Unused inode 198 is marked as 'used' in the bitmap.
>>>> Zone 393 is marked 'in use', but no file uses it.
>>>> Zone 394 is marked 'in use', but no file uses it.
>>>>
>>>>   198 inodes used (58%)
>>>>   395 zones used (39%)
>>>>
>>>>   163 regular files
>>>>    24 directories
>>>>     0 character device files
>>>>     0 block device files
>>>>     0 links
>>>>    10 symbolic links
>>>> ------
>>>>   197 files
>>>> FATAL: Filesystem is corrupted
>>>> -------------------
>>>>
>>> 	If after getting the "FATAL: Filesystem is corrupted" message I do 
>>> "echo 3 > /proc/sys/vm/drop_caches" and rerun the script the filesystem 
>>> somehow got magically fixed (I mean fsck.minix does not report errors 
>>> and the image gets written to disk well ;-)
>> OK, I can reproduce this. It really does seem to be due to buffercache
>> going out of coherency for some reason, so the trick is that you have
>> to fsck it while you have it mounted ro before remounting rw then modifying
>> it then remounting ro and fscking again (the first fsck must bring in
>> uptodate buffercache, and something is not being correctly invalidated).
>>
>> It is also not brd or minix specific -- I reproduced it with loop driver
>> and ext2 too, and probably regular disk driver will have the same problem
>> (ie. it is something in the buffercache).
>>
>> I don't know if this is the same problem as the ext3 issue -- the recipe
>> for reproducing ext3 problem includes umount, which will invalidate all
>> the buffercache unless something is holding the bdev open. But anyway I
>> am making some progress with this problem so I will try solve it first.
>>
>> I can't think of any good reason why buffercache should be going out of
>> sync here...
> 
> 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.
> 
> Thanks,
> Nick
> 
> ---
>  fs/super.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: linux-2.6/fs/super.c
> ===================================================================
> --- linux-2.6.orig/fs/super.c
> +++ linux-2.6/fs/super.c
> @@ -644,6 +644,8 @@ int do_remount_sb(struct super_block *sb
>  		acct_auto_close(sb);
>  	shrink_dcache_sb(sb);
>  	fsync_super(sb);
> +	if (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 */
> 
> 
> 
> 

	With this applied it seems I cannot reproduce the corruption, I have to 
do more tests, but the box oopses on reboot after doing "umount -na -r".

[  193.073856] BUG: unable to handle kernel NULL pointer dereference at 
00000004
[  193.075762] IP: [<c018baa7>] invalidate_bdev+0x4/0x27
[  193.078748] *pde = 00000000
[  193.080306] Oops: 0000 [#1] SMP
[  193.082066] last sysfs file: 
/sys/devices/pci0000:00/0000:00:01.3/i2c-adapter/i2c-0/name
[  193.082066] Modules linked in: atmtcp ipt_REJECT nf_conntrack_ipv4 
nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables 
i2c_piix4 i2c_core ata_piix libata ppp_async ppp_synctty sha1_generic 
arc4 ecb ppp_mppe pppol2tp pppoatm pppoe pppox ppp_generic slhc 8021q 
garp tun softdog usbcore
[  193.082066]
[  193.082066] Pid: 1500, comm: busybox Not tainted (2.6.29-rc7 #122)
[  193.082066] EIP: 0060:[<c018baa7>] EFLAGS: 00010202 CPU: 3
[  193.082066] EIP is at invalidate_bdev+0x4/0x27
[  193.082066] EAX: 00000000 EBX: 00000001 ECX: 00000000 EDX: 00000001
[  193.082066] ESI: ce82dc00 EDI: 00000000 EBP: ce861f30 ESP: ce861f2c
[  193.082066]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[  193.082066] Process busybox (pid: 1500, ti=ce860000 task=ce8c0530 
task.ti=ce860000)
[  193.082066] Stack:
[  193.082066]  00000001 ce861f48 c017408a 00000001 00000001 ce861f78 
ce82dc00 ce861f64
[  193.082066]  c0184cd8 00000000 00000040 ce251000 00000001 00000040 
ce861f8c c01853d5
[  193.082066]  00000000 00000000 ce518000 cf81f140 cf401f20 00000000 
ce251000 00000000
[  193.082066] Call Trace:
[  193.082066]  [<c017408a>] ? do_remount_sb+0x4b/0xc2
[  193.082066]  [<c0184cd8>] ? do_remount+0x70/0xb5
[  193.082066]  [<c01853d5>] ? do_mount+0x107/0x181
[  193.082066]  [<c0185665>] ? sys_mount+0x6a/0xa6
[  193.082066]  [<c0102ce2>] ? syscall_call+0x7/0xb
[  193.082066] Code: 43 c0 e8 d2 74 f9 ff 58 5a 8b 45 ec 83 c0 74 e8 d8 
fb 1c 00 8b 45 e4 e8 f9 e1 fc ff 8b 45 e8 8d 65 f4 5b 5e 5f 5d c3 55 89 
e5 53 <8b> 40 04 8b 98 14 01 00 00 83 7b 60 00 74 11 e8 36 0f 00 00 83
[  193.082066] EIP: [<c018baa7>] invalidate_bdev+0x4/0x27 SS:ESP 
0068:ce861f2c
[  193.132444] ---[ end trace 47b1cfc0707471fd ]---
[  193.133287] Kernel panic - not syncing: Fatal exception
[  193.134372] Rebooting in 40 seconds.. 


-- 
==============================================================
Jorge Boncompte - Ingenieria y Gestion de RED
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5   14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be made.
==============================================================


  reply	other threads:[~2009-03-10 16:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-14 13:25 Error testing ext3 on brd ramdisk Adrian Hunter
2009-02-27 18:08 ` Jorge Boncompte [DTI2]
2009-02-28  5:58   ` Nick Piggin
2009-03-02 17:42     ` Jorge Boncompte [DTI2]
2009-03-05  6:55       ` Nick Piggin
2009-03-05  9:19         ` Jorge Boncompte [DTI2]
2009-03-05  9:46           ` Nick Piggin
2009-03-05 10:56             ` Jorge Boncompte [DTI2]
2009-03-05 12:12               ` Jorge Boncompte [DTI2]
2009-03-10 16:12                 ` Nick Piggin
2009-03-10 16:30                   ` Nick Piggin
2009-03-10 16:49                     ` Jorge Boncompte [DTI2] [this message]
2009-03-11  2:19                       ` Nick Piggin
2009-03-13 17:06                         ` Jorge Boncompte [DTI2]
2009-03-17  9:40                           ` Denis Karpov
2009-03-18 12:11                             ` Nick Piggin
2009-03-18 13:42                               ` Jan Kara
2009-03-20 12:24                                 ` Denis Karpov
2009-03-20 12:49                                   ` Denis Karpov
2009-03-20 13:35                                 ` Denis Karpov
2009-03-05 10:45           ` Nick Piggin
2009-03-05 11:54             ` Jorge Boncompte [DTI2]
2009-03-06  7:47         ` Adrian Hunter
2009-03-10 11:03           ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49B69A09.3080408@dti2.net \
    --to=jorge@dti2.net \
    --cc=ext-adrian.hunter@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox