Messages in this thread | | | From | Chao Yu <> | Subject | RE: [f2fs-dev] [PATCH 2/2] f2fs: fix to release inode correctly | Date | Tue, 25 Aug 2015 14:38:00 +0800 |
| |
Hi Jaegeuk,
> -----Original Message----- > From: Jaegeuk Kim [mailto:jaegeuk@kernel.org] > Sent: Tuesday, August 25, 2015 6:53 AM > To: Chao Yu > Cc: linux-kernel@vger.kernel.org; linux-f2fs-devel@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,
| |