linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: "Kasatkin, Dmitry" <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:39:18 +0100	[thread overview]
Message-ID: <1348238358.2746.63.camel@menhir> (raw)
In-Reply-To: <CALLzPKYzc8xAAJt94rBDZXjRnXtyKAmTMAfuPX-DjQn007W4NQ@mail.gmail.com>

Hi,

On Fri, 2012-09-21 at 17:33 +0300, Kasatkin, Dmitry wrote:
> On Fri, Sep 21, 2012 at 5:27 PM, Steven Whitehouse <swhiteho@redhat.com> wrote:
> > 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.
> >
> 
> So you say that we might not need to lock i_mutex at all when we call
> __generic_block_fiemap?
> 
> - Dmitry
> 
Yes for GFS2. Although, also it makes little odds if it is held. I'm not
sure what the requirements are for the other filesystems, they may or
may not have their own locking,

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)))
> >
> >



  reply	other threads:[~2012-09-21 14:39 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
2012-09-21 14:33   ` Kasatkin, Dmitry
2012-09-21 14:39     ` Steven Whitehouse [this message]
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=1348238358.2746.63.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).