I would be surprised if the "iscsi_full_feature" code was generating a lot of leaks, because this code should only be run during a login to the target, and logins should not be occurring too frequently.
A new bug 6657591 deals with one of the recently spotted memory leak, and the iscsi team do appear to be working on this now, with a fix expected in Nevada snv_85. http://bugs.opensolaris.org/view_bug.do?bug_id=6657591 It looks to me like this bug was introduced in snv_56 during the fixing of another bug: 6491077 - "daemon should use umem_cache_create and friends for speedier allocations." http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6491077 In function "trans_cmd_dup()" a "free()" should have been changed to a "umem_cache_free()", but it was missed. http://src.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/cmd/iscsi/iscsitgtd/t10_sam.c?r2=3213&r1=3126 (A good reason for having code reviews!) I found a couple of interesting links regarding identifying memory leaks, here: http://developers.sun.com/solaris/articles/libumem_library.html http://blogs.sun.com/pnayak/entry/finding_memory_leaks_within_solaris By the way, the version of the iscsi target in S10u4 does seem to be quite old. A bug was recently found in S10u4 that had been fixed nearly a year ago in Nevada! Regards Nigel Smith This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
