linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chao Yu <yuchao0@huawei.com>
To: Sheng Yong <shengyong1@huawei.com>, <jaegeuk@kernel.org>
Cc: <linux-f2fs-devel@lists.sourceforge.net>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] f2fs: cleanup dirty pages if recover failed
Date: Tue, 16 Oct 2018 20:37:33 +0800	[thread overview]
Message-ID: <b0203c4c-747e-3949-62df-e1644f11ad73@huawei.com> (raw)
In-Reply-To: <20181012104926.244217-1-shengyong1@huawei.com>

On 2018/10/12 18:49, Sheng Yong wrote:
> During recover, we will try to create new dentries for inodes with
> dentry_mark. But if the parent is missing (e.g. killed by fsck),
> recover will break. But those recovered dirty pages are not cleanup.
> This will hit f2fs_bug_on:
> 
> [   53.519566] F2FS-fs (loop0): Found nat_bits in checkpoint
> [   53.539354] F2FS-fs (loop0): recover_inode: ino = 5, name = file, inline = 3
> [   53.539402] F2FS-fs (loop0): recover_dentry: ino = 5, name = file, dir = 0, err = -2
> [   53.545760] F2FS-fs (loop0): Cannot recover all fsync data errno=-2
> [   53.546105] F2FS-fs (loop0): access invalid blkaddr:4294967295
> [   53.546171] WARNING: CPU: 1 PID: 1798 at fs/f2fs/checkpoint.c:163 f2fs_is_valid_blkaddr+0x26c/0x320
> [   53.546174] Modules linked in:
> [   53.546183] CPU: 1 PID: 1798 Comm: mount Not tainted 4.19.0-rc2+ #1
> [   53.546186] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> [   53.546191] RIP: 0010:f2fs_is_valid_blkaddr+0x26c/0x320
> [   53.546195] Code: 85 bb 00 00 00 48 89 df 88 44 24 07 e8 ad a8 db ff 48 8b 3b 44 89 e1 48 c7 c2 40 03 72 a9 48 c7 c6 e0 01 72 a9 e8 84 3c ff ff <0f> 0b 0f b6 44 24 07 e9 8a 00 00 00 48 8d bf 38 01 00 00 e8 7c a8
> [   53.546201] RSP: 0018:ffff88006c067768 EFLAGS: 00010282
> [   53.546208] RAX: 0000000000000000 RBX: ffff880068844200 RCX: ffffffffa83e1a33
> [   53.546211] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88006d51e590
> [   53.546215] RBP: 0000000000000005 R08: ffffed000daa3cb3 R09: ffffed000daa3cb3
> [   53.546218] R10: 0000000000000001 R11: ffffed000daa3cb2 R12: 00000000ffffffff
> [   53.546221] R13: ffff88006a1f8000 R14: 0000000000000200 R15: 0000000000000009
> [   53.546226] FS:  00007fb2f3646840(0000) GS:ffff88006d500000(0000) knlGS:0000000000000000
> [   53.546229] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   53.546234] CR2: 00007f0fd77f0008 CR3: 00000000687e6002 CR4: 00000000000206e0
> [   53.546237] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   53.546240] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [   53.546242] Call Trace:
> [   53.546248]  f2fs_submit_page_bio+0x95/0x740
> [   53.546253]  read_node_page+0x161/0x1e0
> [   53.546271]  ? truncate_node+0x650/0x650
> [   53.546283]  ? add_to_page_cache_lru+0x12c/0x170
> [   53.546288]  ? pagecache_get_page+0x262/0x2d0
> [   53.546292]  __get_node_page+0x200/0x660
> [   53.546302]  f2fs_update_inode_page+0x4a/0x160
> [   53.546306]  f2fs_write_inode+0x86/0xb0
> [   53.546317]  __writeback_single_inode+0x49c/0x620
> [   53.546322]  writeback_single_inode+0xe4/0x1e0
> [   53.546326]  sync_inode_metadata+0x93/0xd0
> [   53.546330]  ? sync_inode+0x10/0x10
> [   53.546342]  ? do_raw_spin_unlock+0xed/0x100
> [   53.546347]  f2fs_sync_inode_meta+0xe0/0x130
> [   53.546351]  f2fs_fill_super+0x287d/0x2d10
> [   53.546367]  ? vsnprintf+0x742/0x7a0
> [   53.546372]  ? f2fs_commit_super+0x180/0x180
> [   53.546379]  ? up_write+0x20/0x40
> [   53.546385]  ? set_blocksize+0x5f/0x140
> [   53.546391]  ? f2fs_commit_super+0x180/0x180
> [   53.546402]  mount_bdev+0x181/0x200
> [   53.546406]  mount_fs+0x94/0x180
> [   53.546411]  vfs_kern_mount+0x6c/0x1e0
> [   53.546415]  do_mount+0xe5e/0x1510
> [   53.546420]  ? fs_reclaim_release+0x9/0x30
> [   53.546424]  ? copy_mount_string+0x20/0x20
> [   53.546428]  ? fs_reclaim_acquire+0xd/0x30
> [   53.546435]  ? __might_sleep+0x2c/0xc0
> [   53.546440]  ? ___might_sleep+0x53/0x170
> [   53.546453]  ? __might_fault+0x4c/0x60
> [   53.546468]  ? _copy_from_user+0x95/0xa0
> [   53.546474]  ? memdup_user+0x39/0x60
> [   53.546478]  ksys_mount+0x88/0xb0
> [   53.546482]  __x64_sys_mount+0x5d/0x70
> [   53.546495]  do_syscall_64+0x65/0x130
> [   53.546503]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [   53.547639] ---[ end trace b804d1ea2fec893e ]---
> 
> So if recover fails, we need to drop all recovered data.
> 
> Signed-off-by: Sheng Yong <shengyong1@huawei.com>

Reviewed-by: Chao Yu <yuchao0@huawei.com>

Thanks,


      reply	other threads:[~2018-10-16 12:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28  2:34 [PATCH] f2fs: cleanup dirty pages if recover failed Sheng Yong
2018-09-29 10:57 ` Chao Yu
2018-10-12 10:49   ` [PATCH v2] " Sheng Yong
2018-10-16 12:37     ` Chao Yu [this message]

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=b0203c4c-747e-3949-62df-e1644f11ad73@huawei.com \
    --to=yuchao0@huawei.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shengyong1@huawei.com \
    /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).