From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chao Yu Subject: Re: [PATCH 1/2] f2fs: remove stale inode entry before eviction from gdirty_list Date: Mon, 19 Nov 2018 14:39:40 +0800 Message-ID: <0a2feb36-8f71-67a0-381c-2e487d658145@huawei.com> References: <1542607377-25446-1-git-send-email-riteshh@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gOdDu-00069a-Mf for linux-f2fs-devel@lists.sourceforge.net; Mon, 19 Nov 2018 06:39:54 +0000 Received: from szxga07-in.huawei.com ([45.249.212.35] helo=huawei.com) by sfi-mx-4.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) id 1gOdDq-00DhbW-VK for linux-f2fs-devel@lists.sourceforge.net; Mon, 19 Nov 2018 06:39:54 +0000 In-Reply-To: <1542607377-25446-1-git-send-email-riteshh@codeaurora.org> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net To: Ritesh Harjani , linux-f2fs-devel@lists.sourceforge.net, jaegeuk@kernel.org Hi Ritesh, On 2018/11/19 14:02, Ritesh Harjani wrote: > This is seen when CP_ERROR_FLAG is not set & FS may be corrupted. > There is a case observed where dirty stale inode pointer data is still > present in the gdirty_list causing panic on access while doing > checkpoint operation. > > WARNING: CPU: 3 PID: 1827 at > kernel/msm-4.14/fs/f2fs/inode.c:567 > f2fs_evict_inode+0x364/0x37c > <...> > [42246.776289] BUG: spinlock bad magic on CPU#4, 1245 > [42246.782674] Unable to handle kernel paging request at virtual address 6b6b6b6b6b713b > <...> > [42246.896370] task: ffffffc0f0434080 task.stack: ffffff8023ea0000 > [42246.902465] pc : spin_bug+0x80/0xb8 > [42246.906055] lr : spin_bug+0x64/0xb8 > <...> > [42247.122346] Call trace: > [42247.124876] spin_bug+0x80/0xb8 > [42247.128110] do_raw_spin_lock+0xe8/0x118 > [42247.132144] _raw_spin_lock+0x24/0x30 > [42247.135916] igrab+0x20/0x6c > [42247.138894] f2fs_sync_inode_meta+0x58/0xc0 > [42247.143199] write_checkpoint+0x1c4/0xecc > [42247.147322] f2fs_sync_fs+0x118/0x170 > [42247.151096] f2fs_do_sync_file+0x4f0/0x798 > [42247.155311] f2fs_sync_file+0x54/0x6c > [42247.159087] vfs_fsync_range+0x90/0xac > [42247.162950] vfs_fsync+0x2c/0x38 > [42247.166278] do_fsync+0x3c/0x78 > [42247.169515] SyS_fdatasync+0x20/0x30 > > Signed-off-by: Ritesh Harjani > --- > fs/f2fs/inode.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c > index 91ceee0..c57f636 100644 > --- a/fs/f2fs/inode.c > +++ b/fs/f2fs/inode.c > @@ -702,11 +702,13 @@ void f2fs_evict_inode(struct inode *inode) > stat_dec_inline_dir(inode); > stat_dec_inline_inode(inode); > > - if (likely(!is_set_ckpt_flags(sbi, CP_ERROR_FLAG) && > - !is_sbi_flag_set(sbi, SBI_CP_DISABLED))) > - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)); > - else > + if (unlikely(is_inode_flag_set(inode, FI_DIRTY_INODE))) { > f2fs_inode_synced(inode); > + f2fs_msg(sbi->sb, KERN_WARNING, > + "inconsistent dirty inode:%u entry found during eviction\n", > + inode->i_ino); > + f2fs_bug_on(sbi, 1); IIRC, Jaegeuk added below condition to avoid f2fs_bug_on during doing test w/ checkpoint error injection, if we remove this, we may still encounter such problem. if (likely(!is_set_ckpt_flags(sbi, CP_ERROR_FLAG))) So I'd like to know what kind of case can make dirty inode during evict(), can you explain more? Thanks, > + } > > /* ino == 0, if f2fs_new_inode() was failed t*/ > if (inode->i_ino) >