All of lore.kernel.org
 help / color / mirror / Atom feed
From: Changman Lee <cm224.lee@samsung.com>
To: Chao Yu <chao2.yu@samsung.com>
Cc: "'Jaegeuk Kim'" <jaegeuk@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: reposition unlock_new_inode to prevent accessing invalid inode
Date: Thu, 28 Aug 2014 19:13:32 +0900	[thread overview]
Message-ID: <20140828101332.GB6808@lcm> (raw)
In-Reply-To: <003801cfc29d$a370dad0$ea529070$@samsung.com>

Hi,

On Thu, Aug 28, 2014 at 04:53:01PM +0800, Chao Yu wrote:
> Hi Changman,
> 
> > -----Original Message-----
> > From: Changman Lee [mailto:cm224.lee@samsung.com]
> > Sent: Thursday, August 28, 2014 9:48 AM
> > To: Chao Yu
> > Cc: Jaegeuk Kim; linux-kernel@vger.kernel.org; linux-f2fs-devel@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 be occured;
> 
> I think this condition is the almost impossible but which can happen theoretically.
> 
> > 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
> > bad_inode in Thread B. However, f2fs_iget could still get inode.
> > How about check it using is_bad_inode() in f2fs_iget.
> 
> Yes, agreed. How about return -EIO when this inode we iget_locked is bad?

Hmm.. It might be better to check return value of f2fs_iget like other f/s.

- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -595,6 +595,8 @@ next_step:
                        inode = f2fs_iget(sb, dni.ino);
                        if (IS_ERR(inode))
                                continue;
+                       else if (is_bad_inode(inode))
+                               continue;


Thanks,
Changman

> 
> Thanks,
> Yu
> 
> > 
> > Thanks,
> > 
> > On Tue, Aug 26, 2014 at 06:35:29PM +0800, Chao Yu wrote:
> > > As the race condition on the inode cache, following scenario can appear:
> > > [Thread a]				[Thread b]
> > > 					->f2fs_mkdir
> > > 					  ->f2fs_add_link
> > > 					    ->__f2fs_add_link
> > > 					      ->init_inode_metadata failed here
> > > ->gc_thread_func
> > >   ->f2fs_gc
> > >     ->do_garbage_collect
> > >       ->gc_data_segment
> > >         ->f2fs_iget
> > >           ->iget_locked
> > >             ->wait_on_inode
> > > 					  ->unlock_new_inode
> > >         ->move_data_page
> > > 					  ->make_bad_inode
> > > 					  ->iput
> > >
> > > When we fail in create/symlink/mkdir/mknod/tmpfile, the new allocated inode
> > > should be set as bad to avoid being accessed by other thread. But in above
> > > scenario, it allows f2fs to access the invalid inode before this inode was set
> > > as bad.
> > > This patch fix the potential problem, and this issue was found by code review.
> > >
> > > Signed-off-by: Chao Yu <chao2.yu@samsung.com>
> > > ---
> > >  fs/f2fs/namei.c | 10 +++++-----
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> > > index 6b53ce9..845f1be 100644
> > > --- a/fs/f2fs/namei.c
> > > +++ b/fs/f2fs/namei.c
> > > @@ -134,8 +134,8 @@ static int f2fs_create(struct inode *dir, struct dentry *dentry, umode_t
> > mode,
> > >  	return 0;
> > >  out:
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, ino);
> > >  	return err;
> > > @@ -267,8 +267,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry *dentry,
> > >  	return err;
> > >  out:
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, inode->i_ino);
> > >  	return err;
> > > @@ -308,8 +308,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry *dentry, umode_t
> > mode)
> > >  out_fail:
> > >  	clear_inode_flag(F2FS_I(inode), FI_INC_LINK);
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, inode->i_ino);
> > >  	return err;
> > > @@ -354,8 +354,8 @@ static int f2fs_mknod(struct inode *dir, struct dentry *dentry,
> > >  	return 0;
> > >  out:
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, inode->i_ino);
> > >  	return err;
> > > @@ -688,8 +688,8 @@ release_out:
> > >  out:
> > >  	f2fs_unlock_op(sbi);
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, inode->i_ino);
> > >  	return err;
> > > --
> > > 2.0.0.421.g786a89d
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > Slashdot TV.
> > > Video for Nerds.  Stuff that matters.
> > > http://tv.slashdot.org/
> > > _______________________________________________
> > > Linux-f2fs-devel mailing list
> > > Linux-f2fs-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

WARNING: multiple messages have this Message-ID (diff)
From: Changman Lee <cm224.lee@samsung.com>
To: Chao Yu <chao2.yu@samsung.com>
Cc: 'Jaegeuk Kim' <jaegeuk@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: reposition unlock_new_inode to prevent accessing invalid inode
Date: Thu, 28 Aug 2014 19:13:32 +0900	[thread overview]
Message-ID: <20140828101332.GB6808@lcm> (raw)
In-Reply-To: <003801cfc29d$a370dad0$ea529070$@samsung.com>

Hi,

On Thu, Aug 28, 2014 at 04:53:01PM +0800, Chao Yu wrote:
> Hi Changman,
> 
> > -----Original Message-----
> > From: Changman Lee [mailto:cm224.lee@samsung.com]
> > Sent: Thursday, August 28, 2014 9:48 AM
> > To: Chao Yu
> > Cc: Jaegeuk Kim; linux-kernel@vger.kernel.org; linux-f2fs-devel@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 be occured;
> 
> I think this condition is the almost impossible but which can happen theoretically.
> 
> > 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
> > bad_inode in Thread B. However, f2fs_iget could still get inode.
> > How about check it using is_bad_inode() in f2fs_iget.
> 
> Yes, agreed. How about return -EIO when this inode we iget_locked is bad?

Hmm.. It might be better to check return value of f2fs_iget like other f/s.

- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -595,6 +595,8 @@ next_step:
                        inode = f2fs_iget(sb, dni.ino);
                        if (IS_ERR(inode))
                                continue;
+                       else if (is_bad_inode(inode))
+                               continue;


Thanks,
Changman

> 
> Thanks,
> Yu
> 
> > 
> > Thanks,
> > 
> > On Tue, Aug 26, 2014 at 06:35:29PM +0800, Chao Yu wrote:
> > > As the race condition on the inode cache, following scenario can appear:
> > > [Thread a]				[Thread b]
> > > 					->f2fs_mkdir
> > > 					  ->f2fs_add_link
> > > 					    ->__f2fs_add_link
> > > 					      ->init_inode_metadata failed here
> > > ->gc_thread_func
> > >   ->f2fs_gc
> > >     ->do_garbage_collect
> > >       ->gc_data_segment
> > >         ->f2fs_iget
> > >           ->iget_locked
> > >             ->wait_on_inode
> > > 					  ->unlock_new_inode
> > >         ->move_data_page
> > > 					  ->make_bad_inode
> > > 					  ->iput
> > >
> > > When we fail in create/symlink/mkdir/mknod/tmpfile, the new allocated inode
> > > should be set as bad to avoid being accessed by other thread. But in above
> > > scenario, it allows f2fs to access the invalid inode before this inode was set
> > > as bad.
> > > This patch fix the potential problem, and this issue was found by code review.
> > >
> > > Signed-off-by: Chao Yu <chao2.yu@samsung.com>
> > > ---
> > >  fs/f2fs/namei.c | 10 +++++-----
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> > > index 6b53ce9..845f1be 100644
> > > --- a/fs/f2fs/namei.c
> > > +++ b/fs/f2fs/namei.c
> > > @@ -134,8 +134,8 @@ static int f2fs_create(struct inode *dir, struct dentry *dentry, umode_t
> > mode,
> > >  	return 0;
> > >  out:
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, ino);
> > >  	return err;
> > > @@ -267,8 +267,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry *dentry,
> > >  	return err;
> > >  out:
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, inode->i_ino);
> > >  	return err;
> > > @@ -308,8 +308,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry *dentry, umode_t
> > mode)
> > >  out_fail:
> > >  	clear_inode_flag(F2FS_I(inode), FI_INC_LINK);
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, inode->i_ino);
> > >  	return err;
> > > @@ -354,8 +354,8 @@ static int f2fs_mknod(struct inode *dir, struct dentry *dentry,
> > >  	return 0;
> > >  out:
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, inode->i_ino);
> > >  	return err;
> > > @@ -688,8 +688,8 @@ release_out:
> > >  out:
> > >  	f2fs_unlock_op(sbi);
> > >  	clear_nlink(inode);
> > > -	unlock_new_inode(inode);
> > >  	make_bad_inode(inode);
> > > +	unlock_new_inode(inode);
> > >  	iput(inode);
> > >  	alloc_nid_failed(sbi, inode->i_ino);
> > >  	return err;
> > > --
> > > 2.0.0.421.g786a89d
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > Slashdot TV.
> > > Video for Nerds.  Stuff that matters.
> > > http://tv.slashdot.org/
> > > _______________________________________________
> > > Linux-f2fs-devel mailing list
> > > Linux-f2fs-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/

  reply	other threads:[~2014-08-28 10:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-26 10:35 [f2fs-dev][PATCH] f2fs: reposition unlock_new_inode to prevent accessing invalid inode Chao Yu
2014-08-26 10:35 ` [PATCH] " Chao Yu
2014-08-28  1:47 ` [f2fs-dev] " Changman Lee
2014-08-28  1:47   ` Changman Lee
2014-08-28  8:53   ` [f2fs-dev] " Chao Yu
2014-08-28  8:53     ` Chao Yu
2014-08-28 10:13     ` Changman Lee [this message]
2014-08-28 10:13       ` Changman Lee

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=20140828101332.GB6808@lcm \
    --to=cm224.lee@samsung.com \
    --cc=chao2.yu@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.