From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Alexander Beregalov <a.beregalov@gmail.com>
Cc: "Theodore Ts'o\"" <tytso@mit.edu>,
linux-ext4@vger.kernel.org,
Dmitry Monakhov <dmonakhov@openvz.org>
Subject: Re: 3.8.0-rc1: WARNING: at fs/ext4/page-io.c:232
Date: Thu, 27 Dec 2012 14:29:07 +0800 [thread overview]
Message-ID: <20121227062907.GA5001@gmail.com> (raw)
In-Reply-To: <CAA1sL1QgkEWciR2qBbKWr+_2tRdhxpE1Jh3P0waSeYR8LR8R5w@mail.gmail.com>
On Thu, Dec 27, 2012 at 03:27:04AM +0300, Alexander Beregalov wrote:
> Hello
>
> Let me know if you need more info
>
> EXT4-fs (sda2): INFO: recovery required on readonly filesystem
> EXT4-fs (sda2): write access will be enabled during recovery
> EXT4-fs (sda2): orphan cleanup on readonly fs
> EXT4-fs (sda2): ext4_orphan_cleanup: truncating inode 841849 to 0 bytes
> ------------[ cut here ]------------
> WARNING: at fs/ext4/page-io.c:232 ext4_flush_unwritten_io+0x6b/0x80()
> Hardware name: P35-DS3
> Modules linked in:
> Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc1-00004-g637704c #1
> Call Trace:
> [<ffffffff81038f5a>] warn_slowpath_common+0x7a/0xb0
> [<ffffffff81038fa5>] warn_slowpath_null+0x15/0x20
> [<ffffffff81163b8b>] ext4_flush_unwritten_io+0x6b/0x80
> [<ffffffff8117ac5c>] ext4_ext_truncate+0x2c/0x1f0
> [<ffffffff8116c6d0>] ? ext4_msg+0x50/0x60
> [<ffffffff8115e050>] ext4_truncate+0x70/0xb0
> [<ffffffff8117190b>] ext4_fill_super+0x2bab/0x2ce0
> [<ffffffff810ef02a>] mount_bdev+0x1aa/0x1f0
> [<ffffffff8102aec9>] ? default_spin_lock_flags+0x9/0x10
> [<ffffffff8116ed60>] ? ext4_calculate_overhead+0x3a0/0x3a0
> [<ffffffff8116a870>] ext4_mount+0x10/0x20
> [<ffffffff810ef96b>] mount_fs+0x1b/0xd0
> [<ffffffff81108fc1>] vfs_kern_mount+0x71/0x110
> [<ffffffff8110b096>] do_mount+0x386/0x980
> [<ffffffff810b7f43>] ? strndup_user+0x53/0x70
> [<ffffffff8110b71b>] sys_mount+0x8b/0xe0
> [<ffffffff816afcc8>] mount_block_root+0xfe/0x298
> [<ffffffff816afeb8>] mount_root+0x56/0x5a
> [<ffffffff816afff0>] prepare_namespace+0x134/0x16d
> [<ffffffff8147c9c6>] kernel_init+0x196/0x2a0
> [<ffffffff816af539>] ? loglevel+0x31/0x31
> [<ffffffff8147c830>] ? rest_init+0x80/0x80
> [<ffffffff81482a7c>] ret_from_fork+0x7c/0xb0
> [<ffffffff8147c830>] ? rest_init+0x80/0x80
> ---[ end trace 425942f4f0ed8d07 ]---
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 835709
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 835629
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 682715
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 832545
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 677529
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 838885
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 676342
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 832311
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 683216
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 828057
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 847476
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 834769
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 846534
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 842096
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 833886
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 688996
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 1085523
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 524364
> EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 12686
> EXT4-fs (sda2): 19 orphan inodes deleted
> EXT4-fs (sda2): 1 truncate cleaned up
> EXT4-fs (sda2): recovery complete
> EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
Hi Alexander,
This warning is from ext4_flush_unwritten_io() because we need to take
i_mutex lock before calling this function. Ohterwise we will trigger a
WARN_ON_ONCE(). But, unfortunately, we don't take this lock in
ext4_orphan_cleanup(). So that is why we will get this warning when
cleaning up orphan list. Could you please test this patch?
Thanks,
- Zheng
Subject: [PATCH] ext4: fixup a warning from ext4_flush_unwritten_io() in orphan list cleanup
From: Zheng Liu <wenqing.lz@taobao.com>
When ext4 tries to clean up orphan list, we will get the following warning from
ext4_flush_unwritten_io() because i_mutex lock doesn't be taken.
EXT4-fs (sda2): INFO: recovery required on readonly filesystem
EXT4-fs (sda2): write access will be enabled during recovery
EXT4-fs (sda2): orphan cleanup on readonly fs
EXT4-fs (sda2): ext4_orphan_cleanup: truncating inode 841849 to 0 bytes
------------[ cut here ]------------
WARNING: at fs/ext4/page-io.c:232 ext4_flush_unwritten_io+0x6b/0x80()
Hardware name: P35-DS3
Modules linked in:
Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc1-00004-g637704c #1
Call Trace:
[<ffffffff81038f5a>] warn_slowpath_common+0x7a/0xb0
[<ffffffff81038fa5>] warn_slowpath_null+0x15/0x20
[<ffffffff81163b8b>] ext4_flush_unwritten_io+0x6b/0x80
[<ffffffff8117ac5c>] ext4_ext_truncate+0x2c/0x1f0
[<ffffffff8116c6d0>] ? ext4_msg+0x50/0x60
[<ffffffff8115e050>] ext4_truncate+0x70/0xb0
[<ffffffff8117190b>] ext4_fill_super+0x2bab/0x2ce0
[<ffffffff810ef02a>] mount_bdev+0x1aa/0x1f0
[<ffffffff8102aec9>] ? default_spin_lock_flags+0x9/0x10
[<ffffffff8116ed60>] ? ext4_calculate_overhead+0x3a0/0x3a0
[<ffffffff8116a870>] ext4_mount+0x10/0x20
[<ffffffff810ef96b>] mount_fs+0x1b/0xd0
[<ffffffff81108fc1>] vfs_kern_mount+0x71/0x110
[<ffffffff8110b096>] do_mount+0x386/0x980
[<ffffffff810b7f43>] ? strndup_user+0x53/0x70
[<ffffffff8110b71b>] sys_mount+0x8b/0xe0
[<ffffffff816afcc8>] mount_block_root+0xfe/0x298
[<ffffffff816afeb8>] mount_root+0x56/0x5a
[<ffffffff816afff0>] prepare_namespace+0x134/0x16d
[<ffffffff8147c9c6>] kernel_init+0x196/0x2a0
[<ffffffff816af539>] ? loglevel+0x31/0x31
[<ffffffff8147c830>] ? rest_init+0x80/0x80
[<ffffffff81482a7c>] ret_from_fork+0x7c/0xb0
[<ffffffff8147c830>] ? rest_init+0x80/0x80
---[ end trace 425942f4f0ed8d07 ]---
EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 835709
EXT4-fs (sda2): ext4_orphan_cleanup: deleting unreferenced inode 835629
Now we try to take i_mutex lock before orphan list cleanup, although we don't
need to take it in ext4_orphan_cleanup() because no one write this inode.
WARN_ON_ONCE doesn't be removed because this warning could help us to avoid some
ciritcal errors.
CC: Dmitry Monakhov <dmonakhov@openvz.org>
Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
---
fs/ext4/super.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 3cdb0a2..188d6f1 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2212,7 +2212,18 @@ static void ext4_orphan_cleanup(struct super_block *sb,
__func__, inode->i_ino, inode->i_size);
jbd_debug(2, "truncating inode %lu to %lld bytes\n",
inode->i_ino, inode->i_size);
+ /*
+ * Actually we don't need to take i_mutex lock
+ * because in orphan list cleanup no one can write
+ * this inode. We take it here because in calling
+ * ext4_flush_unwritten_io() this lock needs to be
+ * taken, and we don't want to remove this
+ * WARN_ON_ONCE(). It is useful for us to avoid some
+ * critical errors.
+ */
+ mutex_lock(&inode->i_mutex);
ext4_truncate(inode);
+ mutex_unlock(&inode->i_mutex);
nr_truncates++;
} else {
ext4_msg(sb, KERN_DEBUG,
--
1.7.12.rc2.18.g61b472e
next prev parent reply other threads:[~2012-12-27 6:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-27 0:27 3.8.0-rc1: WARNING: at fs/ext4/page-io.c:232 Alexander Beregalov
2012-12-27 6:29 ` Zheng Liu [this message]
2012-12-27 8:04 ` Dmitry Monakhov
2012-12-27 10:33 ` Zheng Liu
2012-12-27 13:44 ` Theodore Ts'o
2012-12-29 0:21 ` Dave Chinner
2012-12-29 5:04 ` Dmitry Monakhov
2012-12-29 23:23 ` Dave Chinner
2013-01-02 15:17 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121227062907.GA5001@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=a.beregalov@gmail.com \
--cc=dmonakhov@openvz.org \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).