The memleaks on the DSes are plugged:

> ::findleaks
CACHE             LEAKED           BUFCTL CALLER
ffffff01d459d5a0       1 ffffff01eae60088 cralloc_flags+0x21
ffffff01c682a860       1 ffffff01d75d65e8 dserv_mds_do_reportavail+0x210
ffffff01c68262e0       4 ffffff01f3c3f1c0 mds_compound+0x54
ffffff01c682b2e0       3 ffffff01ecc0e6e8 mds_compound+0x193
ffffff01c6828020       2 ffffff02032b4d30 mds_get_server_impl_id+0x30
ffffff01c68262e0       2 ffffff01f3c3f0e8 mds_get_server_impl_id+0x58
ffffff01c6826b20       2 ffffff01dfb46cc0 mds_get_server_impl_id+0x8a
ffffff01c6828860       1 ffffff01d7ba0740 modinstall+0x129
ffffff01c682b2e0       1 ffffff01ddfd1b60 modinstall+0x129
ffffff01c6828860       1 ffffff01d7ba0c50 modinstall+0x129
ffffff01c68265a0       2 ffffff01e159f890 tohex+0x32
ffffff01c6828020       2 ffffff01e3e6e398 xdr_array+0xae
ffffff01c68282e0       1 ffffff0201571818 xdr_bytes+0x70
ffffff01c68285a0       1 ffffff02590b2538 xdr_bytes+0x70
------------------------------------------------------------------------
           Total      24 buffers, 2356 bytes

And on the MDS, we see the same:

> ::findleaks
CACHE             LEAKED           BUFCTL CALLER
ffffff01c68262e0       4 ffffff01d6e497b8 mds_compound+0x54
ffffff01c682b2e0       3 ffffff01d69cdcb0 mds_compound+0x193
ffffff01c6828020       1 ffffff0202d71db8 mds_get_server_impl_id+0x30
ffffff01c6828020       1 ffffff03ea11d4c0 mds_get_server_impl_id+0x30
ffffff01c68262e0       2 ffffff01ebc1a008 mds_get_server_impl_id+0x58
ffffff01c6826b20       2 ffffff0202808588 mds_get_server_impl_id+0x8a
ffffff01c68265a0       2 ffffff01f92d2458 tohex+0x32
ffffff01c6828020       2 ffffff0202d71c08 xdr_array+0xae
ffffff01c68285a0       1 ffffff07c864e128 xdr_bytes+0x70
ffffff01c68282e0       1 ffffff02027ff390 xdr_bytes+0x70
------------------------------------------------------------------------
           Total      19 buffers, 1496 bytes

Besides that nasty interaction on the DS XDR code, we can see that I've fixed the rpc_init_taglist() leak on both systems. BTW - I thought that one may have been in Nevada, but I checked and it is only in the nfs41-gate. Sweet, that means I don't have to backport it into a gate which would cause another week of testing.

The code is ready to go, I have a code walk through next week, where I need to iron out the following issues:

1. Do we leave in the print routines for spe debugging in the kernel?
   • Small footprint
   • But not needed
     • Could use dtrace to debug now that bulk of unit testing is done.
     • No need to print from kernel, may eventually want to write a file.
     • All printing can be done with sped.
2. Is sped a loader or a daemon right now?
   • Only loads policies and nppols
   • Would have to re-run to change them
   • Not SMF-ized
3. Biggest issue - is kspe part of nfssrv or nfs?
   • Put in nfssrv module because of need to get at mds_sids.
   • Not sure if client-side spe will ever work, because of issue with getting path from vnode.
   • Want to do this right, the first integration!

---

Originally posted on Kool Aid Served Daily
Copyright (C) 2009, Kool Aid Served Daily