From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 7 17:56:11 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFC711065670 for ; Mon, 7 Jun 2010 17:56:11 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3E88FC1F for ; Mon, 7 Jun 2010 17:56:11 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o57HuAtW042593 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 7 Jun 2010 10:56:11 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C0D32B6.3030305@feral.com> Date: Mon, 07 Jun 2010 10:56:06 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4C09FD65.9010406@FreeBSD.org> <4C0A6E82.4050006@feral.com> <4C0A72C7.8080005@feral.com> In-Reply-To: <4C0A72C7.8080005@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Mon, 07 Jun 2010 10:56:11 -0700 (PDT) Subject: Re: report luns (plus some CAM_DEBUG changes) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:56:12 -0000 I believe I addressed Alexander's concerns. I will push this tomorrow unless I hear a "Stoi!" > New patch now in http://people.freebsd.org/~mjacob/active_patches > >>> - removing blank line from xpt_acquire_device() violates style(9). > fixed > >>> - wouldn't "debug" sounded better the "dflags" in sysctl? > > this is matching the previous name usage of cam_dflags. > >>> - is there reason to check CAM_DEV_INQUIRY_DATA_VALID in >>> PROBE_REPORT_LUNS? > > Just caution. Also, it allows me to avoid sending MODE SENSE to a > non-connected lun (case of LUN0 not connected, but we use it to gather > REPORT LUNS data) > >>> - in PROBE_REPORT_LUNS you are incrementing target->refcount. But who >>> will decrement it back, if XPT_SCAN_LUN was called directly, without >>> XPT_SCAN_BUS/TGT? >>> - while target is probably also counted by scan request and is not >>> going to disappear, do you think direct manipulation with >>> target->refcount (especially decrement) is a good policy? >>> - if xpt_create_path() or something else fails, I think you may leak >>> target->refcount. >>> >>> > > I've fixed this by delaying the freeing of the old path in > xpt_scan_bus/XPT_SCAN_LUN until *past* the creation of the next path > (in the case we have more to scan). This gets us past having the > target (with its list of luns) go away out from underneath us in the > case that lun0 was scanned but is not itself on the list. I'm much > happier with this change. > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"