On Thu, Jul 16, 2009 at 10:18:05AM -0400, J. Bruce Fields wrote:
> On Wed, Jun 24, 2009 at 03:37:47PM -0400, andros@xxxxxxxxxx wrote:
> > From: Andy Adamson <andros@xxxxxxxxxx>
> >
> > Signed-off-by: Andy Adamson <andros@xxxxxxxxxx>
> > ---
> > fs/nfsd/nfs4state.c | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index b4a536d..991c3cc 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -583,6 +583,9 @@ free_session(struct kref *kref)
> > struct nfsd4_cache_entry *e = &ses->se_slots[i].sl_cache_entry;
> > nfsd4_release_respages(e->ce_respages, e->ce_resused);
> > }
> > + spin_lock(&nfsd_drc_lock);
> > + nfsd_drc_mem_used -= ses->se_fchannel.maxreqs * NFSD_SLOT_CACHE_SIZE;
> > + spin_unlock(&nfsd_drc_lock);
> > kfree(ses);
>
> This patch has to be combined with the previous one.
I thought this was fixing a bug from the previous patch! But instead I
see this is a fix for a preexisting bugfix. So better to move this to
the head of the patch series; applied the following to my for-2.6.32.
Apologies--I've just done this myself and applied the following. Look
OK?
--b.
commit 0a515ffa6f29e9a0f0f60373576bd4d3d5608ae8
Author: Andy Adamson <andros@xxxxxxxxxx>
Date: Mon Jul 27 18:49:05 2009 -0400
nfsd41: reclaim DRC memory on session free
This fixes a leak which would eventually lock out new clients.
Signed-off-by: Andy Adamson <andros@xxxxxxxxxx>
Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxxxxxx>
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 2e6a44e..69bd37e 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -585,6 +585,9 @@ free_session(struct kref *kref)
struct nfsd4_cache_entry *e = &ses->se_slots[i].sl_cache_entry;
nfsd4_release_respages(e->ce_respages, e->ce_resused);
}
+ spin_lock(&nfsd_drc_lock);
+ nfsd_drc_pages_used -= ses->se_fchannel.maxreqs * NFSD_PAGES_PER_SLOT;
+ spin_unlock(&nfsd_drc_lock);
kfree(ses);
}
--
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
