linux-ext4 - [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

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: <200910131316.n9DDG5tM028039@demeter.kernel.org>
Date:	Tue, 13 Oct 2009 13:16:05 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

http://bugzilla.kernel.org/show_bug.cgi?id=14354

--- Comment #33 from Theodore Tso <tytso@....edu>  2009-10-13 13:16:01 ---
Alexey, the dmesg outputs you are posting --- are these random dmesg's, or ones
taken right before the system goes read-only, or the boot session *before*
that?   If you can easily trigger the file system corruption, something really
useful to do would be to set up syslog to do remote logging, so we can get the
EXT4 syslog just as or after the root filesystem gets remounted read-only.   In
addition, it would be useful to get the EXT4 syslog messages for one or two
boot sessions *before* the file system was found to be corrupted, as well as
the boot session where the file system was found corrupted.  

If the file system is getting corrupted after the journal is found corrupted
due to a checksum mismatch, the syslog file may not have the EXT4 syslog
messages, since the file system may end up getting remounted read-only.  And in
that case, it's useful to see if there are any EXT4 syslog messages or any
messages from the device driver showing any I/O errors.

The reason why I'm asking about LVM errors and dm-crypt is that at least one
fsck log had the name /dev/mapper/sda5_crypt.   At this point I'm still trying
to find common elements and information leading to a reliable reproduction ---
and something that can confirm that this is indeed a regression, so I know
whether or not focusing on recent commits is productive.  (The theory that it
might have something to do with journal checksums is assuming that this is a
regression, but so far none of the dmesg is showing the "Journal transaction
XXXX is corrupt" that would be expected if the theory that this was caused by a
journal checksum failure is correct.   So I don't want to focus too soon on
recent commits as potential causes of this problem until we know for certain it
is a regression.)

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
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