Date: Thu, 31 May 2007 21:21:13 -0600 From: Scott Long <scottl@samsco.org> To: Hidetoshi Shimokawa <simokawa@freebsd.org> Cc: freebsd-scsi@freebsd.org Subject: Re: CAM locking Message-ID: <465F90A9.7080608@samsco.org> In-Reply-To: <86wsyopf0t.wl%simokawa@FreeBSD.ORG> References: <86wsyopf0t.wl%simokawa@FreeBSD.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
Hidetoshi Shimokawa wrote: > Hi Scott, > > Thank you for your work on CAM. > I have some questions about lock assertion. > > 1. Now, xpt_done() should be called with a sim lock for QUEUED ccbs. > Why don't you add an assertion in xpt_done()? Accessing the sim_lock from the CCB requires enough dereferences that if the lock isn't already held, you'll probably run into problems just doing the derefs in the assertion. Adding a sim_lock field to the CCB has crossed my mind, but I don't want to pollute the CCB with more kernel-only fields if I can. I need to think some more on it. > > 2. CAMDEBUG seems useless with WITNESS because xpt_path_path_id() requires > a sim lock. Can we safely drop the assertion? Yes, this is an area that I didn't clean up very well. A lot of code in periphs and SIMs wants to be able to use CAMDEBUG functions in random places without the lock held, and I don't know of a good way to safely fix this without rewriting a lot of code. I don't know if it's better to just drop the assertion or to audit all of the code provide locked and unlocked versions of the CAMDEBUG functions. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?465F90A9.7080608>