linux-ext4 - Re: ext4 corruption

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]

Date:	Mon, 28 Feb 2011 15:45:51 -0800
From:	"Bill Huey (hui)" <bill.huey@...il.com>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: ext4 corruption

Yeah, it was just a standard mkfs so I doubt that option was
specified. The important thing for me here was to at least let you
folks know about it so that you can determine if this is significant
or not.


Thanks

bill

On Mon, Feb 28, 2011 at 2:55 PM, Ted Ts'o <tytso@....edu> wrote:
> There are a few places where we update the superblock bypassing the
> journal layer.  (For example, when we set the RO_COMPAT_LARGE_FILE
> feature flag if it wasn't previously set).  Those should be cleaned
> up, but it's not related to the rest of the scary-looking corruption
> which you saw.  The worst that might happen is specific superblock
> update might get lost (i.e., the RO_COMPAT_LARGE_FILE feature flag) on
> a crash before we commit some other superblock change to the journal.
--
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