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

[Rick Macklem]

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