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]

Message-ID: <20090226205245.GM7227@mit.edu>
Date:	Thu, 26 Feb 2009 15:52:45 -0500
From:	Theodore Tso <tytso@....edu>
To:	Fabio Comolli <fabio.comolli@...il.com>
Cc:	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Crash in 2.6.28.7 - ext4 related

On Thu, Feb 26, 2009 at 09:42:15PM +0100, Fabio Comolli wrote:
> It's my home directory and so I prefer not to share, sorry. 

No problem, I understand.

> 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.

Did you ever try running e2fsck on the filesystem while you could
reproduce it?  Did it report any errors?  A good thing to do in
general, if you can report these sorts of problems, is to run e2fsck
with the -n option, while the filesystme is unmounted, and see if any
errors are reported.  That would tell us if there were any filesystem
corruption problems (and the -n avoids making any changes to the
filesystem).

Also, even if you don't feel willing to share the e2image file, if you
can reproduce it, please consider making a raw e2image dump.  That way
if the problem goes away again, maybe you'll be able to consistently
report reproduce it on the e2image dump file.  

The other thing that you can do which will sometimes work is to add
the -s option to the e2image command.  The -s option scrambles the
name of the directory entries and zeros out any unused portions of
directory blocks to prevent privacy problems.  The downside is that it
can prevent certain bugs from being repeatable and you have to either
turn off the dir_index feature or run e2fsck to fix up the htree since
the filename hashes will be screwed up after the directory entries are
scrambled.  So it's not ideal, but in cases where there are privacy
issues, that can be helpful.

Regards,

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