Hi Jaegeuk, > -----Original Message----- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Tuesday, August 25, 2015 6:53 AM > To: Chao Yu > Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net > Subject: Re: [f2fs-dev] [PATCH 2/2] f2fs: fix to release inode correctly > > Hi Chao, > > On Mon, Aug 24, 2015 at 09:54:23AM -0700, Jaegeuk Kim wrote: > > On Mon, Aug 24, 2015 at 05:40:45PM +0800, Chao Yu wrote: > > > In following call stack, if unfortunately we lose all chances to truncate > > > inode page in remove_inode_page, eventually we will add the nid allocated > > > previously into free nid cache, this nid is with NID_NEW status and with > > > NEW_ADDR in its blkaddr pointer: > > > > > > - f2fs_create > > > - f2fs_add_link > > > - __f2fs_add_link > > > - init_inode_metadata > > > - new_inode_page > > > - new_node_page > > > - set_node_addr(, NEW_ADDR) > > > - f2fs_init_acl failed > > > - remove_inode_page failed > > > - handle_failed_inode > > > - remove_inode_page failed > > > - iput > > > - f2fs_evict_inode > > > - remove_inode_page failed > > > - alloc_nid_failed cache a nid with valid blkaddr: NEW_ADDR > > Unfortunately, this couldn't fix my bug case.
Another thing I note is that: we do not cover free_nid_list_lock with build_lock, so when we are building free nid cache, we can change the status of free nid cache, so I guess it is one possible suspect who cause our nid issue. And, could you share me the information for reproducing the nid reallocation issue? So I can reproduce in my environment for invistigating. > I'm still struggling to find out something tho. > Meanwhile, let's stay with both of the patches. OK. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/