[445] in linux-scsi channel archive

home help back first fref pref prev next nref lref last post

scsi.c bug?

daemon@ATHENA.MIT.EDU (Roland Dunkerley III)
Tue Aug 1 02:36:01 1995

Date: Mon, 31 Jul 95 15:06:48 PDT
To: mike@ringo.reno.nv.us (Michael Morrison)
Cc: linux-scsi@vger.rutgers.edu (linux scsi)
From: rolandd@swn.com (Roland Dunkerley III)
In-Reply-To: <m0sc5Sp-000SmpC@ringo>

>>>>> "|" == Michael Morrison <mike@ringo.reno.nv.us> writes:

    |> Hi all, I was looking through scsi.c and noticed that a bus
    |> reset is issued when a RESERVATION CONFLICT is detected.  Is
    |> this the correct behavior?

I hope not, this will blow me right out of the water with what I'm
trying to do.  Glad I found this before it happened to me, I'll have
to disable that code in my kernel manually until this can be resolved.

    |> Assume that you have two linux boxes connected to the same
    |> target on some exotic piece of scsi hardware via the generic
    |> scsi driver.  You then have 1 scsi bus with 2 initiators and 1
    |> target.  There is an application running on each box that talks
    |> to this exotic scsi device.  If the app on linux-box 1 needs to
    |> issue a series of scsi commands that need to be atomic on the
    |> target.  It would have to issue a reserve command, do the
    |> series of commands, then issue a release command.  linux-box 2
    |> would get a RESERVATION_CONFLICT if it tried to access the
    |> exotic device while reserved by linux-box 1.  The result would
    |> be a bus reset which may or may not hose linux-box 1.  The
    |> correct behavior (IMHO) would be to probagate the error up and
    |> let the higher level code decide what to do (which in this case
    |> would be to wait awhile and reissue the command).

    |> Any comments?

Having the higher level code decide what to do with it sounds like a
good plan to me.  Perhaps this could be changed so that the sd, st,
and sr drivers all do a bus reset (or a bus device reset, much
friendlier) if they receive the RESERVATION_CONFLICT, but the sg
driver passes it up to the user who can then decide what to do with
it.  Then if someone wants to define semantics for how linux works in
a multiple initiator environment they can do this in the device type
specific drivers such that the semantics can be different for disks
and tapes, etc.

Of course this is just my opinion, perhaps sopmeone who knows could
tell us if there is a reason for it working the way it does right now.

NSA: Nazi cryptographic [Hello to all my fans in domestic
surveillance] jihad Rule Psix explosion quiche plutonium FSF Ft. Bragg
ammunition North Korea Kennedy Peking CIA

This message copyright (c) Roland Pleasant Dunkerley III        rolandd@swn.com
<A HREF="http://www.cdt.org/petition.html">Petition to Help keep FCC away
from inet!</A> Distribution of this article via Microsoft Network requires
payment of a $1.00(US) per character per copy license fee.


home help back first fref pref prev next nref lref last post