kern/144330: [nfs] mbuf leakage in nfsd with zfs

[Rick Macklem]

The following reply was made to PR kern/144330; it has been noted by GNATS.

From: Rick Macklem <rmacklem at uoguelph.ca>
To: Daniel Braniss <danny at cs.huji.ac.il>
Cc: Mikolaj Golub <to.my.trociny at gmail.com>,
        Jeremy Chadwick <freebsd at jdc.parodius.com>, freebsd-fs at FreeBSD.org,
        Kai Kockro <kkockro at web.de>, bug-followup at FreeBSD.org,
        gerrit at pmp.uni-hannover.de
Subject: Re: kern/144330: [nfs] mbuf leakage in nfsd with zfs 
Date: Mon, 22 Mar 2010 20:48:50 -0400 (EDT)

 On Mon, 22 Mar 2010, Daniel Braniss wrote:
 
 [good stuff snipped]
 >>
 >> The initial leap doesn't worry me. That's just a design constraint.
 > yes, but new-nsfd does it better.
 >
 
 It's the classic tradeoff between a generic tool and one designed for
 a specific case. Because of quirks in NFSv4, the experimental server
 has no choice but to use a replay cache designed specifically for it
 and it knows assorted things about NFS. The one in sys/rpc/replay.c
 doesn't know anything about NFS, so it will be less efficient w.r.t.
 NFS.
 
 >> A slow leak after that is still a problem. (I might have seen the
 >> slow leak in testing here. I'll poke at it and see if I can reproduce
 >> that.)
 >
 > all I do is mount upd on a client and start a write process.
 >
 
 I only have a FreeBSD client at this point, and it doesn't cause the
 leak for nfsv3,udp for me here.
 
 Doug Rabson pointed out that there would be a leak for the "default:"
 case too, although didn't know if that would occur in practice.
 
 So, maybe you could test this variant of the patch (just in case that
 was the slow leak...):
 --- rpc/svc.c.sav	2010-03-21 18:46:20.000000000 -0400
 +++ rpc/svc.c	2010-03-22 19:00:17.000000000 -0400
 @@ -819,9 +819,11 @@
   					free(r->rq_addr, M_SONAME);
   					r->rq_addr = NULL;
   				}
 +				m_freem(args);
   				goto call_done;
 
   			default:
 +				m_freem(args);
   				goto call_done;
   			}
   		}
 > there seems to be an NFSLOCK involved before calling replay_setsize ...
 >
 
 Ah, thanks for pointing that out.
 
 Thanks for the good testing. At least we're down to a slow leak..rick