| Message ID | 1343949380-15398-1-git-send-email-ablock84@googlemail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@jikos.cz> > Signed-off-by: Alexander Block <ablock84@googlemail.com> > --- > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 3, 2012 at 11:13 PM, Josef Bacik <jbacik@fusionio.com> wrote: > 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@jikos.cz> >> Signed-off-by: Alexander Block <ablock84@googlemail.com> >> --- >> 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? It's in linus current master. Lio Bo moved the call out of btrfs_mksubvol into the caller. Later a commit from Jan Kara tried to move the call inside mksubvol below i_mutex. If I understand the logs correctly, It was then merged incorrectly. > Thanks, > > Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Aug 04, 2012 at 01:39:25AM +0200, Alexander Block wrote: > On Fri, Aug 3, 2012 at 11:13 PM, Josef Bacik <jbacik@fusionio.com> wrote: > > I'm confused, this isn't here in btrfs-next, so is this a problem still? > > It's in linus current master. Lio Bo moved the call out of > btrfs_mksubvol into the caller. Later a commit from Jan Kara tried to > move the call inside mksubvol below i_mutex. If I understand the logs > correctly, It was then merged incorrectly. How should we resolve this? The patch has to be pulled via a separate branch, based on top of linus/master, as cmason/for-linus does not have the clashing freezer patches. And I do want to see the fix in master rather soon as it makes testing tedious. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 08, 2012 at 09:20:59AM -0600, David Sterba wrote: > On Sat, Aug 04, 2012 at 01:39:25AM +0200, Alexander Block wrote: > > On Fri, Aug 3, 2012 at 11:13 PM, Josef Bacik <jbacik@fusionio.com> wrote: > > > I'm confused, this isn't here in btrfs-next, so is this a problem still? > > > > It's in linus current master. Lio Bo moved the call out of > > btrfs_mksubvol into the caller. Later a commit from Jan Kara tried to > > move the call inside mksubvol below i_mutex. If I understand the logs > > correctly, It was then merged incorrectly. > > How should we resolve this? The patch has to be pulled via a separate > branch, based on top of linus/master, as cmason/for-linus does not have > the clashing freezer patches. And I do want to see the fix in master > rather soon as it makes testing tedious. Right, I'll fix this up in a separate send to Linus. I thought I had this fixed in my original merge, but either way I'll send a pull to fix it. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; }
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@jikos.cz> Signed-off-by: Alexander Block <ablock84@googlemail.com> --- fs/btrfs/ioctl.c | 5 ----- 1 file changed, 5 deletions(-)