linux-ext4 - Re: Kernel panic from corrupt journal

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] [day] [month] [year] [list]

Message-ID: <20120831055349.GA18086@thunk.org>
Date:	Fri, 31 Aug 2012 01:53:49 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Brian Candler <B.Candler@...ox.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Kernel panic from corrupt journal

On Thu, Aug 30, 2012 at 10:22:12AM +0100, Brian Candler wrote:
> I have a system where just replaying the journal causes a kernel panic. If I
> boot into recovery mode and then type
> 
> With "debugfs /dev/sda8", then:
> 
>     logdump /tmp/sda8.dmp      -> this works OK, writes out a list of blocks
>     logdump -ac /tmp/sda8.dmp  -> this also causes a kernel panic!

I'm going to guess that there is some kind of hardware failure which
is returning an I/O error that the device driver can't handle, and so
you're getting a kernel panic.  That's because if you get it while
accessing the data blocks on the disk which contains the journal from
a userspace program such as debugfs, there is no ext4 kernel code
which is involved.

Taking a screen shot with the scratch information is useful, but it
will almost certainly (especially when you are running the journal via
e2fsck or debugfs) show a kernel strack trace that doesn't involve the
ext4 code paths at all.

> (1) the fact that I can cause a kernel panic is a bug, and if I can help fix
> it I will; however I'm not sure how I can pass on any useful information
> given that even dumping the journal causes a kernel panic.  Can I get the
> journal by dd'ing at a specific offset?
> 
> (2) I'd also like to be able to recover this filesystem, e.g. by clearing
> the journal, but I haven't been able to find out how to do this.

What kind of device is /dev/sda?  You might want to try removing the
disk and connecting it to another computer, and then copying the
entire disk image to a new disk using dd_rescue (which will create a
block-by-block copy of the disk image).  You could try copying the
disk using dd_rescue on your current computer. but it will almost
certainly crash as well.  It seems likely that the mere act of trying
to read the data block in question is causing an I/O error which is
causing the device driver to crash.

Regards,

							- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html