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-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-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ