From: Steven Whitehouse <swhiteho@redhat.com>
To: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Cc: sandeen@redhat.com, viro@zeniv.linux.org.uk, tytso@mit.edu,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, zohar@linux.vnet.ibm.com
Subject: Re: [PATCH 1/1] fiemap: move i_op->fiemap() locking to the ioctl_fiemap()
Date: Fri, 21 Sep 2012 15:27:11 +0100 [thread overview]
Message-ID: <1348237631.2746.60.camel@menhir> (raw)
In-Reply-To: <a1259b2d9d0e9c0ee02f37f9b21230fcb9702207.1348236846.git.dmitry.kasatkin@intel.com>
Hi,
On Fri, 2012-09-21 at 17:14 +0300, Dmitry Kasatkin wrote:
> On some filesystems calling i_op->fiemap() takes the i_mutex,
> on others it doesn't. For example, on ext2/ext3 fiemap calls
> generic_block_fiemap(), which takes the i_mutex, but on ext4
> it doesn't call generic_block_fiemap() for inodes, that have no
> extents and does not take the i_mutex in other cases. Other i_op
> functions, like setxattr/setattr, rely on the caller to lock the
> i_mutex.
>
> This patch moves the i_mutex locking from generic_block_fiemap()
> to ioctl_fiemap(), which is currently the only caller of i_op->fiemap().
>
> This change is needed in preparation for EVM to include a hash of
> the extent data to be used in the HMAC calculation. EVM is called
> when the i_mutex has already been taken.
>
> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
I'm just wondering whether or not we need the i_mutex lock to be taken
at all in GFS2.... the reason that it was moved up a level was that we
require i_mutex to be taken before the glock (rule being local locking
before cluster locking).
However, we do hold a shared glock over the same portion of code and
that should be enough to prevent any changes in the on-disk extents for
the inode in question.
Since we have the new truncate sequence, the inode cannot be truncated
outside of the glock any more, so I don't think that i_mutex really buys
us anything there, unless anybody else can spot a good reason for it?
That said, the patch as is looks ok to me, its just that we may not need
i_mutex protection at all now,
Steve.
> ---
> fs/ext2/inode.c | 4 ++--
> fs/ext3/inode.c | 4 ++--
> fs/ext4/extents.c | 4 ++--
> fs/gfs2/inode.c | 3 ---
> fs/ioctl.c | 2 ++
> 5 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
> index 6363ac6..0e7a0b3 100644
> --- a/fs/ext2/inode.c
> +++ b/fs/ext2/inode.c
> @@ -760,8 +760,8 @@ int ext2_get_block(struct inode *inode, sector_t iblock, struct buffer_head *bh_
> int ext2_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> u64 start, u64 len)
> {
> - return generic_block_fiemap(inode, fieinfo, start, len,
> - ext2_get_block);
> + return __generic_block_fiemap(inode, fieinfo, start, len,
> + ext2_get_block);
> }
>
> static int ext2_writepage(struct page *page, struct writeback_control *wbc)
> diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
> index a075973..0727254 100644
> --- a/fs/ext3/inode.c
> +++ b/fs/ext3/inode.c
> @@ -1046,8 +1046,8 @@ out:
> int ext3_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> u64 start, u64 len)
> {
> - return generic_block_fiemap(inode, fieinfo, start, len,
> - ext3_get_block);
> + return __generic_block_fiemap(inode, fieinfo, start, len,
> + ext3_get_block);
> }
>
> /*
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index cd0c7ed..e960831 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -4916,8 +4916,8 @@ int ext4_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>
> /* fallback to generic here if not in extents fmt */
> if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)))
> - return generic_block_fiemap(inode, fieinfo, start, len,
> - ext4_get_block);
> + return __generic_block_fiemap(inode, fieinfo, start, len,
> + ext4_get_block);
>
> if (fiemap_check_flags(fieinfo, EXT4_FIEMAP_FLAGS))
> return -EBADR;
> diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
> index 4ce22e5..bb8d541 100644
> --- a/fs/gfs2/inode.c
> +++ b/fs/gfs2/inode.c
> @@ -1775,8 +1775,6 @@ static int gfs2_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> if (ret)
> return ret;
>
> - mutex_lock(&inode->i_mutex);
> -
> ret = gfs2_glock_nq_init(ip->i_gl, LM_ST_SHARED, 0, &gh);
> if (ret)
> goto out;
> @@ -1802,7 +1800,6 @@ static int gfs2_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
>
> gfs2_glock_dq_uninit(&gh);
> out:
> - mutex_unlock(&inode->i_mutex);
> return ret;
> }
>
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 29167be..320993f 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -206,7 +206,9 @@ static int ioctl_fiemap(struct file *filp, unsigned long arg)
> if (fieinfo.fi_flags & FIEMAP_FLAG_SYNC)
> filemap_write_and_wait(inode->i_mapping);
>
> + mutex_lock(&inode->i_mutex);
> error = inode->i_op->fiemap(inode, &fieinfo, fiemap.fm_start, len);
> + mutex_unlock(&inode->i_mutex);
> fiemap.fm_flags = fieinfo.fi_flags;
> fiemap.fm_mapped_extents = fieinfo.fi_extents_mapped;
> if (copy_to_user(ufiemap, &fiemap, sizeof(fiemap)))
next prev parent reply other threads:[~2012-09-21 14:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-21 14:14 [PATCH 1/1] fiemap: move i_op->fiemap() locking to the ioctl_fiemap() Dmitry Kasatkin
2012-09-21 14:27 ` Steven Whitehouse [this message]
2012-09-21 14:33 ` Kasatkin, Dmitry
2012-09-21 14:39 ` Steven Whitehouse
2012-09-21 22:59 ` Dave Chinner
2012-09-24 8:13 ` Kasatkin, Dmitry
2012-09-24 9:18 ` Dave Chinner
2012-09-24 11:28 ` Kasatkin, Dmitry
2012-09-25 1:56 ` Dave Chinner
2012-09-26 8:22 ` Kasatkin, Dmitry
2012-09-27 2:12 ` Dave Chinner
2012-09-27 7:43 ` Kasatkin, Dmitry
2012-09-27 12:35 ` Dave Chinner
2012-09-27 13:11 ` Kasatkin, Dmitry
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=1348237631.2746.60.camel@menhir \
--to=swhiteho@redhat.com \
--cc=dmitry.kasatkin@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=zohar@linux.vnet.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).