Hi, > -----Original Message----- > From: Jaegeuk Kim [mailto:jaegeuk....@samsung.com] > Sent: Tuesday, January 28, 2014 2:00 PM > To: Chao Yu > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Subject: Re: [f2fs-dev] [PATCH] f2fs: use inode mutex to keep atomicity of > f2fs_falloc > > Hi, > > 2014-01-28 (화), 10:29 +0800, Chao Yu: > > Previously without protection of inode mutex, f2fs_falloc and other data > > correlated operations will interfere with each other. > > Could you explain a little bit more what kind of scenarios wrt this?
1. Without protection of i_mutex, status(e.g. i_size) of inode could be changed by other operation(e.g. vfs_write()/vfs_truncate()) when we fallocate a file, it may cause us walk into wrong branch code after we check these status of inode, and vice versa. 2. i_size_write()/inode_newsize_ok() is called in f2fs_fallocate(), usually we use i_mutex to protect these functions. > > > > So let's use inode mutex to keep atomicity of f2fs_falloc. > > > > Signed-off-by: Chao Yu <chao2...@samsung.com> > > --- > > fs/f2fs/file.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > > index 85e91ca..ece380f 100644 > > --- a/fs/f2fs/file.c > > +++ b/fs/f2fs/file.c > > @@ -559,6 +559,8 @@ static long f2fs_fallocate(struct file *file, int mode, > > if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)) > > return -EOPNOTSUPP; > > > > + mutex_lock(&inode->i_mutex); > > + > > if (mode & FALLOC_FL_PUNCH_HOLE) > > ret = punch_hole(inode, offset, len); > > else > > @@ -568,6 +570,9 @@ static long f2fs_fallocate(struct file *file, int mode, > > inode->i_mtime = inode->i_ctime = CURRENT_TIME; > > mark_inode_dirty(inode); > > } > > + > > + mutex_unlock(&inode->i_mutex); > > + > > trace_f2fs_fallocate(inode, mode, offset, len, ret); > > return ret; > > } > > -- > Jaegeuk Kim > Samsung -- 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/
