linux-ext4 - [Bug 14602] JBD2 journal abort / checkpoint creation racy?

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: <200911152228.nAFMS1B4032449@demeter.kernel.org>
Date:	Sun, 15 Nov 2009 22:28:01 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 14602] JBD2 journal abort / checkpoint creation racy?

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

Theodore Tso <tytso@....edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@....edu

--- Comment #1 from Theodore Tso <tytso@....edu>  2009-11-15 22:27:58 ---
If the journal is aborted, then any attempts to destroy the journal, checkpoint
the journal, create a new transaction, etc., will result in -EIO being
returned.   In the code that you quoted, the EIO is being returned because
is_journal_aborted(journal) returns true.

The normal reason why the journal gets aborted is because ext4_error() has
called ext4_handle_error(), which then calls jbd2_journal_abort() and the
errors behavior is remount-read-only.   The basic idea is that if some kind of
file system error or corruption has been detected, we want to stop the file
system from any further modifications, which might cause more damage and/or
user data loss.

We don't have a good errno value to use, so we just use EIO, and the error
handling after an aborted journal is admittedly not great.   It triggers a lot
of scary, and to someone who isn't an ext3/ext4 veteran, misleading, error
messages, and unfortunately it can cause the key initial failure to scroll off
of a VT console.

So it's not a race condition; the system is functioning as designed, although
at some point we may put in better error handling and some earlier tests for an
aborted journal in some of the upper layers of various ext4 functions.

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