linux-ext4 - JBD2 stuck, causing fsck to not run.

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

Date:	Thu, 8 Oct 2015 09:42:30 +0300
From:	Nikolay Borisov <kernel@...p.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	"Darrick J. Wong" <darrick.wong@...cle.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	SiteGround Operations <operations@...eground.com>,
	Marian Marinov <mm@...com>
Subject: JBD2 stuck, causing fsck to not run.

Hello,

Yesterday I wanted to run fsck on an ext4 volume. However, fsck was
saying that the volume was still in use and was aborting. After some
debugging turned out it was failing in the bd_may_claim() . Further
investigation revealed that the JBD2 thread for this particular volume
was stuck with the following trace:

PID: 14508 TASK: ffff8802c3b8bd80 CPU: 11 COMMAND: "jbd2/dm-11-8"
#0 [ffff8805d1aefdc0] __schedule at ffffffff815ac3be
#1 [ffff8805d1aefe10] schedule at ffffffff815ac9ce
#2 [ffff8805d1aefe30] kjournald2 at ffffffff8127a5ae
#3 [ffff8805d1aefec0] kthread at ffffffff81073fce
#4 [ffff8805d1aeff50] ret_from_fork at ffffffff815b0fe2

This seems pretty normal to me except that at some point ext4_put_super
should have called jbd2_journal_destroy, which in turn should set the
JBD2_UNMOUNT flag and wakeup the jbd thread so that it can exit
gracefully, apparently this hadn't happened. The volume where the
filesystem was created is an LVM thin volume if it matters.

I wonder whether it's possible due to corruption that ext4 got confused
that it's not being journalled and as such skipped part responsible for
shutting down JBD2? So far this has happened numerous times on a variety
of kernel - from 3.12.28 to 4.1.6 (which was the most recent as of
yesterday). Any ideas when this problem manifests again how to debug it
further?

Regards,
Nikolay
--
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