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

Message-ID: <b637ec0b0902261401p191b2a1fn75b29e99c9f03726@mail.gmail.com>
Date:	Thu, 26 Feb 2009 23:01:13 +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 9:52 PM, Theodore Tso <tytso@....edu> wrote:
> 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.

Thanks.

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

OK, maybe I did not make myself clear in my previous post. After the
last crash (the one from which the picture was taken)  I booted
single-user and the I forced a full fsck with the filesystem
unmounted. It reported no errors. After that I removed the problematic
directory and all is fine since that.

Maybe it's worth mentioning that I did the very same actions after
another crash that happened before: also in that case a full fsck
reported no errors but trying to remove the directory after that
crashed the machine.

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

Yup, will do if the problem shows up again.

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

Will do.

>
> Regards,
>
>                                        - Ted
>

Regards,
Fabio
--
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/