@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Subject: Re: [f2fs-dev] [PATCH] f2fs: reposition unlock_new_inode to
> > prevent accessing invalid
> > inode
> >
> > Hi Chao,
> >
> > I agree it's correct unlock_new_inode should be lo
TCH] f2fs: reposition unlock_new_inode to prevent
> accessing invalid
> inode
>
> Hi Chao,
>
> I agree it's correct unlock_new_inode should be located after make_bad_inode.
>
> About this scenario,
> I think we should check some condition if this could be occured;
I think t
unlock_new_inode to prevent
accessing invalid
inode
Hi Chao,
I agree it's correct unlock_new_inode should be located after make_bad_inode.
About this scenario,
I think we should check some condition if this could be occured;
I think this condition is the almost impossible but which can happen
...@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: reposition unlock_new_inode to
prevent accessing invalid
inode
Hi Chao,
I agree it's correct unlock_new_inode should be located after
make_bad_inode.
About this scenario,
I think we should check some condition if this could
Hi Chao,
I agree it's correct unlock_new_inode should be located after make_bad_inode.
About this scenario,
I think we should check some condition if this could be occured;
A inode allocated newly could be victim by gc thread.
Then, f2fs_iget called by Thread A have to fail because we handled it
Hi Chao,
I agree it's correct unlock_new_inode should be located after make_bad_inode.
About this scenario,
I think we should check some condition if this could be occured;
A inode allocated newly could be victim by gc thread.
Then, f2fs_iget called by Thread A have to fail because we handled it
As the race condition on the inode cache, following scenario can appear:
[Thread a] [Thread b]
->f2fs_mkdir
->f2fs_add_link
->__f2fs_add_link
As the race condition on the inode cache, following scenario can appear:
[Thread a] [Thread b]
-f2fs_mkdir
-f2fs_add_link
-__f2fs_add_link
8 matches
Mail list logo
