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