linux-kernel - Re: Crash in 2.6.28.7

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:	Thu, 26 Feb 2009 21:42:15 +0100
From:	Fabio Comolli <fabio.comolli@...il.com>
To:	Theodore Tso <tytso@....edu>,
	Fabio Comolli <fabio.comolli@...il.com>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Crash in 2.6.28.7 - ext4 related

Hi.

On Thu, Feb 26, 2009 at 5:08 PM, Theodore Tso <tytso@....edu> wrote:
> I got the crash image.  Unfortunately the beginning of the Oops
> message was cut off, which might have been valuable.  There are some
> new patches that are newer than what has been backported to 2.6.28.7;
> some of them are in the for-stable branch of the ext4 git tree, and
> have been queued for 2.6.28.8.  The call stack doesn't look like one
> of the known bugs, though.
>
> Hmm... can you send us the output of dumpe2fs on the filesystem?

Attached.

> And something that would be very useful would be a raw e2image of the
> filesystem, created thusly:
>
>            e2image -r /dev/sdXXX - | bzip2 > sdXXX.e2i.bz2
>
> This image will contain the basic filesystem metadata, including the
> directory blocks (and directory names), but none of the data blocks.
> It is therefore much smaller, and if you are willing to let me see
> your directory file names, I can take that image and try to replicate
> the problem on one of my systems.

It's my home directory and so I prefer not to share, sorry. Anyway, it
seems that after the removal of that (possibly corrupted) directory, I
can't reproduce the problem anymore. I tried to create / modify /
delete some big directories, even two or three at a time with no luck.

I would post some new pictures if the problems represents.

> If you have a spare 20gb of disk space, you can also unpack the raw
> image dump and try reproducing the problem on the raw image dump.  If
> you can trigger it easily with an rm -rf operation, it should be just
> as reproducible on the raw image dump.
>
> Regards,
>
>                                                - Ted
>

Thanks,
Fabio

Download attachment "dumpe2fs.log.gz" of type "application/x-gzip" (143271 bytes)