On Thu, Aug 02, 2012 at 05:16:20PM -0600, Alexander Block wrote: > We got a recursive lock in mksubvol because the caller already held > a lock. I think we got into this due to a merge error. Commit a874a63 > removed the mnt_want_write call from btrfs_mksubvol and added a > replacement call to mnt_want_write_file in btrfs_ioctl_snap_create_transid. > Commit e7848683 however tried to move all calls to mnt_want_write above > i_mutex. So somewhere while merging this, it got mixed up. The > solution is to remove the mnt_want_write call completely from > mksubvol. > > Reported-by: David Sterba <dave@xxxxxxxx> > Signed-off-by: Alexander Block <ablock84@xxxxxxxxxxxxxx> > --- > fs/btrfs/ioctl.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c > index 00ddf22..9df50fa 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -664,10 +664,6 @@ static noinline int btrfs_mksubvol(struct path *parent, > struct dentry *dentry; > int error; > > - error = mnt_want_write(parent->mnt); > - if (error) > - return error; > - > mutex_lock_nested(&dir->i_mutex, I_MUTEX_PARENT); > > dentry = lookup_one_len(name, parent->dentry, namelen); > @@ -703,7 +699,6 @@ out_dput: > dput(dentry); > out_unlock: > mutex_unlock(&dir->i_mutex); > - mnt_drop_write(parent->mnt); > return error; > } > I'm confused, this isn't here in btrfs-next, so is this a problem still? Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
