On Tue, 31 May 2011, Sebastian Andrzej Siewior wrote: > Sage Weil wrote: > > > Could one of VFS ppl look at this an NACK/ACK it? > > > > I think it's the other dput that you want to remove. 64252c75 is a > > misleading because the first hunk has to remove dput() from every exit path > > for the function. dentry_unhash is unconditionally doing dget, though. I > > think we want > > > > diff --git a/drivers/usb/core/inode.c b/drivers/usb/core/inode.c > > index 1b125c2..2278dad 100644 > > --- a/drivers/usb/core/inode.c > > +++ b/drivers/usb/core/inode.c > > @@ -389,7 +389,6 @@ static int usbfs_rmdir(struct inode *dir, struct dentry > > *dentry) > > mutex_unlock(&inode->i_mutex); > > if (!error) > > d_delete(dentry); > > - dput(dentry); > > return error; > > } > > Yep, this is the correct one. I added a file and removed it after the hcd > was gone and it only survived your way :) > Are you going to post a complete patch or do you want me to do it? Patch is below. Thanks for testing! sage >From 2dbf6d8f7426980d4c0d8798222b2ce9eed76651 Mon Sep 17 00:00:00 2001 From: Sage Weil <sage@xxxxxxxxxxxx> Date: Tue, 31 May 2011 09:09:16 -0700 Subject: [PATCH] usb: remove bad dput after dentry_unhash Commit 64252c75a removed the useless dget from dentry_unhash but didn't fix up this caller in the usb code. There used to be exactly one dput per dentry_unhash call; now there are none. Tested-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> Signed-off-by: Sage Weil <sage@xxxxxxxxxxxx> --- drivers/usb/core/inode.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/core/inode.c b/drivers/usb/core/inode.c index 1b125c2..2278dad 100644 --- a/drivers/usb/core/inode.c +++ b/drivers/usb/core/inode.c @@ -389,7 +389,6 @@ static int usbfs_rmdir(struct inode *dir, struct dentry *dentry) mutex_unlock(&inode->i_mutex); if (!error) d_delete(dentry); - dput(dentry); return error; } -- 1.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
