Date: Sat, 05 Jun 2010 08:52:39 -0700 From: Matthew Jacob <mj@feral.com> To: freebsd-scsi@freebsd.org Subject: Re: report luns (plus some CAM_DEBUG changes) Message-ID: <4C0A72C7.8080005@feral.com> In-Reply-To: <4C0A6E82.4050006@feral.com> References: <mailpost.1275699021.5610248.61078.mailing.freebsd.scsi@FreeBSD.cs.nctu.edu.tw> <4C09FD65.9010406@FreeBSD.org> <4C0A6E82.4050006@feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C0A72C7.8080005>