CAM locking

[Hidetoshi Shimokawa]

On 6/1/07, Scott Long <scottl at samsco.org> wrote:
> 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.

If the lock isn't already held, we have a problem sooner or later. The
assertion doesn't add extra dereference except for mtx itself. I don't
see any problem with adding this assertion,
though it may be not perfect.

I think it useful for detecting programming error and describing interface.

> > 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.

Yes, it's very complicated to lock all debug codes.
Can you document somewhere that CAMDEBUG is not usable
with INVARIANTS(or WINTNESS??).



-- 
/\ Hidetoshi Shimokawa
\/  simokawa at FreeBSD.ORG