[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d9f68dc2278627dbe8d5e5434cf5a78.squirrel@www.codeaurora.org>
Date: Tue, 1 Jul 2014 06:44:45 -0000
From: "Dolev Raviv" <draviv@...eaurora.org>
To: linux-ext4@...r.kernel.org
Cc: "Tanya Brokhman" <tlinder@...eaurora.org>,
"Maya Erez" <merez@...eaurora.org>, kdorfman@...eaurora.org,
lsusman@...eaurora.org
Subject: help with bug_on on ext4 mount
Hi All,
Im working on a crash originating from ext4 mount path. Im running with
3.10 based kernel.
Crash description:
I saw a BUG_ON assertion failure in function ext4_clear_journal_err(). The
assertion that fails is: !EXT4_HAS_COMPAT_FEATURE(sb,
EXT4_FEATURE_COMPAT_HAS_JOURNAL).
The strange thing is, that the same BUG_ON assertion is called at the
start of the function that calls ext4_clear_journal_err(), which is
ext4_load_journal(). This means that the capability flag is changed in
ext4_load_journal, before the call for journal_err().
Im not too familiar with ext4 code unfortunately. From analyzing the
journal path I came to the below conclusions:
This scenario is possible, if during journal replay, the super_block is
restored or overridden from the journal.
I have noticed a case where the sb is marked as dirty and later, it is
evicted through the address_space_operations .writepage = ext4_writepage
cb. This cb is using the journal and can cause the dirty sb appear on the
journal. If during the journal write operation a power cut occurs, and the
sb copy in the journal is corrupted, it may cause the BUG_ON assertion
failure above.
Is the scenario described above even possible (or am I missing something)?
Has anyone encountered similar issues? Are there any known fixes for this?
Thanks,
Dolev
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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