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]

Date:	Tue, 27 Oct 2009 20:00:53 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 #131 from Linus Torvalds <torvalds@...ux-foundation.org>  2009-10-27 20:00:51 ---
Some more testing of this issue:

 - if I do something like

     [root@...piron-laptop linux]# sync
     [root@...piron-laptop linux]# echo b > /proc/sysrq-trigger

   I never seem to see any problems.

I've done the above several times - I started using it as my shutdown
replacement, and I'm bisecting another independent issue on the same laptop.
And no problems so far.

 - but when I did the whole power-button thing even when the system looked
otherwise idle (it was hung at shutdown, and I waited ten+ seconds), I get in
trouble very easily.

This makes me suspect that the background flush by bdflush simply isn't working
well for ext4. Even when you'd expect things to be idle, and bdflush should
hopefully get your metadata out, it just doesn't.

I'd suspect the 'wait=0' case in ext4_write_inode. It does the same 'don't do
anything' that ext3 does, but presumably the delayed allocation makes for much
worse trouble. Notice how just returning zero from ext4_write_inode() will make
the general fs/fs-writeback.c just remove the inode from the dirty lists
entirely.

One thing to note is that the ext4_write_inode() behavior certainly isn't new,
but it's entirely possible that the per-bdi writeback logic has changed timing
of the writebacks a lot. Which may explain why it's apparently getting more
attention in the 2.6.32-rc series, although some people seem to have seen it
earlier too.

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