linux-ext4 - All processes accessing etx4 partition stuck in 'D' state

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:	Mon, 19 Jan 2009 06:47:45 +0000
From:	Graham Murray <graham@...rray.org.uk>
To:	linux-ext4@...r.kernel.org
Subject: All processes accessing etx4 partition stuck in 'D' state

I do not know if this is ext4 related or not, so my apologies if it is
not.

I am running the latest linus 2.6.29-rc2 git kernel together with the
master branch of the ext4 git tree announced here a couple of days ago.

Yesterday evening, all processes accessing /home which is formatted as
ext4 (created as ext4 under 2.6.26 with the ext4 patches applied, not
converted from ext3) were stuck in 'D' state and top showed both cores
of the core2 CPU in 100% Waiting state. Everything not accessing /home
was responsive. To eliminate a physical problem I ran a SMART self-test
on the drive containing /home and it passed with no errors. / is also
etx4, but was converted from ext3. There were no kernel messages, just
the hung processes. The system would not reboot normally (because of the
processes in 'D' state), but following sysrq sync, mount r/o and reboot,
the filesystem showed as clean when restarted. To be sure, the first
thing I did was to unmount it and manually ran fsck -f and that did not
report any problems. 
--
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