On Wed, 2016-08-10 at 14:46 -0400, Josef Bacik wrote:
> On 08/10/2016 02:25 PM, Linus Torvalds wrote:
> >
> > > > On Wed, Aug 10, 2016 at 11:22 AM, Josef Bacik <jbacik@xxxxxx> wrote:
> > >
> > > On 08/10/2016 02:06 PM, Linus Torvalds wrote:
> > > >
> > > >
> > > > More information in the original email on lkml.
> > >
> > > I'm not subscribed to lkml and for some reason I can't find the original
> > > email in any of the lkml/linux-nfs archives. Could you forward more of the
> > > details?
> >
> > Done.
> >
>
> So my naive fix would be something like this
>
>
> > From: Josef Bacik <jbacik@xxxxxx>
> Date: Wed, 10 Aug 2016 14:43:08 -0400
> Subject: [PATCH] nfsd: fix dentry refcounting problem
>
> b44061d0b9 introduced a dentry ref counting bug, previously we were grabbing one
> ref to dchild in nfsd_create(), but with the creation of nfsd_create_locked() we
> have a ref for dchild from the lookup in nfsd_create(), and then another ref in
> nfsd_create_locked(). The ref from the lookup in nfsd_create() is never dropped
> and results in dentries still in use at unmount.
>
> > Signed-off-by: Josef Bacik <jbacik@xxxxxx>
> ---
> fs/nfsd/vfs.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index ba944123..ff476e6 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1252,10 +1252,13 @@ nfsd_create(struct svc_rqst *rqstp, struct svc_fh *fhp,
> > if (IS_ERR(dchild))
> > return nfserrno(host_err);
> > err = fh_compose(resfhp, fhp->fh_export, dchild, fhp);
> > - if (err) {
> > - dput(dchild);
> > + /*
> > + * We unconditionally drop our ref to dchild as fh_compose will have
> > + * already grabbed its own ref for it.
> > + */
> > + dput(dchild);
> > + if (err)
> > return err;
> > - }
> > return nfsd_create_locked(rqstp, fhp, fname, flen, iap, type,
> > rdev, resfhp);
> }
Looks correct to me:
Reviewed-by: Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
