hi folks

I'm requesting code review for

http://defect.opensolaris.org/bz/show_bug.cgi?id=10245

Background - the doors interactions in libnwam were
broken. On the door server side, we were sometimes
alloca()ing a return argument, rather than having a client
pass in a maximally-sized buffer. In the course of fixing this
I've addressed another architectural issue relating
to the libnwam backend - namely that when we call
any of the walk() functions for nwam objects, the
walk was carried out by passing back an nvlist of nvlists,
where each nvlist was a property list for each object.
This obviously is problematic as the number of objects
grows. This approach has been amended to passing
back an nvlist containing a list of object names, each
of which is read() individually. This increases the door
traffic for walks, but with the performance improvements
that accrue from moving away from dynamic allocation,
the effects aren't apparent to the user.

After all this I'm still seeing memory leaks in netcfgd unfortunately,
and these leaks are missing caller information, so ::bufctl_audit
doesn't shed any light on the origin.

I'm also seeing a 24-byte memory leak in nwamcfg which
only happens when we "list" all objects (doesn't happen
for listing NCUs only for example).

Any help in tracking down those leaks would be greatly
appreciated, and if any additional background is required
to make sense of these changes, don't hesitate to ask.
Thanks!

Alan

Reply via email to