Hi Andrey Yes, you are right, & I got this one wrong. Before my previous post, I had only just a quick glance at the code & I thought I remembered what this function did. But my memory was wrong. Maybe I was getting confused with the target code for a different OS! I should have checked, before posting. Apologies for the confusion.
I've been trying out one of Brendan Gregg's DTrace scripts to look at the code flow. And yes "iscsi_full_feature" is called many times! http://www.brendangregg.com/DTrace/dapptrace (The multiple threads do confuse the flow in this script.) Here is a example: [EMAIL PROTECTED]:~# ps -ef | grep iscsi root 7417 1 0 16:29:21 ? 1:18 /usr/sbin/iscsitgtd [EMAIL PROTECTED]:~# ./dapptrace -F -p 659 PID/LWP CALL(args) = return 7417/22: -> iscsi_full_feature(0x80CF8C8, 0x0, 0xD1613A00) 7417/22: -> iscsi_cmd_remove(0x80CF8C8, 0x8, 0x3) 7417/22: -> sna_lt(0x7, 0x8, 0x3) 7417/22: <- sna_lt = 67 7417/22: <- iscsi_cmd_remove = 294 7417/22: -> handle_scsi_cmd(0x80CF8C8, 0xD1014EC0, 0x0) 7417/22: -> iscsi_cmd_alloc(0x80CF8C8, 0x1, 0x0) 7417/22: <- iscsi_cmd_alloc = 264 7417/22: -> spc_decode_lu_addr(0xD1014EC8, 0x8, 0x80DAE40) 7417/22: <- spc_decode_lu_addr = 196 7417/22: -> queue_message_set(0x80C5AF0, 0x0, 0x0) 7417/22: <- queue_message_set = 181 7417/22: <- handle_scsi_cmd = 686 7417/22: <- iscsi_full_feature = 871 Andrey, are you going to raise a bug for that memory leak you spotted in the code for the AHS related error handling? I think you should. Best Regards Nigel Smith This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
