Description of problem: RHEL4 kernels from 2.6.9-55.0.2.EL pop the following badness warning when unlinking a file from a sync-mounted ext2 file system: Feb 1 11:08:21 abox kernel: Badness in __writeback_single_inode at fs/fs-writeback.c:248 Feb 1 11:08:21 abox kernel: Feb 1 11:08:21 abox kernel: Call Trace:<ffffffff8019924e>{__writeback_single_inode+85} <ffffffff801996a3>{sync_inode+52} Feb 1 11:08:21 abox kernel: <ffffffff801ba1f6>{ext2_sync_inode+36} <ffffffff801ba6ca>{ext2_truncate+1231} Feb 1 11:08:21 abox kernel: <ffffffff8017cdc4>{sync_dirty_buffer+169} <ffffffff801ba1ba>{ext2_update_inode+796} Feb 1 11:08:21 abox kernel: <ffffffff801ba6eb>{ext2_delete_inode+0} <ffffffff801ba73b>{ext2_delete_inode+80} Feb 1 11:08:21 abox kernel: <ffffffff8019355c>{generic_delete_inode+190} <ffffffff80189c7a>{sys_unlink+261} Feb 1 11:08:21 abox kernel: <ffffffff80110d91>{error_exit+0} <ffffffff8011026a>{system_call+126} Feb 1 11:08:21 abox kernel: Version-Release number of selected component (if applicable): 2.6.9-55.0.2.EL onwards How reproducible: 100% Steps to Reproduce: 1. mke2fs /some/dev 2. mount -osync /some/dev /some/dir 3. mkdir /some/dir/foo 4. rmdir /some/dir/foo 5. dmesg | tail -20 Actual results: # dmesg|tail -20 <unrelated goop> Badness in __writeback_single_inode at fs/fs-writeback.c:248 [<c0179da5>] __writeback_single_inode+0x41/0xba [<c017a3d3>] sync_inode+0x2f/0x40 [<c0197bd4>] ext2_sync_inode+0x21/0x27 [<c019747f>] ext2_truncate+0x359/0x36f [<c0160523>] submit_bh+0x15a/0x166 [<c016070e>] sync_dirty_buffer+0xa4/0xd4 [<c0197ba3>] ext2_update_inode+0x30a/0x315 [<c01965e2>] ext2_delete_inode+0x0/0x5b [<c019662d>] ext2_delete_inode+0x4b/0x5b [<c0173fdd>] generic_delete_inode+0xa2/0x104 [<c01741c0>] iput+0x5f/0x61 [<c01712e3>] dput+0x17b/0x1a7 [<c016a9d4>] sys_rmdir+0xaa/0xf4 [<c015bfc4>] filp_close+0x59/0x5f [<c011ae91>] do_page_fault+0x0/0x5c6 [<c02e09db>] syscall_call+0x7/0xb Expected results: # dmesg|tail -20 <unrelated goop> Additional info: Fixed upstream in commit 659603ef692d3f6c7c216e80310990253864bf2e Author: Andrea Arcangeli <andrea> Date: Mon Oct 31 14:08:54 2005 -0800 [PATCH] fix __writeback_single_inode WARN_ON When the inode count is zero in inode writeback, the WARN_ON(!(inode->i_state & I_WILL_FREE)); is broken, and needs to test for either I_WILL_FREE|I_FREEING. When the inode is in I_FREEING state, it's already out of the visibility of the vm so it can't be freed so it doesn't require the __iget and the generic_delete_inode path can call the sync internally to the lowlevel fs callback during the last iput. So the inode being in I_FREEING is also a valid condition for calling the sync with i_count == 0. The specific stack trace is this: 0xc00000007b8fb6e0 0xc00000000010118c .__writeback_single_inode +0x5c 0xc00000007b8fb6e0 0xc0000000001014dc (lr) .sync_inode +0x3c 0xc00000007b8fb790 0xc0000000001014dc .sync_inode +0x3c 0xc00000007b8fb820 0xc0000000001a5020 .ext2_sync_inode +0x64 0xc00000007b8fb8f0 0xc0000000001a65b4 .ext2_truncate +0x3f8 0xc00000007b8fba40 0xc0000000001a6940 .ext2_delete_inode +0xdc 0xc00000007b8fbac0 0xc0000000000f7a5c .generic_delete_inode +0x124 0xc00000007b8fbb50 0xc0000000000f5fe0 .iput +0xb8 0xc00000007b8fbbe0 0xc0000000000e9fd4 .sys_unlink +0x2a8 0xc00000007b8fbd10 0xc00000000001048c .ret_from_syscall_1 +0x0 Signed-off-by: Andrew Morton <akpm> Signed-off-by: Linus Torvalds <torvalds>
Created attachment 314204 [details] ext2-delete-assertion.patch Patch to fs-writeback.c to prevent WARN_ON when unlinking from a sync mounted ext2 file system.
Updating PM score.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
patch posted on 3/24/09.. move to POST
Committed in 86.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Any updates here? Has this issue been resolved in the RHEL 4.8 Beta? later kernel?
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1024.html