On Sat, 10 Feb 2001, Justin T. Gibbs wrote:
> >Agreed. Good point for the theory. But in practice, entering driver
> >methods without any lock against the access method may lead to subtle
> >races. At least Linux/SCSI hasn't this kind of races.
> >Btw, I am not so sure about FreeBSD/CAM, for example. :-)
>
> In any system, you have to deal with races involving a transaction
> going up and down the stack at the same time or events that invalidate
> a transaction while it is coming down. In CAM this is dealt with by
> having the controller driver assume ownership of a transaction while a
> lock, that prevents the occurance of events that might invalidate
> that transaction, is held. During the process of assuming ownership,
> the transaction is checked one last time to see if it was aborted. If
> not, transfer is complete. Holding a lock across system boundaries
> is a simpler way to deal with these kinds of races, but not nearly
> as efficient as you trade a per-instance lock with a global one.
Thanks for the course. :)
At the time I have adapted sym53c8xx to FreeBSD, I didn't see any
transaction identifier in the IO control block (CCB). But, if you mean
that it is the pointer to the CCB that identifies a transaction, then I
imagine that it should at least host some reference count, for example.
All that in theory, obviously :). In practice, there is certainly
mechanisms that avoid CCB reuse races and I very probably missed some.
(Btw, I donnot claim that Linux is better in this regard, even if some
sequence number (pid, serial_number, ...) is hosted in the Scsi_Cmnd
structure).
On the other hand, I am under the impression that not only low-level
drivers must check ownership of the _transaction_ each time they want to
reference the associated CCB. This hasn't been that clear to me in the
FreeBSD CAM code.
Hopefully, Linux-2.5.x and FreeBSD-5.x will share some synergy about the
issue, given that the dropping of the io_request_lock in Linux/SCSI and
the fine grained of FreeBSD-CAM may well encounter similar synchronisation
issues at nearly the same time. :)
Sorry for all I missed and thanks for your reply.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
